Ralf Jung [Fri, 18 Dec 2020 15:22:07 +0000 (16:22 +0100)]
Rollup merge of #80130 - pierwill:patch-7, r=oli-obk
docs: Edit rustc_span::symbol::Symbol method
Edit wording of the doc comment for [rustc_span::symbol::Symbol::can_be_raw](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Symbol.html#method.can_be_raw) to match related methods.
bors [Fri, 18 Dec 2020 08:44:50 +0000 (08:44 +0000)]
Auto merge of #80090 - jyn514:tcx-in-render, r=GuillaumeGomez
Pass a `TyCtxt` through to `FormatRender`
This is the next step after https://github.com/rust-lang/rust/pull/79957 for https://github.com/rust-lang/rust/issues/76382. Eventually I plan to use this to remove `stability`, `const_stability`, and `deprecation` from `Item`, but that needs more extensive changes (in particular, https://github.com/rust-lang/rust/pull/75355 or something like it).
This has no actual changes to behavior, it's just moving types around.
Before this change, finding an error when parsing a doctest would make Clippy exit without emitting an error. Now we properly catch a fatal error and ignore it.
Also, if a doctest specifies an edition in the info line, it will be used when parsing it.
bors [Fri, 18 Dec 2020 03:01:14 +0000 (03:01 +0000)]
Auto merge of #80036 - sivadeilra:syms_no_macro, r=petrochenkov
Stop using intermediate macros in definition of symbols
Currently, the rustc_macros::symbols macro generates two
`macro_rules!` macros as its output. These two macros are
used in rustc_span/src/symbol.rs.
This means that each Symbol that we define is represented
in the AST of rustc_symbols twice: once in the definition
of the `define_symbols!` macro (similarly for the
`keywords! macro), and once in the rustc_span::symbols
definition.
That would be OK if there were only a handful of symbols,
but currently we define over 1100 symbols. The definition
of the `define_symbols!` macro contains the expanded definition
of each symbol, so that's a lot of AST storage wasted on a
macro that is used exactly once.
This commit removes the `define_symbols` macro, and simply
allows the proc macro to directly generate the
`rustc_symbols::symbol::sym` module.
The benefit is mainly in reducing memory wasted during
compilation of rustc itself. It should also reduce memory used
by Rust Analyzer.
This commit also reduces the size of the AST for symbol
definitions, by moving two `#[allow(...)]` attributes from
the symbol constants to the `sym` module. This eliminates 2200+
attribute nodes.
This commit also eliminates the need for the `digits_array`
constant. There's no need to store an array of Symbol values
for digits. We can simply define a constant of the base value,
and add to that base value.
I left the `sym::integer` function in rustc_span/src/symbol.rs
instead of moving it into rustc_macros/src/symbols.rs for two
reasons. First, because it's human-written code; it doesn't need
to be generated by the proc-macro. Second, because I didn't want
the `#[allow(...)]` attributes that I moved to the `sym` module
scope to apply to this function. The `sym` module re-exports the
`integer` function from its parent module.
bors [Fri, 18 Dec 2020 00:08:30 +0000 (00:08 +0000)]
Auto merge of #80138 - Dylan-DPC:rollup-qamsfyh, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #78164 (Prefer regions with an `external_name` in `approx_universal_upper_bound`)
- #80003 (Fix overflow when converting ZST Vec to VecDeque)
- #80023 (Enhance error message when misspelled label to value in break expression)
- #80046 (Add more documentation to `Diagnostic` and `DiagnosticBuilder`)
- #80109 (Remove redundant and unreliable coverage test results)
Dylan DPC [Thu, 17 Dec 2020 23:30:21 +0000 (00:30 +0100)]
Rollup merge of #80109 - richkadel:llvm-coverage-counters-2.3.0, r=tmandry
Remove redundant and unreliable coverage test results
The `coverage-reports` tests still generate counters and JSON reports
for inspection, but these files are no longer used in Makefile diffs, to
reduce complexity and confusion from unreliable or unexpected test
results, especially when maintaining them (i.e., generating `--bless`ed
results).
The associated `expected_` files for counters and JSON reports have been
removed, leaving only the files actually used for testing: the `llvm-cov
show` reports.
r? `@tmandry`
Tyler - as we discussed offline...
FYI: `@wesleywiser` `@Swatinem`
Arpad, depending on the timing of this PR, it may not affect you, but I'm removing some of the files that produce slightly different results on Windows as they really aren't necessary to validate coverage results.
Dylan DPC [Thu, 17 Dec 2020 23:30:11 +0000 (00:30 +0100)]
Rollup merge of #80003 - Stupremee:fix-zst-vecdeque-conversion-panic, r=dtolnay
Fix overflow when converting ZST Vec to VecDeque
```rust
let v = vec![(); 100];
let queue = VecDeque::from(v);
println!("{:?}", queue);
```
This code will currently panic with a capacity overflow.
This PR resolves this issue and makes the code run fine.
Dylan DPC [Thu, 17 Dec 2020 23:30:09 +0000 (00:30 +0100)]
Rollup merge of #78164 - Aaron1011:fix/async-region-name, r=tmandry
Prefer regions with an `external_name` in `approx_universal_upper_bound`
Fixes #75785
When displaying a MIR borrowcheck error, we may need to find an upper
bound for a region, which gives us a region to point to in the error
message. However, a region might outlive multiple distinct universal
regions, in which case the only upper bound is 'static
To try to display a meaningful error message, we compute an
'approximate' upper bound by picking one of the universal regions.
Currently, we pick the region with the lowest index - however, this
caused us to produce a suboptimal error message in issue #75785
This PR `approx_universal_upper_bound` to prefer regions with an
`external_name`. This causes us to prefer regions from function
arguments/upvars, which seems to lead to a nicer error message in some
cases.
Arlie Davis [Mon, 14 Dec 2020 19:34:55 +0000 (11:34 -0800)]
Stop using intermediate macros in definition of symbols
Currently, the rustc_macros::symbols macro generates two
`macro_rules!` macros as its output. These two macros are
used in rustc_span/src/symbol.rs.
This means that each Symbol that we define is represented
in the AST of rustc_symbols twice: once in the definition
of the `define_symbols!` macro (similarly for the
`keywords! macro), and once in the rustc_span::symbols
definition.
That would be OK if there were only a handful of symbols,
but currently we define over 1100 symbols. The definition
of the `define_symbols!` macro contains the expanded definition
of each symbol, so that's a lot of AST storage wasted on a
macro that is used exactly once.
This commit removes the `define_symbols` macro, and simply
allows the proc macro to directly generate the
`rustc_symbols::symbol::sym` module.
The benefit is mainly in reducing memory wasted during
compilation of rustc itself. It should also reduce memory used
by Rust Analyzer.
This commit also reduces the size of the AST for symbol
definitions, by moving two `#[allow(...)]` attributes from
the symbol constants to the `sym` module. This eliminates 2200+
attribute nodes.
This commit also eliminates the need for the `digits_array`
constant. There's no need to store an array of Symbol values
for digits. We can simply define a constant of the base value,
and add to that base value.
bors [Thu, 17 Dec 2020 21:13:51 +0000 (21:13 +0000)]
Auto merge of #80122 - davidtwco:revert-76030, r=oli-obk
Revert "cg_llvm: `fewer_names` in `uncached_llvm_type`"
Fixes #76213 and fixes #79564.
This PR temporarily reverts commit fa01ce802f1b403a2140fd945b43af86ec3998a1 from #76030 to until the root issue can be resolved. Requested [in t-compiler meeting](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.20meeting.5D.202020-12-17.20.2354818/near/220261541).
*Note*: I was seeing some failing debuginfo-gdb tests locally but I wasn't sure if they were spurious.
Aaron Hill [Tue, 20 Oct 2020 20:31:54 +0000 (16:31 -0400)]
Prefer regions with an `external_name` in `approx_universal_upper_bound`
Fixes #75785
When displaying a MIR borrowcheck error, we may need to find an upper
bound for a region, which gives us a region to point to in the error
message. However, a region might outlive multiple distinct universal
regions, in which case the only upper bound is 'static
To try to display a meaningful error message, we compute an
'approximate' upper bound by picking one of the universal regions.
Currently, we pick the region with the lowest index - however, this
caused us to produce a suboptimal error message in issue #75785
This PR `approx_universal_upper_bound` to prefer regions with an
`external_name`. This causes us to prefer regions from function
arguments/upvars, which seems to lead to a nicer error message in some
cases.
bors [Thu, 17 Dec 2020 14:52:50 +0000 (14:52 +0000)]
Auto merge of #80113 - davidtwco:issue-80086-ci-llvm-stamp, r=Mark-Simulacrum
bootstrap: update ci-llvm stamp after #80087
Fixes #80086.
Unfortunately, #80087 forgot to update the ci-llvm stamp, so the updated ci-llvm tarball with `llvm-dwp` wasn't downloaded by users. This PR updates the ci-llvm stamp to resolve that problem.
bors [Thu, 17 Dec 2020 12:02:29 +0000 (12:02 +0000)]
Auto merge of #80114 - GuillaumeGomez:rollup-gszr5kn, r=GuillaumeGomez
Rollup of 5 pull requests
Successful merges:
- #80006 (BTreeMap: more expressive local variables in merge)
- #80022 (BTreeSet: simplify implementation of pop_first/pop_last)
- #80035 (Optimization for bool's PartialOrd impl)
- #80040 (Always run intrinsics lowering pass)
- #80047 (Use more symbols in rustdoc)
Guillaume Gomez [Thu, 17 Dec 2020 10:36:54 +0000 (11:36 +0100)]
Rollup merge of #80047 - jyn514:more-symbols, r=GuillaumeGomez
Use more symbols in rustdoc
Builds on https://github.com/rust-lang/rust/pull/80044 and should not be merged before.
I want to test if this is actually faster before merging it, there was a lot of `to_string()` calls so I'm not sure it will actually help. That means I have to wait for 80044 to get merged before running perf.
Guillaume Gomez [Thu, 17 Dec 2020 10:36:52 +0000 (11:36 +0100)]
Rollup merge of #80040 - tmiasko:always-lower-intrinsics, r=Dylan-DPC
Always run intrinsics lowering pass
Move intrinsics lowering pass from the optimization phase (where it
would not run if -Zmir-opt-level=0), to the drop lowering phase where it
runs unconditionally.
The implementation of those intrinsics in code generation and
interpreter is unnecessary. Remove it.
David Wood [Thu, 17 Dec 2020 10:29:58 +0000 (10:29 +0000)]
bootstrap: update ci-llvm stamp after #80087
Unfortunately, #80087 forgot to update the ci-llvm stamp, so the updated
ci-llvm tarball with `llvm-dwp` wasn't downloaded by users. This commit
updates the ci-llvm stamp to resolve that problem.
Rich Kadel [Thu, 17 Dec 2020 06:07:40 +0000 (22:07 -0800)]
Remove redundant and unreliable coverage test results
The `coverage-reports` tests still generate counters and JSON reports
for inspection, but these files are no longer used in Makefile diffs, to
reduce complexity and confusion from unreliable or unexpected test
results, especially when maintaining them (i.e., generating `--bless`ed
results).
The associated `expected_` files for counters and JSON reports have been
removed, leaving only the files actually used for testing: the `llvm-cov
show` reports.
Yuki Okushi [Thu, 17 Dec 2020 02:44:12 +0000 (11:44 +0900)]
Rollup merge of #80097 - SimonSapin:popcount, r=m-ou-se
Add `popcount` and `popcnt` as doc aliases for `count_ones` methods.
Integer types have a `count_ones` method that end up calling `intrinsics::ctpop`. On some architectures, that intrinsic is translated as a corresponding CPU instruction know as "popcount" or "popcnt".
This PR makes it so that searching for those names in rustdoc shows those methods.
CC https://blog.rust-lang.org/2020/11/19/Rust-1.48.html#adding-search-aliases
Yuki Okushi [Thu, 17 Dec 2020 02:44:10 +0000 (11:44 +0900)]
Rollup merge of #80082 - ehuss:revert-rust-src-vendor, r=Mark-Simulacrum
Revert #78790 - rust-src vendoring
This reverts the rust-src vendor changes from #78790. There were a few issues (see #79218, https://github.com/rust-lang/cargo/issues/8962, https://github.com/rust-lang/cargo/issues/8963), that I don't think will get fixed in the next few days before the beta branch.
Yuki Okushi [Thu, 17 Dec 2020 02:44:06 +0000 (11:44 +0900)]
Rollup merge of #80072 - richkadel:llvm-coverage-counters-2.2.1, r=tmandry
Fixed conflict with drop elaboration and coverage
See
https://github.com/rust-lang/rust/issues/80045#issuecomment-745733339
Coverage statements are moved to the beginning of the BCB. This does
also affect what's counted before a panic, changing some results, but I
think these results may even be preferred? In any case, there are no
guarantees about what's counted when a panic occurs (by design).
But that is not always a safe thing to do -- sometimes the early `otherwise` branch is necessary so the later block could assume the value of `discriminant(X)`.
I am not totally sure what's the best way to detect that, but fixing #78496 should be easy -- we just check if `X` is a sub-expression of `Y`. A more precise test might be to check if `Y` contains a `Downcast(1)` of `X`, but I think this might be good enough.
Yuki Okushi [Thu, 17 Dec 2020 02:43:57 +0000 (11:43 +0900)]
Rollup merge of #79877 - bstrie:depinfut, r=oli-obk
Allow `since="TBD"` for rustc_deprecated
Closes #78381.
This PR only affects `#[rustc_deprecated]`, not `#[deprecated]`, so there is no effect on any stable language feature.
Likewise this PR only implements `since="TBD"`, it does not actually tag any library functions with it, so there is no effect on any stable API.
Overview of changes:
* `rustc_middle/stability.rs`:
* change `deprecation_in_effect` function to return `false` when `since="TBD"`
* tidy up the compiler output when a deprecated item has `since="TBD"`
* `rustc_passes/stability.rs`:
* allow `since="TBD"` to pass the sanity check for stable_version < deprecated_version
* refactor the "invalid stability version" and "invalid deprecation version" error into separate errors
* rustdoc: make `since="TBD"` message on a deprecated item's page match the command-line deprecation output
* tests:
* test rustdoc output
* test that the `deprecated_in_future` lint fires when `since="TBD"`
* test the new "invalid deprecation version" error message
I probably should do a few more things before this can be merged:
- [x] Add tests (added basic tests, more advanced tests could be done in the future?)
- [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements)
- [x] Fix clippy
However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs.
Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this?
r? `@ghost` for now
I probably should do a few more things before this can be merged:
- [x] Add tests (added basic tests, more advanced tests could be done in the future?)
- [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements)
- [x] Fix clippy
However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs.
Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this?
r? `@ghost` for now
bors [Thu, 17 Dec 2020 00:15:45 +0000 (00:15 +0000)]
Auto merge of #79790 - LeSeulArtichaut:issue-79683, r=lcnr
Take into account negative impls in "trait item not found" suggestions
This removes the suggestion to implement a trait for a type when that type already has a negative implementation for the trait, and replaces it with a note to point out that the trait is explicitely unimplemented, as suggested by `@scottmcm.`
Simon Sapin [Wed, 16 Dec 2020 22:51:18 +0000 (23:51 +0100)]
Add `popcount` and `popcnt` as doc aliases for `count_ones` methods.
Integer types have a `count_ones` method that end up calling
`intrinsics::ctpop`.
On some architectures, that intrinsic is translated as a corresponding
CPU instruction know as "popcount" or "popcnt".
This PR makes it so that searching for those names in rustdoc shows those methods.
CC https://blog.rust-lang.org/2020/11/19/Rust-1.48.html#adding-search-aliases
bors [Wed, 16 Dec 2020 19:36:22 +0000 (19:36 +0000)]
Auto merge of #80087 - davidtwco:issue-80086-llvm-dwp-in-ci-llvm, r=Mark-Simulacrum
bootstrap: include llvm-dwp in CI LLVM
Fixes #80086.
This PR includes the `llvm-dwp` tool in the CI LLVM (which rustc developers can download instead of building LLVM locally) - `llvm-dwp` is required by Split DWARF which landed in PR #77117.
David Wood [Wed, 16 Dec 2020 19:16:36 +0000 (19:16 +0000)]
bootstrap: include llvm-dwp in CI LLVM
This commit includes the `llvm-dwp` tool in the CI LLVM (which rustc
developers can download instead of building LLVM locally) - `llvm-dwp`
is required by Split DWARF which landed in PR #77117.
bors [Wed, 16 Dec 2020 12:51:42 +0000 (12:51 +0000)]
Auto merge of #77117 - davidtwco:issue-34651-split-dwarf, r=nagisa
cg_llvm: split dwarf support
cc #34651
This PR adds initial support for Split DWARF to rustc, based on the implementation in Clang.
##### Current Status
This PR currently has functioning split-dwarf, running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary, which contains the linked dwarf objects.
##### To-Do
I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit.
- [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense.
- [x] Determine whether or not there should be a single `dwo` output from rustc, or one per codegen-unit as exists currently.
- [x] Add tests.
- [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile`, which is correct, but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file).
r? `@nagisa`
cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`
David Wood [Sun, 8 Nov 2020 17:17:37 +0000 (17:17 +0000)]
cg_llvm: split dwarf filename and comp dir
llvm-dwp concatenates `DW_AT_comp_dir` with `DW_AT_GNU_dwo_name` (only
when `DW_AT_comp_dir` exists), which can result in it failing to find
the DWARF object files.
In earlier testing, `DW_AT_comp_dir` wasn't present in the final
object and the current directory was the output directory.
When running tests through compiletest, the working directory of the
compilation is different from output directory and that resulted in
`DW_AT_comp_dir` being in the object file (and set to the current
working directory, rather than the output directory), and
`DW_AT_GNU_dwo_name` being set to the full path (rather than just
the filename), so llvm-dwp was failing.
This commit changes the compilation directory provided to LLVM to match
the output directory, where DWARF objects are output; and ensures that
only the filename is used for `DW_AT_GNU_dwo_name`.
David Wood [Sun, 8 Nov 2020 17:27:33 +0000 (17:27 +0000)]
compiletest: add split dwarf compare mode
This commit adds a Split DWARF compare mode to compiletest so that
debuginfo tests are also tested using Split DWARF in split mode (and
manually in single mode).
David Wood [Wed, 14 Oct 2020 17:16:05 +0000 (18:16 +0100)]
bootstrap: copy `llvm-dwp` to sysroot
`llvm-dwp` is required for linking the DWARF objects into DWARF packages
when using Split DWARF, especially given that rustc produces multiple
DWARF objects (one for each codegen unit).
David Wood [Wed, 23 Sep 2020 15:57:50 +0000 (16:57 +0100)]
cg_ssa: introduce `TargetMachineFactoryFn` alias
This commit removes the `TargetMachineFactory` struct and adds a
`TargetMachineFactoryFn` type alias which is used everywhere that the
previous, long type was used.