Yuki Okushi [Fri, 7 May 2021 06:20:26 +0000 (15:20 +0900)]
Rollup merge of #84897 - richkadel:cover-closure-macros, r=tmandry
Coverage instruments closure bodies in macros (not the macro body)
Fixes: #84884
This solution might be considered a compromise, but I think it is the
better choice.
The results in the `closure.rs` test correctly resolve all test cases
broken as described in #84884.
One test pattern (in both `closure_macro.rs` and
`closure_macro_async.rs`) was also affected, and removes coverage
statistics for the lines inside the closure, because the closure
includes a macro. (The coverage remains at the callsite of the macro, so
we lose some detail, but there isn't a perfect choice with macros.
Often macro implementations are split across the macro and the callsite,
and there doesn't appear to be a single "right choice" for which body
should be covered. For the current implementation, we can't do both.
The callsite is most likely to be the preferred site for coverage.
Yuki Okushi [Fri, 7 May 2021 06:20:25 +0000 (15:20 +0900)]
Rollup merge of #84875 - richkadel:no-coverage-dont-check-unused, r=tmandry
Removes unneeded check of `#[no_coverage]` in mapgen
There is an anticipated feature request to support a compiler flag that
only adds coverage for specific files (or perhaps mods). As I thought
about where that change would need to be supported, I realized that
checking the attribute in mapgen (for unused functions) was unnecessary.
The unused functions are only synthesized if they have MIR coverage, and
functions with the `no_coverage` attribute will not have been
instrumented with MIR coverage statements in the first place.
New tests confirm this.
Also, while adding tests, I updated resolved comments and FIXMEs in
other tests, and expanded comments and tests on one remaining issue that
is still not resolved.
bors [Fri, 7 May 2021 01:16:08 +0000 (01:16 +0000)]
Auto merge of #85014 - Dylan-DPC:rollup-jzpbkdu, r=Dylan-DPC
Rollup of 11 pull requests
Successful merges:
- #84409 (Ensure TLS destructors run before thread joins in SGX)
- #84500 (Add --run flag to compiletest)
- #84728 (Add test for suggestion to borrow unsized function parameters)
- #84734 (Add `needs-unwind` and beginning of support for testing `panic=abort` std to compiletest)
- #84755 (Allow using `core::` in intra-doc links within core itself)
- #84871 (Disallows `#![feature(no_coverage)]` on stable and beta (using standard crate-level gating))
- #84872 (Wire up tidy dependency checks for cg_clif)
- #84896 (Handle incorrect placement of parentheses in trait bounds more gracefully)
- #84905 (CTFE engine: rename copy → copy_intrinsic, move to intrinsics.rs)
- #84953 (Remove unneeded call to with_default_session_globals in rustdoc highlight)
- #84987 (small nits)
Both libc and libgcc_s provide an unwinder implementation, but libgcc_s
provides some extra symbols upon which Rust directly depends. If libc
is first in the NEEDED list we will find some of those symbols in libc
but others in libgcc_s, resulting in undefined behaviour as the two
implementations do not use compatible interior data structures.
This solution is not perfect, but is the simplest way to produce correct
binaries on illumos for now.
Dylan DPC [Thu, 6 May 2021 22:38:43 +0000 (00:38 +0200)]
Rollup merge of #84905 - RalfJung:copy, r=oli-obk
CTFE engine: rename copy → copy_intrinsic, move to intrinsics.rs
The `copy` name is confusing for this function because we also have `copy_op` which is pretty different. I hope `copy_intrinsic` is clearer. Also `step.rs` should really just contain the main loop and opcode dispatch, so move this helper function to a more appropriate place.
Dylan DPC [Thu, 6 May 2021 22:38:40 +0000 (00:38 +0200)]
Rollup merge of #84871 - richkadel:no-coverage-unstable-only, r=nagisa
Disallows `#![feature(no_coverage)]` on stable and beta (using standard crate-level gating)
Fixes: #84836
Removes the function-level feature gating solution originally implemented, and solves the same problem using `allow_internal_unstable`, so normal crate-level feature gating mechanism can still be used (which disallows the feature on stable and beta).
I tested this, building the compiler with and without `CFG_DISABLE_UNSTABLE_FEATURES=1`
With unstable features disabled, I get the expected result as shown here:
```shell
$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc src/test/run-make-fulldeps/coverage/no_cov_crate.rs
error[E0554]: `#![feature]` may not be used on the dev release channel
--> src/test/run-make-fulldeps/coverage/no_cov_crate.rs:2:1
|
2 | #![feature(no_coverage)]
| ^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0554`.
```
Dylan DPC [Thu, 6 May 2021 22:38:38 +0000 (00:38 +0200)]
Rollup merge of #84755 - jyn514:core-links, r=kennytm
Allow using `core::` in intra-doc links within core itself
I came up with this idea ages ago, but rustdoc used to ICE on it. Now it doesn't.
Helps with https://github.com/rust-lang/rust/issues/73445. Doesn't fix it completely since `extern crate self as std;` in std still gives strange errors.
Dylan DPC [Thu, 6 May 2021 22:38:37 +0000 (00:38 +0200)]
Rollup merge of #84734 - tmandry:compiletest-needs-unwind, r=Mark-Simulacrum
Add `needs-unwind` and beginning of support for testing `panic=abort` std to compiletest
For the Fuchsia platform we build libstd with `panic=abort` and would like a way to run tests with that enabled. This adds low-level support for this directly to compiletest.
In the future I'd like to add high-level support in rustbuild, e.g. having target-specific flags that allow configuring a panic strategy. (Side note: It would be nice if we could also build multiple configurations for the same target, but I'm getting ahead of myself.)
This plus #84500 have everything that's needed to get ui tests passing on fuchsia targets.
Part of #84766. Note that this change only includes the header on tests which need an unwinder to _build_, not those which need it to _run_.
Dylan DPC [Thu, 6 May 2021 22:38:36 +0000 (00:38 +0200)]
Rollup merge of #84728 - camelid:sized-param-sugg-test, r=Mark-Simulacrum
Add test for suggestion to borrow unsized function parameters
Closes #82820.
This is a regression test for #82820.
This test case is included in more general tests, but I think the error
regressed because there were a bunch of other diagnostic changes in the
test that obscured this regression.
Hopefully, having a test specific to the suggestion, and running rustfix
for the test, will prevent this error from regressing in the future.
Rich Kadel [Mon, 3 May 2021 18:23:40 +0000 (11:23 -0700)]
Removes unneeded check of `#[no_coverage]` in mapgen
And adds tests to validate it still works.
There is an anticipated feature request to support a compiler flag that
only adds coverage for specific files (or perhaps mods). As I thought
about where that change would need to be supported, I realized that
checking the attribute in mapgen (for unused functions) was unnecessary.
The unused functions are only synthesized if they have MIR coverage, and
functions with the `no_coverage` attribute will not have been
instrumented with MIR coverage statements in the first place.
New tests confirm this.
Also, while adding tests, I updated resolved comments and FIXMEs in
other tests.
Add test for suggestion to borrow unsized function parameters
This is a regression test for #82820.
This test case is included in more general tests, but I think the error
regressed because there were a bunch of other diagnostic changes in the
test that obscured this regression.
Hopefully, having a test specific to the suggestion, and running rustfix
for the test, will prevent this error from regressing in the future.
Rich Kadel [Tue, 4 May 2021 06:21:24 +0000 (23:21 -0700)]
Coverage instruments closure bodies in macros (not the macro body)
Fixes: #84884
This solution might be considered a compromise, but I think it is the
better choice.
The results in the `closure.rs` test correctly resolve all test cases
broken as described in #84884.
One test pattern (in both `closure_macro.rs` and
`closure_macro_async.rs`) was also affected, and removes coverage
statistics for the lines inside the closure, because the closure
includes a macro. (The coverage remains at the callsite of the macro, so
we lose some detail, but there isn't a perfect choice with macros.
Often macro implementations are split across the macro and the callsite,
and there doesn't appear to be a single "right choice" for which body
should be covered. For the current implementation, we can't do both.
The callsite is most likely to be the preferred site for coverage.
I applied this fix to all `MacroKinds`, not just `Bang`.
I'm trying to resolve an issue of lost coverage in a
`MacroKind::Attr`-based, function-scoped macro. Instead of only
searching for a body_span that is "not a function-like macro" (that is,
MacroKind::Bang), I'm expanding this to all `MacroKind`s. Maybe I should
expand this to `ExpnKind::Desugaring` and `ExpnKind::AstPass` (or
subsets, depending on their sub-kinds) as well, but I'm not sure that's
a good idea.
I'd like to add a test of the `Attr` macro on functions, but I need time
to figure out how to constract a good, simple example without external
crate dependencies. For the moment, all tests still work as expected (no
change), this new commit shouldn't have a negative affect, and more
importantly, I believe it will have a positive effect. I will try to
confirm this.
bors [Thu, 6 May 2021 17:42:32 +0000 (17:42 +0000)]
Auto merge of #84559 - jackh726:issue-84398, r=nikomatsakis
Deduplicate ParamCandidates with the same value except for bound vars
Fixes #84398
This is kind of a hack. I wonder if we can get other types of candidates that are the same except for bound vars. This won't be a problem with Chalk, since we don't really need to know that there are two different "candidates" if they both give the same final substitution.
Alex Crichton [Thu, 6 May 2021 15:47:55 +0000 (08:47 -0700)]
rustc: Support Rust-specific features in -Ctarget-feature
Since the beginning of time the `-Ctarget-feature` flag on the command
line has largely been passed unmodified to LLVM. Afterwards, though, the
`#[target_feature]` attribute was stabilized and some of the names in
this attribute do not match the corresponding LLVM name. This is because
Rust doesn't always want to stabilize the exact feature name in LLVM for
the equivalent functionality in Rust. This creates a situation, however,
where in Rust you'd write:
This difference is somewhat odd to deal with if you're a newcomer and
the situation may be made worse with upcoming features like [WebAssembly
SIMD](https://github.com/rust-lang/rust/issues/74372) which may be more
prevalent.
This commit implements a mapping to translate requests via
`-Ctarget-feature` through the same name-mapping functionality that's
present for attributes in Rust going to LLVM. This means that
`+pclmulqdq` will work on x86 targets where as previously it did not.
I've attempted to keep this backwards-compatible where the compiler will
just opportunistically attempt to remap features found in
`-Ctarget-feature`, but if there's something it doesn't understand it
gets passed unmodified to LLVM just as it was before.
Dylan DPC [Thu, 6 May 2021 11:31:01 +0000 (13:31 +0200)]
Rollup merge of #84950 - pietroalbini:revert-3478f83c0, r=Mark-Simulacrum
Revert PR 83866
https://github.com/rust-lang/rust/pull/83866 caused multiple test failures when Rust's channel is changed from nightly to anything else. The PR will have to be landed again after the test suite is fixed.
The two kinds of test failures were:
* Rustdoc tests failed because the links in the generated HTML didn't point at nightly anymore, see https://github.com/rust-lang/rust/pull/84909#issuecomment-832028701
* Rustdoc UI tests failed because the links included in error messages didn't point at nightly anymore, see https://github.com/rust-lang/rust/pull/84909#issuecomment-832517722
Introduces feature flags for the general syntax (`native_link_modifiers`) and each modifier (`native_link_modifiers_{as_needed,bundle,verbatim,whole_archive}`).
For certain sorts of systems, programming, it's deemed essential that
all allocation failures be explicitly handled where they occur. For
example, see Linus Torvald's opinion in [1]. Merely not calling global
panic handlers, or always `try_reserving` first (for vectors), is not
deemed good enough, because the mere presence of the global OOM handlers
is burdens static analysis.
One option for these projects to use rust would just be to skip `alloc`,
rolling their own allocation abstractions. But this would, in my
opinion be a real shame. `alloc` has a few `try_*` methods already, and
we could easily have more. Features like custom allocator support also
demonstrate and existing to support diverse use-cases with the same
abstractions.
A natural way to add such a feature flag would a Cargo feature, but
there are currently uncertainties around how std library crate's Cargo
features may or not be stable, so to avoid any risk of stabilizing by
mistake we are going with a more low-level "raw cfg" token, which
cannot be interacted with via Cargo alone.
Note also that since there is no notion of "default cfg tokens" outside
of Cargo features, we have to invert the condition from
`global_oom_handling` to to `not(no_global_oom_handling)`. This breaks
the monotonicity that would be important for a Cargo feature (i.e.
turning on more features should never break compatibility), but it
doesn't matter for raw cfg tokens which are not intended to be
"constraint solved" by Cargo or anything else.
To support this use-case we create a new feature, "global-oom-handling",
on by default, and put the global OOM handler infra and everything else
it that depends on it behind it. By default, nothing is changed, but
users concerned about global handling can make sure it is disabled, and
be confident that all OOM handling is local and explicit.
For this first iteration, non-flat collections are outright disabled.
`Vec` and `String` don't yet have `try_*` allocation methods, but are
kept anyways since they can be oom-safely created "from parts", and we
hope to add those `try_` methods in the future.
Luqman Aden [Thu, 25 Mar 2021 04:45:09 +0000 (21:45 -0700)]
Implement RFC 2951: Native link modifiers
This commit implements both the native linking modifiers infrastructure
as well as an initial attempt at the individual modifiers from the RFC.
It also introduces a feature flag for the general syntax along with
individual feature flags for each modifier.
The8472 [Wed, 5 May 2021 20:52:58 +0000 (22:52 +0200)]
lazify backtrace formatting for delayed diagnostics
This defers backtrace formatting to the point where we
actually want to flush delayed diagnostics. If they are discarded
before that point then we can avoid invoking the backtrace formatting
machinery which will parse debug info and symbol tables.
for debuginfo=2 this leads to a 20% walltime reduction of the UI testsuite
For certain sorts of systems, programming, it's deemed essential that
all allocation failures be explicitly handled where they occur. For
example, see Linus Torvald's opinion in [1]. Merely not calling global
panic handlers, or always `try_reserving` first (for vectors), is not
deemed good enough, because the mere presence of the global OOM handlers
is burdens static analysis.
One option for these projects to use rust would just be to skip `alloc`,
rolling their own allocation abstractions. But this would, in my
opinion be a real shame. `alloc` has a few `try_*` methods already, and
we could easily have more. Features like custom allocator support also
demonstrate and existing to support diverse use-cases with the same
abstractions.
A natural way to add such a feature flag would a Cargo feature, but
there are currently uncertainties around how std library crate's Cargo
features may or not be stable, so to avoid any risk of stabilizing by
mistake we are going with a more low-level "raw cfg" token, which
cannot be interacted with via Cargo alone.
Note also that since there is no notion of "default cfg tokens" outside
of Cargo features, we have to invert the condition from
`global_oom_handling` to to `not(no_global_oom_handling)`. This breaks
the monotonicity that would be important for a Cargo feature (i.e.
turning on more features should never break compatibility), but it
doesn't matter for raw cfg tokens which are not intended to be
"constraint solved" by Cargo or anything else.
To support this use-case we create a new feature, "global-oom-handling",
on by default, and put the global OOM handler infra and everything else
it that depends on it behind it. By default, nothing is changed, but
users concerned about global handling can make sure it is disabled, and
be confident that all OOM handling is local and explicit.
For this first iteration, non-flat collections are outright disabled.
`Vec` and `String` don't yet have `try_*` allocation methods, but are
kept anyways since they can be oom-safely created "from parts", and we
hope to add those `try_` methods in the future.
bors [Wed, 5 May 2021 17:45:41 +0000 (17:45 +0000)]
Auto merge of #84956 - RalfJung:rollup-m70mx2n, r=RalfJung
Rollup of 11 pull requests
Successful merges:
- #83553 (Update `ptr` docs with regards to `ptr::addr_of!`)
- #84183 (Update RELEASES.md for 1.52.0)
- #84709 (Add doc alias for `chdir` to `std::env::set_current_dir`)
- #84803 (Reduce duplication in `impl_dep_tracking_hash` macros)
- #84808 (Account for unsatisfied bounds in E0599)
- #84843 (use else if in std library )
- #84865 (rustbuild: Pass a `threads` flag that works to windows-gnu lld)
- #84878 (Clarify documentation for `[T]::contains`)
- #84882 (platform-support: Center the contents of the `std` and `host` columns)
- #84903 (Remove `rustc_middle::mir::interpret::CheckInAllocMsg::NullPointerTest`)
- #84913 (Do not ICE on invalid const param)
bors [Wed, 5 May 2021 17:33:46 +0000 (17:33 +0000)]
Auto merge of #7170 - flip1995:revert_drop_order, r=llogiq
Fix stack overflow issue in `redundant_pattern_matching`
Fixes #7169
~~cc `@Jarcho` Since tomorrow is release day and we need to get this also fixed in beta, I'll just revert the PR instead of looking into the root issue. Your changes are good, so if you have an idea what could cause this stack overflow and know how to fix it, please open a PR that reverts this revert with a fix.~~
r? `@llogiq`
changelog: none (fixes stack overflow, but this was introduced in this release cycle)
bors [Wed, 5 May 2021 17:11:14 +0000 (17:11 +0000)]
Auto merge of #6887 - xFrednet:4310-internal-metadata-extraction-lint, r=xFrednet
A metadata collection monster
This PR introduces a metadata collection lint as discussed in #4310. It currently collects:
* The lint ID
* The lint declaration file and location (for #1303)
* The lint group
* The documentation
* The applicability (if resolvable)
* If the suggestion is a multi-part-suggestion
This data has a slightly different structure than the current [lints.json](https://github.com/rust-lang/rust-clippy/blob/gh-pages/master/lints.json) and doesn't include depreciated lints yet. I plan to adapt the website to the new format and include depreciated lints in a follow-up PR :). The current collected json looks like this: [metadata_collection.json](https://gist.github.com/xFrednet/6b9e2c3f725f476ba88db9563f67e119)
The entire implementation is guarded behind the `metadata-collector-lint` feature and the `ENABLE_METADATA_COLLECTION` environment value to prevent default collection. You can test the implementation via:
```sh
$ ENABLE_METADATA_COLLECTION=1 cargo test --test dogfood --all-features
```
changelog: none
---
The size of this PR sadly also grew into a small monster, sorry! I definitely plan to improve on this! And it's totally okay if you take your time with this :)
Ralf Jung [Wed, 5 May 2021 15:52:29 +0000 (17:52 +0200)]
Rollup merge of #84913 - estebank:issue-84831, r=varkor
Do not ICE on invalid const param
When encountering a path that can't have generics, do not call
`generics_of`. This would happen when writing something like
`path::this_is_a_mod<const_val>`.
Removing it per https://github.com/rust-lang/rust/pull/84842#discussion_r625589674: it's a dead enum variant.
Note that `PointerArithmeticTest` also seems dead:
```
$ rg -F PointerArithmeticTest -C5
compiler/rustc_middle/src/mir/interpret/error.rs
169-
170-/// Details of why a pointer had to be in-bounds.
171-#[derive(Debug, Copy, Clone, TyEncodable, TyDecodable, HashStable)]
172-pub enum CheckInAllocMsg {
173- MemoryAccessTest,
174: PointerArithmeticTest,
175- InboundsTest,
176-}
177-
178-impl fmt::Display for CheckInAllocMsg {
179- /// When this is printed as an error the context looks like this
--
182- write!(
183- f,
184- "{}",
185- match *self {
186- CheckInAllocMsg::MemoryAccessTest => "memory access",
187: CheckInAllocMsg::PointerArithmeticTest => "pointer arithmetic",
188- CheckInAllocMsg::InboundsTest => "inbounds test",
189- }
190- )
191- }
192-}
```
Not sure if that is also desirable to be removed, however.
Ralf Jung [Wed, 5 May 2021 15:52:25 +0000 (17:52 +0200)]
Rollup merge of #84865 - petrochenkov:llthread, r=Mark-Simulacrum
rustbuild: Pass a `threads` flag that works to windows-gnu lld
MinGW driver for COFF LLD doesn't currently translate GNU-style `--threads=N` to native `/threads:N`, so we have to pass the option in its native form to avoid an error.
Also pass the `threads` flag to lld-link (windows-msvc lld) as well.
projects / rust.git / log