The previous commit wrapped `Parser` within a `Cow` for the hot macro
parsing path. As a result, there's no need for the `Cow` within
`Directory`, because it lies within `Parser`.
Avoid instantiating many `Parser` structs in `generic_extension`.
Currently, every iteration of the main loop in `generic_extension`
instantiates a `Parser`, which is expensive because `Parser` is a large
type. Many of those instantiations are only used immutably, particularly
for simple-but-repetitive macros of the sort seen in `html5ever` and PR
68836.
This commit initializes a single "base" parser outside the loop, and
then uses `Cow` to avoid cloning it except for the mutating iterations.
This speeds up `html5ever` runs by up to 15%.
bors [Tue, 4 Feb 2020 23:56:49 +0000 (23:56 +0000)]
Auto merge of #68544 - Aaron1011:remove-overlapping-traits, r=estebank
Remove the `overlapping_marker_traits` feature
See #29864
This has been replaced by `#[feature(marker_trait_attr)]`
A few notes:
* Due to PR #68057 not yet being in the bootstrap compiler, it's
necessary to continue using `#![feature(overlapping_marker_traits)]`
under `#[cfg(bootstrap)]` to work around type inference issues.
* I've updated tests that used `overlapping_marker_traits` to now use
`marker_trait_attr` where applicable
The test `src/test/ui/overlap-marker-trait.rs` doesn't make any sense
now that `overlapping_marker_traits`, so I removed it.
The test `src/test/ui/traits/overlap-permitted-for-marker-traits-neg.rs`
now fails, since it's no longer possible to have multiple overlapping
negative impls of `Send`. I believe that this is the behavior we want
(assuming that `Send` is not going to become a `#[marker]` trait, so I
renamed the test to `overlap-permitted-for-marker-traits-neg`
bors [Tue, 4 Feb 2020 20:30:53 +0000 (20:30 +0000)]
Auto merge of #68558 - HeroicKatora:buf-writer-capacity, r=alexcrichton
Add a method to query the capacity of a BufWriter and BufReader
Besides the obvious of retrieving the parameter used to construct the writer, this method allows consumers to control the number of `flush` calls during write operations. For `BufReader` it gives an upper bound on the returned buffer in `fill_buf` which might influence the allocation behaviour of a consumer.
Aaron Hill [Sat, 25 Jan 2020 20:30:19 +0000 (15:30 -0500)]
Remove the `overlapping_marker_traits` feature
See #29864
This has been replaced by `#[feature(marker_trait_attr)]`
A few notes:
* Due to PR #68057 not yet being in the bootstrap compiler, it's
necessary to continue using `#![feature(overlapping_marker_traits)]`
under `#[cfg(bootstrap)]` to work around type inference issues.
* I've updated tests that used `overlapping_marker_traits` to now use
`marker_trait_attr` where applicable
The test `src/test/ui/overlap-marker-trait.rs` doesn't make any sense
now that `overlapping_marker_traits`, so I removed it.
The test `src/test/ui/traits/overlap-permitted-for-marker-traits-neg.rs`
now fails, since it's no longer possible to have multiple overlapping
negative impls of `Send`. I believe that this is the behavior we want
(assuming that `Send` is not going to become a `#[marker]` trait, so I
renamed the test to `overlap-permitted-for-marker-traits-neg`
bors [Tue, 4 Feb 2020 17:17:55 +0000 (17:17 +0000)]
Auto merge of #68377 - estebank:fn-obligations-spans, r=oli-obk
Tweak obligation error output
- Point at arguments or output when fn obligations come from them, or ident when they don't
- Point at `Sized` bound (fix #47990)
- When object unsafe trait uses itself in associated item suggest using `Self` (fix #66424, fix #33375, partially address #38376, cc #61525)
- Point at reason in object unsafe trait with `Self` in supertraits or `where`-clause (cc #40533, cc #68377)
- On implicit type parameter `Sized` obligations, suggest `?Sized` (fix #57744, fix #46683)
bors [Tue, 4 Feb 2020 14:16:18 +0000 (14:16 +0000)]
Auto merge of #68708 - Mark-Simulacrum:stage0-step, r=pietroalbini
Step stage0 to bootstrap from 1.42
This also includes a commit which fixes the rustfmt downloading logic to redownload when the rustfmt channel changes, and bumps rustfmt to a more recent version.
bors [Tue, 4 Feb 2020 10:58:45 +0000 (10:58 +0000)]
Auto merge of #68804 - ecstatic-morse:qualif-cursor-lazy, r=estebank
Always use lazy qualif getters during const-checking
`has_mut_interior_eager_seek` was needed to work around an overly restrictive bound on the `per_local` argument to the `Qualif` trait. This PR makes that bound `FnMut` instead of `Fn` so we can seek cursors inside of it, resolving a FIXME in the const-checking code.
bors [Mon, 3 Feb 2020 22:02:26 +0000 (22:02 +0000)]
Auto merge of #67668 - matthewjasper:or-patterns, r=pnkfelix
Implement MIR lowering for or-patterns
This is the last thing needed to get meaningful run-pass tests for or-patterns. There probably need to be more tests before stabilizing this, but the most important cases should have been covered.
Note: we can generate exponentially large MIR CFGs when using or-patterns containing bindings, type ascriptions, or that are for a match arm with a guard. `src/test/mir-opt/exponential-or.rs` shows the best case for what we currently do.
bors [Mon, 3 Feb 2020 18:40:54 +0000 (18:40 +0000)]
Auto merge of #68803 - Dylan-DPC:rollup-b4x6ghj, r=Dylan-DPC
Rollup of 8 pull requests
Successful merges:
- #68678 (Install robots.txt into rust-docs tarballs)
- #68711 (Added upper bound of what vecs and boxes can allocate)
- #68744 (Do not ICE in `type-alias-impl-trait` with save-analysis)
- #68777 (Clean up E0263 explanation)
- #68787 (Optimize core::ptr::align_offset (part 1))
- #68797 (Fix links to types instead of modules)
- #68798 (Test that `#[track_caller]` as `fn()` respects RT / CTFE equivalence)
- #68800 (Stabilize `core::iter::once_with()`)
Dylan DPC [Mon, 3 Feb 2020 17:58:27 +0000 (18:58 +0100)]
Rollup merge of #68711 - hman523:fix-68593, r=Dylan-DPC
Added upper bound of what vecs and boxes can allocate
Fixed issue #68593
I added a line of documentation to these two files to reflect that vectors and boxes ensure that they never allocate more than `isize::MAX` bytes.
r? @steveklabnik
bors [Mon, 3 Feb 2020 13:06:44 +0000 (13:06 +0000)]
Auto merge of #68665 - eddyb:debuginfo-early-create-var, r=nagisa
codegen: create DIVariables ahead of using them with llvm.dbg.declare.
Instead of having `rustc_codegen_llvm` bundle creation of a `DIVariable` and `llvm.dbg.declare` into a single operation, they are now two separate methods, and the `DIVariable` is created earlier, specifically when `mir::VarDebugInfo`s are being partitioned into locals.
While this isn't currently needed, it's a prerequisite for #48300, which adds fragmented debuginfo, where one `mir::VarDebugInfo` has multiple parts of itself mapped to different `mir::Place`s.
For debuggers to see one composite variable instead of several ones with the same name, we need to create a single `DIVariable` and share it between multiple `llvm.dbg.declare` calls, which are likely pointing to different MIR locals.
That makes the `per_local_var_debug_info` partitioning a good spot to do this in, as we can create *exactly* one `DIVariable` per `mir::VarDebugInfo`, and refer to it as many things as needed.
I'm opening this PR separately because I want to test its perf impact in isolation (see https://github.com/rust-lang/rust/pull/48300#issuecomment-580121438).
r? @nagisa or @oli-obk cc @michaelwoerister @nikomatsakis
bors [Mon, 3 Feb 2020 06:38:34 +0000 (06:38 +0000)]
Auto merge of #68772 - matthewjasper:relate-opt, r=davidtwco
Avoid exponential behaviour when relating types
When equating bound types we check subtyping in both directions. Since closures are invariant in their substs, we end up comparing the two types an exponential number of times. If there are no bound variables this isn't needed.
bors [Sun, 2 Feb 2020 20:33:47 +0000 (20:33 +0000)]
Auto merge of #68720 - wesleywiser:llvm_time_trace, r=davidtwco
Add support for enabling the LLVM time-trace feature
I found this helpful while investigating an LLVM performance issue.
Passing `-Z llvm-time-trace` causes a `llvm_timings.json` file to be
created. This file can be inspected in with the Chrome Profiler
tools or with any other compatible tool like SpeedScope.
Rollup merge of #68764 - Centril:self-semantic, r=petrochenkov
parser: syntactically allow `self` in all `fn` contexts
Part of https://github.com/rust-lang/rust/pull/68728.
`self` parameters are now *syntactically* allowed as the first parameter irrespective of item context (and in function pointers). Instead, semantic validation (`ast_validation`) is used.
bors [Sat, 1 Feb 2020 23:31:51 +0000 (23:31 +0000)]
Auto merge of #68752 - JohnTitor:rollup-zz3u4xl, r=JohnTitor
Rollup of 7 pull requests
Successful merges:
- #68460 (Use BufWriter for emitting MIR)
- #68681 (Suggest path separator for single-colon typos)
- #68688 ([docs] remind bug reporters to update nightly)
- #68704 (Ignore `build` dir formatting)
- #68727 (Remove a comment about pretty printer in formatting tests)
- #68736 (Remove `Alloc` in favor of `AllocRef`)
- #68740 (Do not suggest things named underscore)
Yuki Okushi [Sat, 1 Feb 2020 23:30:16 +0000 (08:30 +0900)]
Rollup merge of #68704 - jonas-schievink:ignore-build-fmt, r=Mark-Simulacrum
Ignore `build` dir formatting
I've noticed that rustfmt tries to parse and check the formatting of code in `build` if `.git` is missing (which includes test artifacts and generated code). This should fix that.
Yuki Okushi [Sat, 1 Feb 2020 23:30:15 +0000 (08:30 +0900)]
Rollup merge of #68688 - jbr:remind-bug-reporters-to-update-if-on-nightly, r=centril
[docs] remind bug reporters to update nightly
Hi and thanks for rust! Today I reported a bug in nightly that was already fixed, so I thought other potential bug reporters might appreciate a reminder to update before reporting. I wasn't sure if this would apply for other channels as well.
Yuki Okushi [Sat, 1 Feb 2020 23:30:11 +0000 (08:30 +0900)]
Rollup merge of #68681 - bobrippling:fix-matched-angle-brackets, r=Centril
Suggest path separator for single-colon typos
This commit adds guidance for when a user means to type a path, but ends
up typing a single colon, such as `<<Impl as T>:Ty>`.
This change seemed pertinent as the current error message is
particularly misleading, emitting `error: unmatched angle bracket`,
despite the angle bracket being matched later on, leaving the user to
track down the typo'd colon.