Avoid delayed-bug ICE for malformed diagnostic attrs
Fixesrust-lang/rust#152744
Skip suggestions in `expected_lit` when parsing with `Recovery::Forbidden`, since this may later cancel `InvalidMetaItem`. This avoids creating delayed bugs that can be promoted to ICE.
Do no add -no-pie on Windows
Windows binaries are always position independent and Clang warns when trying to enable or disable that:
```
❯ clang hello.c -pie
clang: warning: argument unused during compilation: '-pie' [-Wunused-command-line-argument]
❯ clang hello.c -no-pie
clang: warning: argument unused during compilation: '-no-pie' [-Wunused-command-line-argument]
```
https://github.com/rust-lang/rust/pull/149937 will turn these warnings into build errors:
```
❯ cargo rustc -- -D linker-messages
Compiling hello v0.1.0 (E:\tmp\hello)
error: linker stderr: x86_64-w64-mingw32-clang: argument unused during compilation: '-nolibc' [-Wunused-command-line-argument]␍
x86_64-w64-mingw32-clang: argument unused during compilation: '-no-pie' [-Wunused-command-line-argument]␍
|
= note: requested on the command line with `-D linker-messages`
error: could not compile `hello` (bin "hello") due to 1 previous error
```
Add a mir-opt test for alignment check generation [zero changes outside tests]
I wrote this as part of rust-lang/rust#152641 which it looks like I'm going to just close, so submitting the new test separately since we didn't have any mir-opt testing of this pass that I could find (at least `x test tests/mir-opt` didn't fail when I broke them) so figured it's something that should exist.
std::r#try! - avoid link to nightly docs
Use a relative link to the current version of rust-by-example rather than sending people to the nightly version.
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
Windows binaries are always position independent
and Clang warns when trying to enable or disable
that:
```
❯ clang hello.c -pie
clang: warning: argument unused during compilation: '-pie' [-Wunused-command-line-argument]
❯ clang hello.c -no-pie
clang: warning: argument unused during compilation: '-no-pie' [-Wunused-command-line-argument]
```
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
