Ignore commented out lines when finding features
This fixes#76246, where commented out lines were being detected as features by `tidy`, by ignoring those lines when looking for features. It's still not perfect, since it can be fooled by things like:
```rust
/*
#[unstable(feature = "foo", issue = "1234")]
*/
```
But luckily that never happens in `rustc`, so `foo` now ceases to appear in the unstable book.
`test tidy` should ignore alternative `build` dir patterns
I need to have multiple `build` directories, such as `build`,
`build-fuchsia`, and `build-test`. But when I'm uploading a change, I
run `./x.py test tidy`, and if I have a `build-something` directory with
Rust sources, I git a bunch of formatting errors.
`rustfmt.toml` only ignores the directory named `build`.
This change extends the patterns to also ignore `build-*` and `*-build`.
As a rustc contributor, I not only build the rust compiler to develop
new features, but I also build alternative "distributions" (using
secondary `*-config.toml` files with different configurations),
including:
* To occasionally rebuild a version of the compiler that `rust-analyzer`
can use to `check` source (which fixes issues in the VS Code UI, so
changing and rebuilding the compiler does not break VS Code editing Rust
code).
* To build custom distributions for Fuchsia
* To build test distributions when working on changes to `bootstrap`
(e.g., when I recently added `rust-demangler` to distributions)
Don't rebuild rustdoc and clippy after checking bootstrap
This works by unconditionally passing -Z unstable-options to the
compiler. This has no affect in practice since bootstrap doesn't use
`deny(rustc::internal)`.
Fixes https://github.com/rust-lang/rust/issues/82461.
r? ```@Mark-Simulacrum```
don't enable parking_lot nightly features
Having the compiler itself depend on external libraries that use nightly features can lead to "fun" bootstrap situations. Within the rustc repo we use `cfg(bootstrap)` to resolve those, but that is not a reasonable option for external dependencies.
So I propose we stop enabling the "nightly" feature of `parking_lot` here. In my experiments, this then indeed leads to the feature not being enabled (i.e., nothing else enables it), and everything still builds. However, this means parking_lot's `RwLock` will no longer have hardware lock elision for readers -- I hope that is okay to lose in exchange for less bootstrap brain twisting. ;)
Cc `@Amanieu`
Simplify `Mutex::into_inner`
Thanks to #77147, `Mutex` do not implement `Drop` directly, so the old unsafe implementation of `into_inner` is not relevant anymore.
Adds feature-gated `#[no_coverage]` function attribute, to fix derived Eq `0` coverage issue #83601
Derived Eq no longer shows uncovered
The Eq trait has a special hidden function. MIR `InstrumentCoverage`
would add this function to the coverage map, but it is never called, so
the `Eq` trait would always appear uncovered.
Fixes: #83601
The fix required creating a new function attribute `no_coverage` to mark
functions that should be ignored by `InstrumentCoverage` and the
coverage `mapgen` (during codegen).
Adding a `no_coverage` feature gate with tracking issue #84605.
r? `@tmandry`
cc: `@wesleywiser`
Improve coverage spans for chained function calls
Fixes: #84180
For chained function calls separated by the `?` try operator, the
function call following the try operator produced a MIR `Call` span that
matched the span of the first call. The `?` try operator started a new
span, so the second call got no span.
It turns out the MIR `Call` terminator has a `func` `Operand`
for the `Constant` representing the function name, and the function
name's Span can be used to reset the starting position of the span.
r? `@tmandry`
cc: `@wesleywiser`
Revert "Rollup merge of #82296 - spastorino:pubrules, r=nikomatsakis"
This reverts commit e2561c58a41023a14e0e583113dcf55e1ecb236a, reversing
changes made to 2982ba50fc4bb629b8fe4108a81cb2f9b053510b.
As discussed in #83641 this feature is not complete and in particular doesn't work cross macros and given that this is not going to be included in edition 2021 nobody seems to be trying to fix the underlying problem. When can add this again I guess, whenever somebody has the time to make it work cross crates.
r? `@nikomatsakis`
Update grab bag
This PR slides a bunch of crate versions forward until suddenly a bunch of deps fall out of the tree!
In doing so this mostly picks up a version bump in the `redox_users` crate which makes most of the features default to optional.
crossbeam-utils 0.7 => 0.8.3 (where applicable)
https://github.com/crossbeam-rs/crossbeam/blob/master/crossbeam-utils/CHANGELOG.md
directories 3.0.1 => 3.0.2
ignore 0.4.16 => 0.4.17
tempfile 3.0.5 => tempfile 3.2
Removes constant_time_eq from deps exceptions
Removes arrayref from deps exceptions
And also removes:
- blake2b_simd
- const_fn (the package, not the feature)
- constant_time_eq
- redox_users 0.3.4
- rust-argon2
Update cargo
5 commits in 0ed318d182e465cd66071b91ac3d265af63ef8a1..4369396ce7d270972955d876eaa4954bea56bcd9
2021-04-23 20:54:54 +0000 to 2021-04-27 14:35:53 +0000
- Fix rebuild issues with rustdoc. (rust-lang/cargo#9419)
- Always use full metadata hash for -C metadata. (rust-lang/cargo#9418)
- Expose build.target .cargo/config setting as packages.target in Cargo.toml (rust-lang/cargo#9030)
- Some changes to rustdoc fingerprint checking. (rust-lang/cargo#9404)
- Document that CARGO_PKG_ are availble to build.rs (rust-lang/cargo#9405)
The Eq trait has a special hidden function. MIR `InstrumentCoverage`
would add this function to the coverage map, but it is never called, so
the `Eq` trait would always appear uncovered.
Fixes: #83601
The fix required creating a new function attribute `no_coverage` to mark
functions that should be ignored by `InstrumentCoverage` and the
coverage `mapgen` (during codegen).
While testing, I also noticed two other issues:
* spanview debug file output ICEd on a function with no body. The
workaround for this is included in this PR.
* `assert_*!()` macro coverage can appear covered if followed by another
`assert_*!()` macro. Normally they appear uncovered. I submitted a new
Issue #84561, and added a coverage test to demonstrate this issue.
