Simplify bootstrap `--check-cfg` arguments
This PR simplifies the generated check-cfg arguments generated for the no-values case.
For the `bootstrap` cfg:
```diff
- --check-cfg=cfg(bootstrap,values())
+ --check-cfg=cfg(bootstrap)
```
Those are equivalent, so there isn't any semantic difference; but the invocation is short and less distracting.
`@rustbot` label +F-check-cfg
Fix `<BoundConstness as Display>`
There was infinite recursion, which is not very good. I'm not sure what the best way to implement this is, I just did something that felt right.
r? `@fmease`
Move around the code responsible for decorating builtin diagnostics
This PR move the code responsible for decorating builtin diagnostics into a separate sub-module for ease of use and readability.
While my original intention was to also move the check-cfg unexpected logic in their own function I changed my mind after moving the match altogether. I can move those if desired.
Fixes https://github.com/rust-lang/rust/pull/119425#discussion_r1438446596
r? `@Nilstrieb`
Update to bitflags 2 in the compiler
This involves lots of breaking changes. There are two big changes that force changes. The first is that the bitflag types now don't automatically implement normal derive traits, so we need to derive them manually.
Additionally, bitflags now have a hidden inner type by default, which breaks our custom derives. The bitflags docs recommend using the impl form in these cases, which I did.
r? compiler
This involves lots of breaking changes. There are two big changes that
force changes. The first is that the bitflag types now don't
automatically implement normal derive traits, so we need to derive them
manually.
Additionally, bitflags now have a hidden inner type by default, which
breaks our custom derives. The bitflags docs recommend using the impl
form in these cases, which I did.
openbsd: available_parallelism: use the right API
use the standard `sysconf(_SC_NPROCESSORS_ONLN)` way to get the number of available processors (capable of running processes), and fallback to `sysctl([CTL_HW, HW_NCPU])` (number of CPUs configured) only on error.
it permits to differenciate CPUs online (capable of running processes) vs CPUs configured (not necessary capable of running processes).
while here, use the common code path for BSDs for doing that, and avoid code duplication.
Problem initially reported to me by Jiri Navratil.
coverage: Prepare mappings separately from injecting statements
These two tasks historically needed to be interleaved, but after various recent changes (including #116046 and #116917) they can now be fully separated.
---
`@rustbot` label +A-code-coverage
These two tasks historically needed to be interleaved, but after various recent
changes (including #116046 and #116917) they can now be fully separated.
Fix invalid check-cfg Cargo feature diagnostic help
#118213 added specialized diagnostic for Cargo `feature` cfg. However when providing an empty `#[cfg(feature)]` condition the suggestion would suggest adding `feature` as a feature in `Cargo.toml` (wtf!).
This PR removes the invalid logic, which even brings a nice improvement.
```diff
--> $DIR/cargo-feature.rs:18:7
|
LL | #[cfg(feature)]
- | ^^^^^^^
+ | ^^^^^^^- help: specify a config value: `= "bitcode"`
|
= note: expected values for `feature` are: `bitcode`
- = help: consider defining `feature` as feature in `Cargo.toml`
```
The first commit add a test showing the bug and the second commit fixes the bug.
`@rustbot` label +F-check-cfg
Primitive docs: fix confusing `Send` in `&T`'s list
The two lists in this document describe what traits are implemented on references when their underlying `T` also implements them. However, while it is true that `T: Send + Sync` implies `&T: Send` (which is what the sentence is trying to explain), it is confusing to have `Send` in the list because `T: Send` is not needed for that. In particular, the "also require" part may be interpreted as "both `T: Send` and `T: Sync` are required".
Instead, move `Send` back to where it was before commit 7a477869b7 ("Makes docs for references a little less confusing"), i.e. to the `&mut` list (where no extra nota is needed, i.e. it fits naturally) and move the `Sync` definition/note to the bottom as something independent.
solaris support on bootstrap lock
With https://github.com/yoshuawuyts/fd-lock/pull/48, `fd-lock` now supports Solaris. Therefore we no longer need to conditionally handle the bootstrap locks.
Clean up alloc::sync::Weak Clone implementation
Since both return points (tail and early return) return the same expression and the only difference is whether inner is available, the code that does the atomic operations and checks on inner was moved into the if body and the only return is at the tail. Original comments preserved.
use the standard sysconf(_SC_NPROCESSORS_ONLN) way to get the number of
available processors (capable of running processes), and fallback to
sysctl([CTL_HW, HW_NCPU]) (number of CPUs configured) only on error.
it permits to differenciate CPUs online vs CPUs configured (and not necessary
capable of running processes).
while here, use the common code path for BSDs for doing that, and avoid code
duplication.
Problem initially reported to me by Jiri Navratil.
Shrink span encoding further
Spans are now stored in a more compact form which cuts down on at least 1 byte per span (indirect/direct encoding) and at most 3 bytes per span (indirect/direct encoding, context byte, length byte). As a result, libcore metadata shrinks by 1.5MB.
I'm not a huge fan of the fairly manual encoding/decoding from bits implemented here. Something like Tokio's pack abstraction (https://github.com/tokio-rs/tokio/blob/master/tokio/src/util/bit.rs) might be desirable to cut down on some of the shifting etc. We might also say that this isn't worth doing :)
I took a look at copying the span encoding we use in memory (described [here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_span/src/span_encoding.rs)). I think the format there makes a lot more sense for in-memory storage where prioritizing a fixed length (i.e., 4 or 8 bytes) is much more important. In metadata, it's much easier for us to have variable-length values, so there's less of a cliff if we don't quite fit. The bit packing scheme there would need changes to fit the varint scheme since it has a lot of all-1s patterns as the "relative offset" form.
Implement constant propagation on top of MIR SSA analysis
This implements the idea I proposed in https://github.com/rust-lang/rust/pull/110719#issuecomment-1718324700
Based on https://github.com/rust-lang/rust/pull/109597
The value numbering "GVN" pass formulates each rvalue that appears in MIR with an abstract form (the `Value` enum), and assigns an integer `VnIndex` to each. This abstract form can be used to deduplicate values, reusing an earlier local that holds the same value instead of recomputing. This part is proposed in #109597.
From this abstract representation, we can perform more involved simplifications, for example in https://github.com/rust-lang/rust/pull/111344.
With the abstract representation `Value`, we can also attempt to evaluate each to a constant using the interpreter. This builds a `VnIndex -> OpTy` map. From this map, we can opportunistically replace an operand or a rvalue with a constant if their value has an associated `OpTy`.
The most relevant commit is [Evaluated computed values to constants.](2767c4912e)"
r? `@oli-obk`
Spans are now stored in a more compact form which cuts down on at least
1 byte per span (indirect/direct encoding) and at most 3 bytes per span
(indirect/direct encoding, context byte, length byte). As a result,
libcore metadata shrinks by 1.5MB.
Rollup of 5 pull requests
Successful merges:
- #119322 (Couple of random coroutine pass simplifications)
- #119374 (Italicise "bytes" in the docs of some `Vec` methods)
- #119388 (rustc_lint: Prevent triplication of various lints)
- #119406 (Add non-regression test for ATPIT ICE #114325)
- #119410 (Rename test to be more descriptive)
r? `@ghost`
`@rustbot` modify labels: rollup
The two lists in this document describe what traits are implemented on
references when their underlying `T` also implements them. However,
while it is true that `T: Send + Sync` implies `&T: Send` (which is
what the sentence is trying to explain), it is confusing to have `Send`
in the list because `T: Send` is not needed for that. In particular,
the "also require" part may be interpreted as "both `T: Send` and
`T: Sync` are required".
Instead, move `Send` back to where it was before commit 7a477869b7
("Makes docs for references a little less confusing"), i.e. to the `&mut`
list (where no extra nota is needed, i.e. it fits naturally) and move the
`Sync` definition/note to the bottom as something independent.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
rustc_lint: Prevent triplication of various lints
Prevent triplication of various lints. The triplication happens because we run the same lint three times (or less in some cases):
* In `BuiltinCombinedPreExpansionLintPass`
* In `BuiltinCombinedEarlyLintPass`
* In `shallow_lint_levels_on()`
Only run the lints one time by checking the `lint_added_lints` bool.
Set your GitHub diff setting to ignore whitespaces changes when reviewing this PR, since I had to enclose a block inside an if.
Closes#73301
(I found this while exploring the code related to [this](https://github.com/rust-lang/rust/pull/119251#discussion_r1435677330) comment.)
Italicise "bytes" in the docs of some `Vec` methods
On a cursory read it's easy to miss that the limit is in terms of bytes not no. of elements. The italics should help with that.
Fixes#119149
Remove usage of deprecated `missing-tools` bootstrap flag
This PR removes the usage of `--enable-missing-tools` in CI, as this config option is no longer used. It also removes `dist.missing-tools` config completely.
Let me know which commits should I remove (if any).
Fixes: https://github.com/rust-lang/rust/issues/79249
r? `@onur-ozkan`
Also walk bindings created by if-let guards
This change makes the `unused_variables` lint pick up unused bindings created by if-let guards.
Fixes#119383
coverage: Avoid a possible query stability hazard in `CoverageCounters`
#119252 revealed a possible query stability hazard in `CoverageCounters`: we iterate over the entries of an `FxHashMap` in a way that allows the iteration order to potentially affect the relative creation order of MIR blocks.
I'm not sure whether there's an actual stability problem or not in practice, but it's certainly a hazard, and I don't see any reason not to switch over to `FxIndexMap` to avoid potential issues.
---
This can either be merged on its own, or incorporated into #119252.
cc `@Enselic`
r? `@cjgillot`
Merge Coroutine lowering functions
Instead of having separate `make_async/etc_expr` functions, this merges them them into one, reducing code duplication a bit.
