compiletest: normalize stderr before SVG rendering
Element position is hardcoded in the rendered SVG. This means that any change in element length (for instance, when substituting the path with the `rust` checkout with `$DIR`) would not change the position and result in buggy SVG being generated. Normalizing before SVG rendering allows us to keep a consistent element placement.
tests: rustc_public: Check const allocation for all variables (1 of 11 was missing)
In the test `tests/ui-fulldeps/rustc_public/check_allocation.rs` there is a check for constant allocations of local variables of this function:
fn other_consts() {{
let _max_u128 = u128::MAX;
let _min_i128 = i128::MIN;
let _max_i8 = i8::MAX;
let _char = 'x';
let _false = false;
let _true = true;
let _ptr = &BAR;
let _null_ptr: *const u8 = NULL;
let _tuple = TUPLE;
let _char_id = const {{ type_id::<char>() }};
let _bool_id = const {{ type_id::<bool>() }};
}}
The current test only finds 10 out of 11 allocations. The constant allocation for
let _ptr = &BAR;
is not checked, because the `SingleUseConsts` MIR pass does not optimize away that assignment. Add code to also collect constant allocation from assignment rvalues to find the constant allocation for that last variable.
Not only does this change make sense on its own, it also makes the test pass both with and without the `SingleUseConsts` pass.
Discovered while investigating ways to avoid [this tests/ui-fulldeps/rustc_public/check_allocation.rs](d7fffabc31 (diff-c4a926f9e8ba22bcfb1e6f2491b79b80608ab018641f85f66d6718d7f3716a5e)) hack from https://github.com/rust-lang/rust/pull/151426 which wants to stop running `SingleUseConsts` for non-optimized builds.
Reflection TypeKind::FnPtr
This is for https://github.com/rust-lang/rust/issues/146922.
Const-eval currently lacks full support for function pointer (fn) types. We should implement handling of FnPtr TypeKind, covering safe and unsafe functions, Rust and custom ABIs, input and output types, higher-ranked lifetimes, and variadic functions.
Fix ICE in transmutability error reporting when type aliases are normalized
Fixesrust-lang/rust#151462
Transmutability error reporting hit an ICE when type aliases were normalized for diagnostics. For example, when type
`JustUnit = ()` normalizes to `()`, the check passes unexpectedly even though the original check with `JustUnit` failed.
Fixed by adding a retry in the `Answer::Yes` arm that checks with the root obligation's types before panicking. The retry only occurs when the root obligation differs and is a Transmute trait predicate.
Also added a test that reproduces the original ICE.
Respect the `--ci` flag in more places in bootstrap
### Motivation
Currently, the way of checking CI environment in bootstrap is not unified. Sometimes `--ci` flag is respected, but in other cases only GITHUB_ACTIONS env var is checked.
### Change
This PR modifies the way of treating the flag in bootstrap. If `--ci` (or `--ci=true`) is added, bootstrap's config set ci_env as `CiEnv::GithubActions`. This PR also modifies some lines in bootstrap to respect the config's CiEnv instance.
### Note
I haven't touched anything in tidy, because I want to raise another PR for introducing --ci flag in tidy. In the PR, I will need to change how tidy treats CI information. So currently I leave it as it is.
Stop using rustc_layout_scalar_valid_range_* in rustc
Another step towards rust-lang/rust#135996
Required some manual impls, but we already do many manual impls for the newtype_index types, so it's not really a new maintenance burden.
- Implement handling of FnPtr TypeKind in const-eval, including:
- Unsafety flag (safe vs unsafe fn)
- ABI variants (Rust, Named(C), Named(custom))
- Input and output types
- Variadic function pointers
- Add const-eval tests covering:
- Basic Rust fn() pointers
- Unsafe fn() pointers
- Extern C and custom ABI pointers
- Functions with multiple inputs and output types
- Variadic functions
- Use const TypeId checks to verify correctness of inputs, outputs, and payloads
carryless_mul: mention the base
Arithmetic operations do not typically care about the base that is used to represent numbers, but this one does. Mentioning that makes it easier to understand the operation, I think.
Cc @folkertdev
Miri: recursive validity: also recurse into Boxes
Now that https://github.com/rust-lang/rust/issues/97270 is fixed, the recursive validity mode for Miri can recuse into Boxes without exploding everywhere.
make `rustc_allow_const_fn_unstable` an actual `rustc_attrs` attribute
It is already named like one, but used to have its own feature gate, which this PR now removes in favor of just using `#![feature(rustc_attrs)]`.
Most of the diff is just the line number changes in `malformed-attrs.stderr`.
Rework explanation of CLI lint level flags
I think the previous wording as either wrong or confusing. I would consider the CLI flags at a *lower* ranking, since source attributes are able to override the CLI flag.
Add documentation note about signed overflow direction
In https://github.com/rust-lang/rust/issues/151989#issuecomment-3845282666 I noticed that signed overflow direction can be determined by returned wrapped value. It is not very obvious (especially, assuming additional `carry: bool` summand), but it is important if we want to add new leading (signed) limb to big integer in this case.
Examples for small summands `x, y: i8` with result extension:
| x | y | overflow | result as (u8, i8) |
| ---- | ---- | -------- | ------------------ |
| -1 | -128 | true | (127, -1) |
| 0 | -1 | false | (255, -1) |
| 2 | 2 | false | (4, 0) |
| 127 | 1 | true | (128, 0) |
Here is general proof.
1. Set $s=2^{N-1}$ and let's say `iN::carrying_add(x, y, c)` returns `(result, true)` then
$$
\mathrm{result}=\begin{cases}
x + y + c + 2s,& x + y + c \le -s-1,\\
x+y+c-2s,& x+y+c\ge s.
\end{cases}
$$
First case is overflowing below `iN::MIN` and we have
$$
\mathrm{result}\ge -s-s+0+2s =0;\qquad
\mathrm{result}=x + y + c + 2s\le -s-1+2s = s - 1,
$$
so we obtain $[0; s-1]$ which is exactly range of non-negative `iN`.
Second case is overflowing above `iN::MAX` and
$$
\mathrm{result}=x+y+c-2s\ge s-2s =-s;\qquad
\mathrm{result}\le s-1 + s-1+1-2s = -1,
$$
that is, $[-s,-1]$ which is exactly range of negative `iN`.
2. Now suppose that `iN::borrowing_sub(x,y,b)` returns `(result, true)` then
$$
\mathrm{result}=\begin{cases}
x - y - b + 2s,& x - y - b \le -s-1,\\
x - y - b - 2s,& x - y - b\ge s.
\end{cases}
$$
First case is overflowing below `iN::MIN` and we have
$$
\mathrm{result}\ge -s-(s-1)-1+2s =0;\qquad
\mathrm{result}=x - y - b + 2s\le -s-1+2s = s - 1.
$$
Second case is overflowing above `iN::MAX` and
$$
\mathrm{result}=x-y-b-2s\ge s-2s =-s;\qquad
\mathrm{result}\le s-1 - (-s) - 0 - 2s = -1.
$$
Fix invalid `mut T` suggestion for `&mut T` in missing lifetime error
close: rust-lang/rust#150077
When suggesting to return an owned value instead of a borrowed one, the diagnostic was only removing `&` instead of `&mut `, resulting in invalid syntax like `mut T`. This PR fixes the span calculation to properly cover the entire `&mut ` prefix.
remove the explicit error for old `rental` versions
This was converted to a hard error 20 months ago (in rust-lang/rust#125596). This seems like enough time for anyone still using it to notice, so remove the note entirely now.
In comparison, the explicit note for the more impactful `time` breakage was already removed after 6 months (rust-lang/rust#129343).
Closesrust-lang/rust#73933.
Closesrust-lang/rust#83125.
r? @petrochenkov
Rename dep node "fingerprints" to distinguish key and value hashes
In the query system's dependency graph, each node is associated with two *fingerprints*: one that is typically a hash of the query key, and one that is typically a hash of the query's return value when called with that key.
Unfortunately, many identifiers and comments fail to clearly distinguish between these two kinds of fingerprint, which have very different roles in dependency tracking. This is a frequent source of confusion.
This PR therefore tries to establish a clear distinction between:
- **Key fingerprints** that help to uniquely identify a node (along with its `DepKind`), and are typically a hash of the query key
- **Value fingerprints** that help to determine whether a node can be marked green (despite having red dependencies), and are typically a hash of the query value
There should be no change to compiler behaviour.
r? nnethercote (or compiler)
compiler: Don't mark `SingleUseConsts` MIR pass as "required for soundness"
I don't think this MIR pass is required for soundness. The reasons are:
* Something like it was not enabled by default before PR rust-lang/rust#107404 which was the precursor to `SingleUseConsts` (see rust-lang/rust#125910 for the switch).
* By following the advice from https://github.com/rust-lang/rust/pull/128657#discussion_r1705114015 we can conclude it is not required for soundness since it has only ever run on MIR opt level > 0.
* Its [`MirPass::can_be_overridden()`](0ee7d96253/compiler/rustc_mir_transform/src/pass_manager.rs (L98-L102)) is unchanged and thus returns `true`, indicating that it is not a required MIR pass.
* PR CI pass in rust-lang/rust#151426 which stops enabling it by default in non-optimized builds.
As shown in the updated test `tests/mir-opt/optimize_none.rs`, `#[optimize(none)]` functions become even less optimized, as expected and desired.
Unblocks https://github.com/rust-lang/rust/pull/151426.
tail calls: fix copying non-scalar arguments to callee
Alternative to https://github.com/rust-lang/rust/pull/144933: when invoking a tail call with a non-scalar argument, we need to delay freeing the caller's local variables until after the callee is initialized, so that we can copy things from the caller to the callee.
Fixes https://github.com/rust-lang/rust/issues/144820... but as the FIXMEs in the code show, it's not clear to me whether these are the right semantics.
r? @WaffleLapkin
Unify wording of resolve error
Remove "failed to resolve" from the main error message and use the same format we use in other resolution errors "cannot find `name`":
```
error[E0433]: cannot find `nonexistent` in `existent`
--> $DIR/custom_attr_multisegment_error.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ could not find `nonexistent` in `existent`
```
The intent behind this is to end up with all resolve errors eventually be on the form of
```
error[ECODE]: cannot find `{NAME}` in {SCOPE}
--> $DIR/file.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ {SPECIFIC LABEL}
```
A category of errors that is interest are those that involve keywords. For example:
```
error[E0433]: cannot find `Self` in this scope
--> $DIR/issue-97194.rs:2:35
|
LL | fn bget(&self, index: [usize; Self::DIM]) -> bool {
| ^^^^ `Self` is only available in impls, traits, and type definitions
```
and
```
error[E0433]: cannot find `super` in this scope
--> $DIR/keyword-super.rs:2:9
|
LL | let super: isize;
| ^^^^^ there are too many leading `super` keywords
```
For these the label provides the actual help, while the message is less informative beyond telling you "couldn't find `name`".
This is an off-shoot of https://github.com/rust-lang/rust/pull/126810 and https://github.com/rust-lang/rust/pull/128086, a subset of the intended changes there with review comments applied.
r? @petrochenkov
Support JSON target specs in bootstrap
JSON target specs were destabilized in https://github.com/rust-lang/rust/pull/150151 and https://github.com/rust-lang/rust/pull/151534. However, this broke trying to build rustc itself with a JSON target spec. This is because in a few places bootstrap is manually calling `rustc` without the ability for the user to provide additional flags (primarily, `-Zunstable-options` to enable JSON targets).
There's a few different ways to fix this. One would be to change these calls to `rustc` to include flags provided by the user (such as `RUSTFLAGS_NOT_BOOTSTRAP`). Just to keep things simple, this PR proposes to just unconditionally pass `-Zunstable-options`.
Another consideration here is how maintainable this is. A possible improvement here would be to have a function somewhere (BootstrapCommand, TargetSelection, free function) that would handle appropriately adding the `--target` flag. For example, that's what cargo does in [`CompileKind::add_target_arg`](592058c7ce/src/cargo/core/compiler/compile_kind.rs (L144-L154)).
I have only tested building the compiler and a few tools like rustdoc. I have not tested doing things like building other tools, running tests, etc.
This would be much easier if there was a Docker image for testing the use case of building rustc with a custom target spec (and even better if that ran in CI).
After the next beta branch, using target JSON specs will become more cumbersome because target specs with the `.json` extension will now require passing `-Zjson-target-spec` (from
https://github.com/rust-lang/cargo/pull/16557). This does not affect target specs without the `.json` extension (such as those from RUST_TARGET_PATH). From my testing, it should be sufficient to pass `CARGOFLAGS_NOT_BOOTSTRAP="-Zjson-target-spec"`. I think that should be fine, since this is not a particularly common use case AFAIK. We could extend bootstrap to auto-detect if the target is a file path, and pass `-Zjson-target-spec` appropriately. I tried something similar in f0bdd35483, which could be adapted if desired.
It would be nice if all of this is documented somewhere. https://rustc-dev-guide.rust-lang.org/building/new-target.html does not really say how to build the compiler with a custom json target.
Fixes https://github.com/rust-lang/rust/issues/151729
