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.
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;
|
```
Disable DWARF in linker options for i686-unknown-uefi
This fixes an lld warning:
> warning: linker stderr: rust-lld: section name .debug_frame is longer than 8 characters and will use a non-standard string table
See https://reviews.llvm.org/D69594 for details of where the warning was added.
This warning only occurs with the i686 UEFI target, not x86_64 or aarch64. The x86_64 target uses an LLVM target of
`x86_64-unknown-windows` and aarch64 uses `aarch64-unknown-windows`, but i686 uses `i686-unknown-windows-gnu` (note the `-gnu`). See comments in `i686_unknown_uefi.rs` for details of why.
The `.debug_frame` section should not actually be needed; UEFI targets provide a separate PDB file for debugging. Disable DWARF (and by extension the `.debug_frame` section) by passing `/DEBUG:NODWARF` to lld.
Tested with:
```
export RUSTC_LOG=rustc_codegen_ssa:🔙:link=info
cargo +stage1 build --release --target i686-unknown-uefi
```
This issue was originally raised here: https://github.com/rust-lang/rust/pull/119286#issuecomment-2612746162. See also https://github.com/rust-lang/rust/issues/136096. It was suggested to file an LLVM bug, but I don't think LLVM is actually doing anything wrong as such.
CC `@dvdhrm` `@jyn514` let me know if you have any feedback on this approach
rustc_middle: parallel: TyCtxt: remove "unsafe impl DynSend/DynSync"
rustc_middle: parallel: TyCtxt: remove "unsafe impl DynSend/DynSync"
We don't need to "short circuit trait resolution", because DynSend and DynSync are auto traits and thus coinductive
cc "Parallel Rustc Front-end" https://github.com/rust-lang/rust/issues/113349
r? SparrowLii
``@rustbot`` label: +WG-compiler-parallel
(rustbot sometimes ignores me and doesn't attach labels on my behalf. rustbot banned me?)
adding autodiff tests
I'd like to get started with upstreaming some tests, even though I'm still waiting for an answer on how to best integrate the enzyme pass. Can we therefore temporarily support the -Z llvm-plugins here without too much effort? And in that case, how would that work? I saw you can do remapping, e.g. `rust-src-base`, but I don't think that will give me the path to libEnzyme.so. Do you have another suggestion?
Other than that this test simply checks that the derivative of `x*x` is `2.0 * x`, which in this case is computed as
`%0 = fadd fast double %x.0.val, %x.0.val`
(I'll add a few more tests and move it to an autodiff folder if we can use the -Z flag)
r? ``@jieyouxu``
Locally at least `-Zllvm-plugins=${PWD}/build/x86_64-unknown-linux-gnu/enzyme/build/Enzyme/libEnzyme-19.so` seems to work if I copy the command I get from x.py test and run it manually. However, running x.py test itself fails.
Tracking:
- https://github.com/rust-lang/rust/issues/124509
Zulip discussion: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Enzyme.20build.20changes
