chore: update rustc-hash 2.1.0 to 2.1.1
This PR updates the rustc-hash crate to include a palliative fix for #135477.
The discussion for this can be found in the issue and on https://github.com/rust-lang/rustc-hash/pull/55.
This PR is the output of running `cargo +nightly update rustc-hash@2.1.0`. I ran all tests locally and they all seem to pass, with the exception of `tests/ui/process/nofile-limit.rs` which always fails on my setup.
`@steffahn` `@orlp` and `@Noratrieb` all have full context on this, I'm opening the pull request trying to be helpful. I'm not sure if anything else needs to be done, like documentation I'm not aware of or running any special CIs but if I can do anything else please let me know!
Simplify intra-crate qualifiers.
The following is a weird pattern for a file within `rustc_middle`:
```
use rustc_middle::aaa;
use crate::bbb;
```
More sensible and standard would be this:
```
use crate::{aaa, bbb};
```
I.e. we generally prefer using `crate::` to using a crate's own name. (Exceptions are things like in macros where `crate::` doesn't work because the macro is used in multiple crates.)
This commit fixes a bunch of these weird qualifiers.
r? `@jieyouxu`
compiler: die immediately instead of handling unknown target codegen
We cannot produce anything useful if asked to compile unknown targets. We should handle the error immediately at the point of discovery instead of propagating it upward, and preferably in the simplest way: Die.
This allows cleaning up our "error-handling" spread across 5 crates.
Update docs for impl keyword
This started as a fix for #79878, but also introduces some structure (headings), and elaborates a tiny bit on impl Trait syntax.
show supported register classes in error message
a simple diagnostic change that shows the supported register classes when an invalid one is found.
This information can be hard to find (especially for unstable targets), and this message now gives at least something to try or search for. I've followed the pattern for invalid clobber ABIs.
`@rustbot` label +A-inline-assembly
fix ensure_monomorphic_enough
When polymorphization was still a thing, the visitor was used to only recurse into *used generic parameters* of function/closure/coroutine types and allow unused parameters (i.e. the polymorphized parameters) to remain generic.
When polymorphization got removed, this got changed to always treat all parameters as polymorphic and never recurse into them: https://github.com/rust-lang/rust/pull/133883/files#diff-210c59e321070d0ca4625c04e9fb064bf43ddc34082e7e33a7ee8a6c577e95afL44-L62
This is clearly wrong and can cause MIR opts to misbehave, for example this currently prints "false" in release mode:
```rust
#![feature(core_intrinsics)]
fn generic<T>() {}
const fn type_id_of_val<T: 'static>(_: &T) -> u128 {
std::intrinsics::type_id::<T>()
}
fn cursed_is_i32<T: 'static>() -> bool {
(const { type_id_of_val(&generic::<T>) } == const { type_id_of_val(&generic::<i32>) })
}
fn main() {
dbg!(cursed_is_i32::<i32>());
}
```
This PR reverts to the old behavior of always treating all types that contain type parameters as too generic, like we used to do without `-Zpolymorphize` before.
~~I'm not including the above as a test case here, because I think there is little value in testing code paths that have been removed and this seems unlikely to regress in a way that would be caught by a regression test, but let me know if you disagree and want me to add a test anyway.~~
Overhaul how contracts are lowered on fn-like bodies
Consolidates all of the contracts lowering logic into `lower_fn_body`, rather than having it be split between `lower_item_kind` and `lower_fn_body`. This should fix#136683.
r? celinval
Stop using span hack for contracts feature gating
The contracts machinery is a pretty straightforward case of an *external* feature using a (perma-unstable) *internal* feature within its implementation. There's no reason why it needs to be implemented any differently than other features by using global span tracking hacks to change whether the internals are gated behind the `contracts` or `contracts_internals` feature gate -- for the case of macro expansions we already have `allow_internal_unstable` for exactly this situation.
This PR changes the internal, perma-unstable AST syntax to use the `contracts_internals` gate always, and adjusts the macro expansion to use the right spans so that `allow_internal_unstable` works correctly.
As a follow-up, there's really no reason to have `contracts` be a *compiler feature* since it's at this point fully a *library feature*; the only reason it's a compiler feature today is so we can mark it as incomplete, but that seems like a weak reason. I didn't do anything in this PR for this.
r? ``@celinval``
cg_llvm: Reduce visibility of some items outside the `llvm` module
Next piece of #135502
This reduces the visibility of items (other than those in the `llvm` module) so that dead code analysis will correctly identify unused items.
Improve examples for file locking
The `lock` and `try_lock` documentation states that "if the file not open for writing, it is unspecified whether this function returns an error." With this change, the examples use `File::create` instead of `File::open`, eliminating the possibility of someone blindly copying code with unspecified behavior.
Fix long lines which rustfmt fails to format
rustfmt fails to format this match expression, because it has several long string literals over the maximum line width. This seems to exhibit rustfmt issues [#3863](https://github.com/rust-lang/rustfmt/issues/3863) (Gives up on chains if any line is too long) and [#3156](https://github.com/rust-lang/rustfmt/issues/3156) (Fail to format match arm when other arm has long line).
Format it with a large line width (e.g., by setting `max_width = 200` in rustfmt.toml) and, in case the rustfmt bugs are later fixed, mark it with `#[rustfmt::skip]`, as it is more legible with each case on one line.
The following is a weird pattern for a file within `rustc_middle`:
```
use rustc_middle::aaa;
use crate::bbb;
```
More sensible and standard would be this:
```
use crate::{aaa, bbb};
```
I.e. we generally prefer using `crate::` to using a crate's own name.
(Exceptions are things like in macros where `crate::` doesn't work
because the macro is used in multiple crates.)
This commit fixes a bunch of these weird qualifiers.
rustfmt fails to format this match expression, because it has several
long string literals over the maximum line width. This seems to exhibit
rustfmt issues #3863 (Gives up on chains if any line is too long) and
#3156 (Fail to format match arm when other arm has long line).
Show diff suggestion format on verbose replacement
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
--> $DIR/attempted-access-non-fatal.rs:7:15
|
LL | let _ = 2.l;
| ^
|
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
|
LL - let _ = 2.l;
LL + let _ = 2.0f64;
|
```
before:
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
--> $DIR/attempted-access-non-fatal.rs:7:15
|
LL | let _ = 2.l;
| ^
|
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
|
LL + let _ = 2.0f64;
| ~~~~
```
r? `@oli-obk`
Update books
## rust-lang/edition-guide
1 commits in f56aecc3b036dff16404b525a83b00f911b9bbea..8dbdda7cae4fa030f09f8f5b63994d4d1dde74b9
2025-02-06 20:06:58 UTC to 2025-02-06 20:06:58 UTC
- Correct spelling error in `static-mut-references.md` (rust-lang/edition-guide#358)
## rust-embedded/book
1 commits in ddbf1b4e2858fedb71b7c42eb15c4576517dc125..0b8219ac23a3e09464e4e0166c768cf1c4bba0d5
2025-02-07 08:26:59 UTC to 2025-02-07 08:26:59 UTC
- Update gcc toolchain download link for windows (rust-embedded/book#384)
## rust-lang/reference
3 commits in 4249fb411dd27f945e2881eb0378044b94cee06f..de2d5289e45506b11dd652bef4f99de64be70e1c
2025-02-08 22:12:20 UTC to 2025-02-06 19:02:01 UTC
- Add trait_upcasting related languages changes (rust-lang/reference#1622)
- fixup `»` insertion for rules (rust-lang/reference#1730)
- doc `cenum_impl_drop_cast` (rust-lang/reference#1713)
## rust-lang/rust-by-example
2 commits in 743766929f1e53e72fab74394ae259bbfb4a7619..66543bbc5b7dbd4e679092c07ae06ba6c73fd912
2025-02-06 12:38:08 UTC to 2025-02-04 01:46:09 UTC
- Add more examples @ drop.md (rust-lang/rust-by-example#1912)
- es translation to 3100 (rust-lang/rust-by-example#1911)
compiler: gate `extern "{abi}"` in ast_lowering
I don't believe low-level crates like `rustc_abi` should have to know or care about higher-level concerns like whether the ABI string is stable for users. These implementation details can be made less open to public inspection. This way the code that governs stability is near the code that enforces stability, and compiled together.
It also abstracts away certain error messages instead of constantly repeating them.
A few error messages are simply deleted outright, instead of made uniform, because they are either too dated to be useful or redundant with other diagnostic improvements we could make. These can be pursued in followups: my first concern was making sure there wasn't unnecessary diagnostics-related code in `rustc_abi`, which is not well-positioned to understand what kind of errors are going to be generated based on how it is used.
r? ``@ghost``
Prevent generic pattern types from being used in libstd
Pattern types should follow the same rules that patterns follow. So a pattern type range must not wrap and not be empty. While we reject such invalid ranges at layout computation time, that only happens during monomorphization in the case of const generics. This is the exact same issue as other const generic math has, and since there's no solution there yet, I put these pattern types behind a separate incomplete feature.
These are not necessary for the pattern types MVP (replacing the layout range attributes in libcore and rustc).
cc #136574 (new tracking issue for the `generic_pattern_types` feature gate)
r? ``@lcnr``
cc ``@scottmcm`` ``@joshtriplett``
Delay bug when method confirmation cannot upcast object pick of self
Justification is on the test comment. Simply delays a bug that we were previously ICEing on.
cc ``@adetaylor`` since this is a `arbitrary_self_types` ICE.
Introduce CoercePointeeWellformed for coherence checks at typeck stage
Fix#135206
This is the first PR to introduce the "wellformedness" check for `derive(CoercePointee)`.
This patch introduces a new error code to cover all the prerequisites of the said macro. The checks that is enforced with this patch is whether the data is indeed `struct` and whether the layout is set to `repr(transparent)`.
A following series of patch will arrive later to address the following concern.
1. #135217 so that we would only admit one single coercion on one type parameter, and leave the rest for future consideration in tandem of development of other coercion rules.
1. Enforcement of data field requirements.
**An open question** is whether there is a good schema to encode the `#[pointee]` as well, so that we could also check if the `#[pointee]` type parameter is indeed `?Sized`.
``@rustbot`` label F-derive_coerce_pointee
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
--> $DIR/attempted-access-non-fatal.rs:7:15
|
LL | let _ = 2.l;
| ^
|
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
|
LL - let _ = 2.l;
LL + let _ = 2.0f64;
|
```
We cannot produce anything useful if asked to compile unknown targets.
We should handle the error immediately at the point of discovery instead
of propagating it upward, and preferably in the simplest way: Die.
This allows cleaning up our "error-handling" spread across 5 crates.
