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.
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
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.
David Wood [Wed, 23 Sep 2020 15:25:20 +0000 (16:25 +0100)]
llvm: update ffi bindings for split dwarf
This commit modifies the FFI bindings to LLVM required for Split DWARF
support in rustc. In particular:
- `addPassesToEmitFile`'s wrapper, `LLVMRustWriteOutputFile` now takes
a `DwoPath` `const char*`. When disabled, `nullptr` should be provided
which will preserve existing behaviour. When enabled, the path to the
`.dwo` file should be provided.
- `createCompileUnit`'s wrapper, `LLVMRustDIBuilderCreateCompileUnit`
now has two additional arguments, for the `DWOId` and to enable
`SplitDebugInlining`. `DWOId` should always be zero.
- `createTargetMachine`'s wrapper, `LLVMRustCreateTargetMachine` has an
additional argument which should be provided the path to the `.dwo`
when enabled.
bors [Wed, 16 Dec 2020 09:13:14 +0000 (09:13 +0000)]
Auto merge of #79682 - jyn514:no-blanket-impls, r=Manishearth,GuillaumeGomez
Don't look for blanket impls in intra-doc links
This never worked and has been causing severe performance problems.
Hopefully it will be re-landed at some point in the future when it
actually works, but in the meantime it makes no sense to have the code
around when it does nothing and actively makes rustdoc harder to use.
Closes https://github.com/rust-lang/rust/issues/78761. Does *not* affect https://github.com/rust-lang/rust/issues/78800.
Rich Kadel [Wed, 16 Dec 2020 07:33:47 +0000 (23:33 -0800)]
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).
bors [Wed, 16 Dec 2020 06:26:51 +0000 (06:26 +0000)]
Auto merge of #79607 - DrMeepster:maybe_uninit_write_slice, r=m-ou-se
MaybeUninit::copy/clone_from_slice
This PR adds 2 new methods to MaybeUninit under the feature of `maybe_uninit_write_slice`: `copy_from_slice` and `clone_from_slice`.
These are useful for initializing uninitialized buffers (such as the one returned by `Vec::spare_capacity_mut` for example) with initialized data.
The methods behave similarly to the methods on slices, but the destination is uninitialized and they return the destination slice as an initialized slice.
bors [Wed, 16 Dec 2020 03:35:08 +0000 (03:35 +0000)]
Auto merge of #80041 - jyn514:shrink-item, r=GuillaumeGomez
Get rid of `clean::Deprecation`
This brings the size of `item.deprecation` from 56 to 16 bytes. Helps with #79103 and https://github.com/rust-lang/rust/issues/76382, in the same vein as https://github.com/rust-lang/rust/pull/79957.
bors [Wed, 16 Dec 2020 00:47:50 +0000 (00:47 +0000)]
Auto merge of #78833 - CDirkx:parse_prefix, r=dtolnay
Refactor and fix `parse_prefix` on Windows
This PR is an extension of #78692 as well as a general refactor of `parse_prefix`:
**Fixes**:
There are two errors in the current implementation of `parse_prefix`:
Firstly, in the current implementation only `\` is recognized as a separator character in device namespace prefixes. This behavior is only correct for verbatim paths; `"\\.\C:/foo"` should be parsed as `"C:"` instead of `"C:/foo"`.
Secondly, the current implementation only handles single separator characters. In non-verbatim paths a series of separator characters should be recognized as a single boundary, e.g. the UNC path `"\\localhost\\\\\\C$\foo"` should be parsed as `"\\localhost\\\\\\C$"` and then `UNC(server: "localhost", share: "C$")`, but currently it is not parsed at all, because it starts being parsed as `\\localhost\` and then has an invalid empty share location.
Paths like `"\\.\C:/foo"` and `"\\localhost\\\\\\C$\foo"` are valid on Windows, they are equivalent to just `"C:\foo"`.
**Refactoring**:
All uses of `&[u8]` within `parse_prefix` are extracted to helper functions and`&OsStr` is used instead. This reduces the number of places unsafe is used:
- `get_first_two_components` is adapted to the more general `parse_next_component` and used in more places
- code for parsing drive prefixes is extracted to `parse_drive`
Joshua Nelson [Fri, 4 Dec 2020 01:14:11 +0000 (20:14 -0500)]
Don't look for blanket impls in intra-doc links
This never worked and has been causing severe performance problems.
Hopefully it will be re-landed at some point in the future when it
actually works, but in the meantime it makes no sense to have the code
around when it does nothing and actively makes rustdoc harder to use.
bors [Tue, 15 Dec 2020 22:00:02 +0000 (22:00 +0000)]
Auto merge of #78399 - vn-ki:gsgdt-graphviz, r=oli-obk
make MIR graphviz generation use gsgdt
gsgdt [https://crates.io/crates/gsgdt] is a crate which provides an
interface for stringly typed graphs. It also provides generation of
graphviz dot format from said graph.
This is the first in a series of PRs on moving graphviz code out of rustc into normal crates and then implementating graph diffing on top of these crates.
bors [Tue, 15 Dec 2020 15:58:46 +0000 (15:58 +0000)]
Auto merge of #80055 - GuillaumeGomez:rollup-p09mweg, r=GuillaumeGomez
Rollup of 6 pull requests
Successful merges:
- #79379 (Show hidden elements by default when JS is disabled)
- #79796 (Hide associated constants too when collapsing implementation)
- #79958 (Fixes reported bugs in Rust Coverage)
- #80008 (Fix `cargo-binutils` link)
- #80016 (Use imports instead of rewriting the type signature of `RustcOptGroup::stable`)
- #80025 (Replace some `println!` with `tidy_error!` to simplify)
Guillaume Gomez [Tue, 15 Dec 2020 15:43:23 +0000 (16:43 +0100)]
Rollup merge of #79958 - richkadel:llvm-coverage-counters-2.2.0, r=tmandry
Fixes reported bugs in Rust Coverage
Fixes: #79569 Fixes: #79566 Fixes: #79565
For the first issue (#79569), I got hit a `debug_assert!()` before
encountering the reported error message (because I have `debug = true`
enabled in my config.toml).
The assertion showed me that some `SwitchInt`s can have more than one
target pointing to the same `BasicBlock`.
I had thought that was invalid, but since it seems to be possible, I'm
allowing this now.
I added a new test for this.
----
In the last two cases above, both tests (intentionally) fail to compile,
but the `InstrumentCoverage` pass is invoked anyway.
The MIR starts with an `Unreachable` `BasicBlock`, which I hadn't
encountered before. (I had assumed the `InstrumentCoverage` pass
would only be invoked with MIRs from successful compilations.)
I don't have test infrastructure set up to test coverage on files that
fail to compile, so I didn't add a new test.
bors [Tue, 15 Dec 2020 11:31:03 +0000 (11:31 +0000)]
Auto merge of #78068 - RalfJung:union-safe-assign, r=nikomatsakis
consider assignments of union field of ManuallyDrop type safe
Assigning to `Copy` union fields is safe because that assignment will never drop anything. However, with https://github.com/rust-lang/rust/pull/77547, unions may also have `ManuallyDrop` fields, and their assignments are currently still unsafe. That seems unnecessary though, as assigning `ManuallyDrop` does not drop anything either, and is thus safe even for union fields.
bors [Tue, 15 Dec 2020 08:46:00 +0000 (08:46 +0000)]
Auto merge of #73210 - wesleywiser:consts_in_debuginfo, r=oli-obk
[mir-opt] Allow debuginfo to be generated for a constant or a Place
Prior to this commit, debuginfo was always generated by mapping a name
to a Place. This has the side-effect that `SimplifyLocals` cannot remove
locals that are only used for debuginfo because their other uses have
been const-propagated.
To allow these locals to be removed, we now allow debuginfo to point to
a constant value. The `ConstProp` pass detects when debuginfo points to
a local with a known constant value and replaces it with the value. This
allows the later `SimplifyLocals` pass to remove the local.
bors [Tue, 15 Dec 2020 06:32:10 +0000 (06:32 +0000)]
Auto merge of #78682 - glandium:issue78471, r=lcnr
Do not inline finish_grow
Fixes #78471.
Looking at libgkrust.a in Firefox, the sizes for the `gkrust.*.o` file is:
- 18584816 (text) 582418 (data) with unmodified master
- 17937659 (text) 582554 (data) with #72227 reverted
- 17968228 (text) 582858 (data) with `#[inline(never)]` on `grow_amortized` and `grow_exact`, but that has some performance consequences
- 17927760 (text) 582322 (data) with this change
So in terms of size, at least in the case of Firefox, this patch more than undoes the regression. I don't think it should affect performance, but we'll see.