Make some lint doctests compatible with `--stage=0`
Currently, running `x test compiler --stage=0` (with `rust.parallel-compiler=false` to avoid other problems) results in two failures, because these lint doctests aren't compatible with the current stage0 compiler.
In theory, the more “correct” solution would be to wrap the opening triple-backtick line in `#[cfg_attr(not(bootstrap), doc = "..."]`. However, that causes a few practical problems:
- `tidy` doesn't understand that syntax, and miscounts the number of backticks in the comment block.
- `lint-docs` doesn't understand that syntax, and thinks it's trying to declare the lint name.
- Working around the above problems would cause more work and more confusion for whoever does the next bootstrap beta bump.
So instead this PR adds some bootstrap gates inside the individual doctests, which end up producing the desired behaviour, and are straightforward to remove.
set `download-ci-llvm = true` by default on "library" and "tools" profiles
It's very rare for developers to need to modify LLVM, so "if-unchanged" isn't a good default for "tools" and "library" profiles since it fetches the LLVM submodule to track changes.
Add `NonNull` convenience methods to `Box` and `Vec`
Implements the ACP: https://github.com/rust-lang/libs-team/issues/418.
The docs for the added methods are mostly copied from the existing methods that use raw pointers instead of `NonNull`.
I'm new to this "contributing to rustc" thing, so I'm sorry if I did something wrong. In particular, I don't know what the process is for creating a new unstable feature. Please advise me if I should do something. Thank you.
stabilize `const_extern_fn`
closes https://github.com/rust-lang/rust/issues/64926
tracking issue: https://github.com/rust-lang/rust/issues/64926
reference PR: https://github.com/rust-lang/reference/pull/1596
## Stabilizaton Report
### Summary
Using `const extern "Rust"` and `const extern "C"` was already stabilized (since version 1.62.0, see https://github.com/rust-lang/rust/pull/95346). This PR stabilizes the other calling conventions: it is now possible to write `const unsafe extern "calling-convention" fn` and `const extern "calling-convention" fn` for any supported calling convention:
```rust
const extern "C-unwind" fn foo1(val: u8) -> u8 { val + 1}
const extern "stdcall" fn foo2(val: u8) -> u8 { val + 1}
const unsafe extern "C-unwind" fn bar1(val: bool) -> bool { !val }
const unsafe extern "stdcall" fn bar2(val: bool) -> bool { !val }
```
This can be used to const-ify an `extern fn`, or conversely, to make a `const fn` callable from external code.
r? T-lang
cc `@RalfJung`
const-eval interning: accept interior mutable pointers in final value
…but keep rejecting mutable references
This fixes https://github.com/rust-lang/rust/issues/121610 by no longer firing the lint when there is a pointer with interior mutability in the final value of the constant. On stable, such pointers can be created with code like:
```rust
pub enum JsValue {
Undefined,
Object(Cell<bool>),
}
impl Drop for JsValue {
fn drop(&mut self) {}
}
// This does *not* get promoted since `JsValue` has a destructor.
// However, the outer scope rule applies, still giving this 'static lifetime.
const UNDEFINED: &JsValue = &JsValue::Undefined;
```
It's not great to accept such values since people *might* think that it is legal to mutate them with unsafe code. (This is related to how "infectious" `UnsafeCell` is, which is a [wide open question](https://github.com/rust-lang/unsafe-code-guidelines/issues/236).) However, we [explicitly document](https://doc.rust-lang.org/reference/behavior-considered-undefined.html) that things created by `const` are immutable. Furthermore, we also accept the following even more questionable code without any lint today:
```rust
let x: &'static Option<Cell<i32>> = &None;
```
This is even more questionable since it does *not* involve a `const`, and yet still puts the data into immutable memory. We could view this as promotion [potentially introducing UB](https://github.com/rust-lang/unsafe-code-guidelines/issues/493). However, we've accepted this since ~forever and it's [too late to reject this now](https://github.com/rust-lang/rust/pull/122789); the pattern is just too useful.
So basically, if you think that `UnsafeCell` should be tracked fully precisely, then you should want the lint we currently emit to be removed, which this PR does. If you think `UnsafeCell` should "infect" surrounding `enum`s, the big problem is really https://github.com/rust-lang/unsafe-code-guidelines/issues/493 which does not trigger the lint -- the cases the lint triggers on are actually the "harmless" ones as there is an explicit surrounding `const` explaining why things end up being immutable.
What all this goes to show is that the hard error added in https://github.com/rust-lang/rust/pull/118324 (later turned into the future-compat lint that I am now suggesting we remove) was based on some wrong assumptions, at least insofar as it concerns shared references. Furthermore, that lint does not help at all for the most problematic case here where the potential UB is completely implicit. (In fact, the lint is actively in the way of [my preferred long-term strategy](https://github.com/rust-lang/unsafe-code-guidelines/issues/493#issuecomment-2028674105) for dealing with this UB.) So I think we should go back to square one and remove that error/lint for shared references. For mutable references, it does seem to work as intended, so we can keep it. Here it serves as a safety net in case the static checks that try to contain mutable references to the inside of a const initializer are not working as intended; I therefore made the check ICE to encourage users to tell us if that safety net is triggered.
Closes https://github.com/rust-lang/rust/issues/122153 by removing the lint.
Cc `@rust-lang/opsem` `@rust-lang/lang`
ci: add a runner for vanilla LLVM 19
Ubuntu 24.10 has `llvm-19` packages that we can start testing with.
The `Dockerfile` is otherwise the same as the `llvm-18` runner.
Fix `Parser::break_up_float`'s right span
```rs
use std::mem::offset_of;
fn main() {
offset_of!((u8,), 0.0);
}
```
Before:
```
error[E0609]: no field `0` on type `u8`
--> ./main.rs:4:25
|
4 | offset_of!((u8,), 0.0);
| _____--------------------^-
| | |
| | in this macro invocation
5 | | }
... |
|
= note: this error originates in the macro `offset_of` (in Nightly builds, run with -Z macro-backtrace for more info)
error: aborting due to 1 previous error
```
After:
```
error[E0609]: no field `0` on type `u8`
--> ./main.rs:4:25
|
4 | offset_of!((u8,), 0.0);
| ^
error: aborting due to 1 previous error
```
---
`@rustbot` label +A-parser +D-imprecise-spans
Stabilize entry_insert
This stabilises `HashMap::Entry::insert_entry`, following the FCP in tracking issue #65225.
This was implemented in #64656 five years ago.
simd_shuffle: require index argument to be a vector
Remove some codegen hacks by forcing the SIMD shuffle `index` argument to be a vector, which means (thanks to https://github.com/rust-lang/rust/pull/128537) that it will automatically be passed as an immediate in LLVM. The only special-casing we still have is for the extra sanity-checks we add that ensure that the indices are all in-bounds. (And the GCC backend needs to do a bunch of work since the Rust intrinsic is modeled after what LLVM expects, which seems to be quite different from what GCC expects.)
Fixes https://github.com/rust-lang/rust/issues/128738, see that issue for more context.
coverage: Extract `executor::block_on` from several async coverage tests
By moving `block_on` to an auxiliary crate, we avoid having to keep a separate copy of it in every async test.
Simplify the canonical clone method and the copy-like forms to copy
Fixes#128081.
The optimized clone method ends up as the following MIR:
```
_2 = copy ((*_1).0: i32);
_3 = copy ((*_1).1: u64);
_4 = copy ((*_1).2: [i8; 3]);
_0 = Foo { a: move _2, b: move _3, c: move _4 };
```
We can transform this to:
```
_0 = copy (*_1);
```
r? `@cjgillot`
Fix `SDKROOT` ignore on macOS
`rustc` has code to detect when `SDKROOT` is obviously set for the wrong platform, so that it can choose to ignore it. This is a pretty important feature for Cargo build scripts and proc macros, since you will often have `SDKROOT` set to an iOS platform there.
However, the code was checking for an old SDK version name `"macosx10.15"` that was previously configured by `add_apple_sdk`, but nowadays configured to the correct `"macosx"`. I think this error was introduced in part https://github.com/rust-lang/rust/pull/77202 and in https://github.com/rust-lang/rust/pull/100286.
Fixes part of https://github.com/rust-lang/rust/issues/80817 (linking with `-Clinker=ld` now works), though more work is still needed in this area, see also https://github.com/rust-lang/rust/issues/129432.
``@rustbot`` label O-macos A-cross
(fix) conflicting negative impl marker
## Context
This MR fixes the error message for conflicting negative trait impls by adding the corresponding the polarity marker to the trait name.
## Issues
- closes#70849
r? `@fmease`
small_data_threshold.rs: Adapt to LLVM head changes
When compiled against LLVM head, `small_data_threshold.rs` [fails with](https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/31051#0191e508-f11d-437b-a4a0-5e18247debc9):
```
/.../small_data_threshold.rs:61:12: error: RISCV: expected string not found in input
--
| //@ RISCV: .section .sdata,
| ^
| /.../small_data_threshold.s:1:1: note: scanning from here
| .text
| ^
| /.../small_data_threshold.s:6:2: note: possible intended match here
| .section .sdata.U,"aw",`@progbits`
| ^
```
I don't know how exactly the current output looks like, or if there was a specific reason for including the trailing comma on the first line.
I only saw a failure for RISCV, but it seemed sensible to adjust MIPS as well.
CI passes with this patch applied: https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/31053
`@rustbot` label: +llvm-main
cc `@paulmenage`
fix doc comments for Peekable::next_if(_eq)
Fix references to a nonexistent `consume` function in the doc comments for `Peekable::next_if` and `Peekable::next_if_eq`.
Failing to do this results in the lint example output complaining
about the lint not existing instead of the thing the lint is supposed
to be complaining about.
Rollup of 5 pull requests
Successful merges:
- #130138 (bootstrap: Print more debug info when `find_initial_libdir` fails)
- #130199 (Don't call closure_by_move_body_def_id on FnOnce async closures in MIR validation)
- #130302 (add llvm-bitcode-linker and llvm-tools bins to ci-rustc's sysroot)
- #130306 (avoid updating LLVM submodule during bootstrap unit tests)
- #130317 (`ProjectionElem` and `UnOp`/`BinOp` dont need to be `PartialOrd`/`Ord`)
r? `@ghost`
`@rustbot` modify labels: rollup
`ProjectionElem` and `UnOp`/`BinOp` dont need to be `PartialOrd`/`Ord`
These types don't really admit a natural ordering and no code seems to rely on it, so let's remove it.
avoid updating LLVM submodule during bootstrap unit tests
To test this, make sure you don't have `src/llvm-project` fetched and then set `llvm.download-ci-llvm=true` and run `x test bootstrap`.
Don't call closure_by_move_body_def_id on FnOnce async closures in MIR validation
Refactors the check in #129847 to not unncessarily call the `closure_by_move_body_def_id` query for async closures that don't *need* a by-move body.
Fixes#130167
bootstrap: Print more debug info when `find_initial_libdir` fails
From looking at the failure messages printed by #129775, my hypothesis is that `rustc --print=sysroot` sometimes prints the wrong path when the rustc executable is hardlinked in multiple places, at least on my macOS system.
However, currently I don't have any concrete evidence of this actually happening. This PR therefore expands on #129775 by printing even more information on failure (including the actual rustc path), in the hope that when the failure next occurs we can confirm or reject the hypothesis that `rustc --print=sysroot` is printing the wrong path.
[bootstrap] Add support for building gcc and libgccjit
As `@eholk` summarized below:
> From my understanding, this change would add libgccjit as an optional component to the Rust distribution. This library is licensed under GPLv2 and currently we do not have any other components under that license so it would be a new license, and one that is generally more restrictive than the other licenses we use.
It'll greatly improve the experience for anyone wanting to work on the GCC backend from the compiler.
Should help with https://github.com/rust-lang/rust/issues/124172.
Will unblock #124353.
r? `@Kobzol`
Rollup of 6 pull requests
Successful merges:
- #129320 (Fix crash when labeling arguments for call_once and friends)
- #130266 (target: default to the medium code model on LoongArch targets)
- #130297 (Dataflow cleanups)
- #130299 (Add set_dcx to ParseSess)
- #130301 (some fixes for clashing_extern_declarations lint)
- #130305 (Clippy: consider msrv for const context for const_float_bits_conv)
r? `@ghost`
`@rustbot` modify labels: rollup
Clippy: consider msrv for const context for const_float_bits_conv
When `const_float_bits_conv` was stabilized for 1.83.0, clippy lints started to be triggered in const context ignoring MSRV. This PR makes the lints trigger in const context only when the MSRV meets 1.83.0.
Fixes https://github.com/rust-lang/rust-clippy/issues/13383.
some fixes for clashing_extern_declarations lint
There were two issues with the clashing_extern_declarations lint:
- It would accept non-`repr(C)` structs as compatible with each other by comparing their fields in declaration order, but the fields could have different memory order (and with `-Zrandomize-layout`, this can really happen).
- It would accept two types as compatible if `compare_layouts` returns `true`, but that function actually just compared the *ABI*, not the fully layout -- and all sized structs with more than 2 fields have the same ABI (`Abi::Aggregate`), so this missed a *lot* of cases.
We don't currently have a clear spec for what we *want* to consider "clashing" and what is fine, so I otherwise kept the original logic. I hope to have a t-lang discussion about this at some point. But meanwhile, these changes seem like clear bugfixes.
Add set_dcx to ParseSess
After [this](https://github.com/rust-lang/rust/pull/126623) PR was merged, it is no longer possible to inject one's own `Emitter` in the way [described in the Compiler Development Guide](https://rustc-dev-guide.rust-lang.org/rustc-driver-getting-diagnostics.html). The reason is that the `dcx` field in `ParseSess` is no longer public, so it is not possible to update the `dcx` field with a `DiagCtxt` that contains one's own `Emitter` in the `psess_created` callback in `rustc_interface::Config`. The only way I have found to insert my own `DiagCtxt` is by creating an entirely new `ParseSess` and replacing the old one. This is not a good solution as the original `ParseSess` contains fields I would like to keep. (In my case the problem is that I lose the `cfg` and `check-cfg` fields of the original.)
The solution proposed in this PR is to add a `set_dcx` method to `ParseSess`. Per my limited understanding of the rustc codebase this should be fine as `set_dcx` requires a mutable reference to `ParseSess`, which is as far as I know only available in the `psess_created` callback (outside of `rustc_interface::run_compiler`).
If this PR is accepted, I will create a new PR to update the aforementioned example in the Compiler Development Guide.
target: default to the medium code model on LoongArch targets
The Rust LoongArch targets have been using the default LLVM code model so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak. As described in the "Code Model" section of LoongArch ELF psABI spec v20231219 [1], one can only make function calls as far as ±128MiB with the "normal" code model; this is insufficient for very large software containing Rust components that needs to be linked into the big text section, such as Chromium.
Because:
* we do not want to ask users to recompile std if they are to build such software,
* objects compiled with larger code models can be linked with those with smaller code models without problems, and
* the "medium" code model is comparable to the "small"/"normal" one performance-wise (same data access pattern; each function call becomes 2-insn long and indirect, but this may be relaxed back into the direct 1-insn form in a future LLVM version), but is able to perform function calls within ±128GiB,
it is better to just switch the targets to the "medium" code model, which is also "medium" in LLVM-speak.
Relands [2]: #120661
[1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models
[2]: https://github.com/rust-lang/rust/issues/121289#issuecomment-2333687396
