Because it's redundant w.r.t. `Diagnostic::is_lint`, which is present
for every diagnostic level.
`struct_lint_level_impl` was the only place that set the `Error` field
to `true`, and it's also the only place that calls
`Diagnostic::is_lint()` to set the `is_lint` field.
Note the parentheses in the last suggestion:
```
error[E0277]: the size for values of type `(dyn Foo + Send + 'static)` cannot be known at compilation time
--> $DIR/not-on-bare-trait.rs:7:8
|
LL | fn foo(_x: Foo + Send) {
| ^^ doesn't have a size known at compile-time
|
= help: the trait `Sized` is not implemented for `(dyn Foo + Send + 'static)`
= help: unsized fn params are gated as an unstable feature
help: you can use `impl Trait` as the argument type
|
LL | fn foo(_x: impl Foo + Send) {
| ++++
help: function arguments must have a statically known size, borrowed types always have a known size
|
LL | fn foo(_x: &(Foo + Send)) {
| ++ +
```
Add the following suggestions:
```
error[E0782]: trait objects must include the `dyn` keyword
--> $DIR/not-on-bare-trait-2021.rs:11:11
|
LL | fn bar(x: Foo) -> Foo {
| ^^^
|
help: use a generic type parameter, constrained by the trait `Foo`
|
LL | fn bar<T: Foo>(x: T) -> Foo {
| ++++++++ ~
help: you can also use `impl Foo`, but users won't be able to specify the type paramer when calling the `fn`, having to rely exclusively on type inference
|
LL | fn bar(x: impl Foo) -> Foo {
| ++++
help: alternatively, use a trait object to accept any type that implements `Foo`, accessing its methods at runtime using dynamic dispatch
|
LL | fn bar(x: &dyn Foo) -> Foo {
| ++++
error[E0782]: trait objects must include the `dyn` keyword
--> $DIR/not-on-bare-trait-2021.rs:11:19
|
LL | fn bar(x: Foo) -> Foo {
| ^^^
|
help: use `impl Foo` to return an opaque type, as long as you return a single underlying type
|
LL | fn bar(x: Foo) -> impl Foo {
| ++++
help: alternatively, you can return an owned trait object
|
LL | fn bar(x: Foo) -> Box<dyn Foo> {
| +++++++ +
```
Fix: Properly set vendor in i686-win7-windows-msvc target
In #118150 , setting the `vendor` field of the `i686-win7-windows-msvc` target was forgotten, preventing us from easily checking the target using `cfg(target_vendor)`.
With this PR, we set the target vendor to "win7".
Update `thread_local` examples to use `local_key_cell_methods`
`local_key_cell_methods` has been stable for a while and provides a much less clunky way to interface with thread-local
Additionaly add context to the documentation about why types with interior mutability are needed.
r? libs
llvm: Allow `noundef` in codegen tests
LLVM 18 will automatically infer `noundef` in some situations. Adjust codegen tests to accept this.
See llvm/llvm-project#76553 for why `noundef` is being generated now.
``@rustbot`` label:+llvm-main
coverage: Avoid a query stability hazard in `function_coverage_map`
When #118865 started enforcing the `rustc::potential_query_instability` lint in `rustc_codegen_llvm`, it added an exemption for this site, arguing that the entries are only used to create a list of filenames that is later sorted.
However, the list of entries also gets traversed when creating the function coverage records in LLVM IR, which may be sensitive to hash-based ordering.
This patch therefore changes `function_coverage_map` to use `FxIndexMap`, which should avoid hash-based instability by iterating in insertion order.
cc ``@Enselic``
Report I/O errors from rmeta encoding with emit_fatal
https://github.com/rust-lang/rust/issues/119456 reminded me that I never did systematic testing to provoke the out-of-disk ICEs so I grepped through a recent crater run (https://github.com/rust-lang/rust/pull/119440#issuecomment-1873393963) for more out-of-disk ICEs on current master and yep there's 2 in there.
So I finally cooked up a way to provoke for these crashes. I wrote a little `cdylib` crate that has a `#[no_mangle] pub extern "C" fn write` which occasionally reports `ENOSPC`, and prints a backtrace when it does.
<details><summary><strong>code for the dylib</strong></summary>
<p>
```rust
// cargo add libc rand backtrace
use rand::Rng;
#[no_mangle]
pub extern "C" fn write(
fd: libc::c_int,
buf: *const libc::c_void,
count: libc::size_t,
) -> libc::ssize_t {
if fd > 2 && rand::thread_rng().gen::<u8>() == 0 {
let mut count = 0;
backtrace::trace(|frame| {
backtrace::resolve_frame(frame, |symbol| {
if let Some(name) = symbol.name() {
if count > 3 {
eprintln!("{}", name);
}
}
count += 1;
});
true
});
unsafe {
*libc::__errno_location() = libc::ENOSPC;
}
return -1;
} else {
unsafe {
let res =
libc::syscall(libc::SYS_write, fd as usize, buf as usize, count as usize) as isize;
if res < 0 {
*libc::__errno_location() = -res as i32;
-1
} else {
res
}
}
}
}
```
</p>
</details>
Then `LD_PRELOAD` that dylib and repeatedly build a big project until it ICEs, such as with this:
```bash
while true; do
cargo clean
LD_PRELOAD=/home/ben/evil/target/release/libevil.so cargo +stage1 check 2> errors
if grep "thread 'rustc' panicked" errors; then
break
fi
done
```
My "big project" for testing was an otherwise-empty project with `cargo add axum`.
Before this PR, the above procedure finds a crash in between 1 and 15 minutes. With this PR, I have not found a crash in 30 minutes, and I'll be leaving this to run overnight (starting now). (A night has now passed, no crashes were found)
I believe the problem is that even though since https://github.com/rust-lang/rust/pull/117301 we correctly check `FileEncoder` for errors on all paths, we use `emit_err`, so there is a window of time between the call to `emit_err` and the full error reporting where rustc believes it has emitted a valid rmeta file and will permit Cargo to launch a build for a dependent crate. Changing these calls to `emit_fatal` closes that window.
I think there are a number of other cases where `emit_err` has been used instead of the more-correct `emit_fatal` such as e51e98dde6/compiler/rustc_codegen_ssa/src/back/write.rs (L542) but unlike rmeta encoding I am not aware of those cases of those causing problems.
r? ``@WaffleLapkin``
Update books
## rust-lang/reference
1 commits in f9f5b5babd95515e7028c32d6ca4d9790f64c146..3565c7978cfc9662f5963b135690ff9cbbfa0318
2023-12-29 21:01:19 UTC to 2023-12-29 21:01:19 UTC
- Use proper footnote for number literals `_` separator note (rust-lang/reference#1444)
## rust-lang/rust-by-example
1 commits in 4c2b24ff9d9cf19f2fcff799a3a49b9a2c50ae8e..c0be6299e52e4164c30ba6f41bd0ad0aaee64972
2023-12-21 15:22:11 UTC to 2023-12-21 15:22:11 UTC
- point to raw indentifiers, talking about fields (rust-lang/rust-by-example#1789)
## rust-lang/rustc-dev-guide
5 commits in 0610665a8687b1b0aa037917a1598b9f2a21e3ef..d13e85152a977cd0bcaf583cf5f49e86225697de
2023-12-30 09:58:25 UTC to 2023-12-19 10:02:34 UTC
- Prominently mention `profiler = true` on the coverage page (rust-lang/rustc-dev-guide#1844)
- Add a description of `unpretty=hir` to the HIR docs (rust-lang/rustc-dev-guide#1842)
- Fix typo in unsize docs (rust-lang/rustc-dev-guide#1843)
- Suggest `gcc_multi` to make `mir_opts` run on nixos (rust-lang/rustc-dev-guide#1841)
- bootstrapping: Clarify that stage0 std code is not executed to produce stage1 compiler (rust-lang/rustc-dev-guide#1840)
Update tracking issue of naked_functions
The original tracking issue #32408 was superseded by the new one #90957 (constrainted naked functions) and therefore is closed.
rc: Take *const T in is_dangling
It is not important which one is used since `is_dangling` does not access memory, but `*const` removes the needs of `*const T` -> `*mut T` casts in `from_raw_in`.
Document that File does not buffer reads/writes
...and refer to `BufReader`/`BufWriter`.
This is a common source of efficiency issues in Rust programs written naively. Including this information with the `File` docs, and adding a link to the wrapper types, will help discoverability.
Query panic!() to useful diagnostic
Changes some more ICEs from bare panic!()s
Adds an `expect_job()` helper method as that is a moral equivalent of what was happening at the uses.
re:#118955
Since we already iterate through targets in StepDescription::maybe_run, there is no need to
iterate targets again in the install step for std.
Compared the results before and after applying the changes to install step of std, and there were no differences.
```sh
~/devspace/.other/rustc-builds $ sha256sum ./old/usr/local/lib/rustlib/manifest-rust-std-x86_64-*
c2ea86fc25ffac87b0b135f31ba9644ad97549da4c050c3921b437d1e18285fd ./old/usr/local/lib/rustlib/manifest-rust-std-x86_64-pc-windows-gnu
d2f1081a779962e2cbc27f53191783d13428abd0964465547af78ce34c7251dd ./old/usr/local/lib/rustlib/manifest-rust-std-x86_64-unknown-linux-gnu
~/devspace/.other/rustc-builds $ sha256sum ./new/usr/local/lib/rustlib/manifest-rust-std-x86_64-*
c2ea86fc25ffac87b0b135f31ba9644ad97549da4c050c3921b437d1e18285fd ./new/usr/local/lib/rustlib/manifest-rust-std-x86_64-pc-windows-gnu
d2f1081a779962e2cbc27f53191783d13428abd0964465547af78ce34c7251dd ./new/usr/local/lib/rustlib/manifest-rust-std-x86_64-unknown-linux-gnu
```
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Temporarily disable M1 runners on GitHub Actions
This commit temporarily reverts the addition of M1 runners on GitHub Actions to work around a billing issue related to their beta.
The runners for `dist-aarch64-apple` were originally changed in 821b03d767e7da7442c21fdc12bb4ac7d5606956, and the `aarch64-apple` job was added in 6909992501b400c8cd7d75e8d61365b2c20015f9.
