Rollup of 8 pull requests
Successful merges:
- #136503 (Tweak output of const panic diagnostic)
- #137390 (tests: fix up new test for nocapture -> capture(none) change)
- #137617 (Introduce `feature(generic_const_parameter_types)`)
- #137719 (Add missing case explanation for doc inlined re-export of doc hidden item)
- #137763 (Use `mk_ty_from_kind` a bit less, clean up lifetime handling in borrowck)
- #137769 (Do not yeet `unsafe<>` from type when formatting unsafe binder)
- #137776 (Some `rustc_transmute` cleanups)
- #137800 (Remove `ParamEnv::without_caller_bounds`)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove `ParamEnv::without_caller_bounds`
This doesn't really do anything that `ParamEnv::empty` doesn't do nowadays as `ParamEnv` *only* stores caller bounds since other information has been moved out into `TypingMode`
r? ```@compiler-errors``` ```@lcnr```
Do not yeet `unsafe<>` from type when formatting unsafe binder
Unsafe binders are types like `unsafe<'a, 'b> Ty<'a, 'b>`. However, users can also specify unsafe binder types with no bound vars, like `unsafe<> Ty`.
When I added nightly formatting for unsafe binders, I didn't consider this, so on nightly we are stripping the `unsafe<>` part, which gives us back `Ty` which is a different type!
This PR fixes that.
r? ``@ytmimi``
Use `mk_ty_from_kind` a bit less, clean up lifetime handling in borrowck
r? ``@BoxyUwU``
Pulled out of my attempt to turn that `*const dyn Tr + '_` casting into a lint (which failed lmao)
Add missing case explanation for doc inlined re-export of doc hidden item
This case was not covered in the rustdoc book as uncovered in #137342.
r? ``@notriddle``
Introduce `feature(generic_const_parameter_types)`
Allows to define const generic parameters whose type depends on other generic parameters, e.g. `Foo<const N: usize, const ARR: [u8; N]>;`
Wasn't going to implement for this for a while until we could implement it with `bad_inference.rs` resolved but apparently the project simd folks would like to be able to use this for some intrinsics and the inference issue isn't really a huge problem there aiui. (cc ``@workingjubilee`` )
tests: fix up new test for nocapture -> capture(none) change
Same change as #136287, but for a newly introduced test.
``@rustbot`` label llvm-main
r? ``@nikic``
Tweak output of const panic diagnostic
### Shorten span of panic failures in const context
Previously, we included a redundant prefix on the panic message and a postfix of the location of the panic. The prefix didn't carry any additional information beyond "something failed", and the location of the panic is redundant with the diagnostic's span, which gets printed out even if its code is not shown.
```
error[E0080]: evaluation of constant value failed
--> $DIR/assert-type-intrinsics.rs:11:9
|
LL | MaybeUninit::<!>::uninit().assume_init();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ panic: aborted execution: attempted to instantiate uninhabited type `!`
```
```
error[E0080]: evaluation of `Fail::<i32>::C` failed
--> $DIR/collect-in-dead-closure.rs:9:19
|
LL | const C: () = panic!();
| ^^^^^^^^ explicit panic
|
= note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
```
error[E0080]: evaluation of constant value failed
--> $DIR/uninhabited.rs:87:9
|
LL | assert!(false);
| ^^^^^^^^^^^^^^ assertion failed: false
|
= note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)
```
### Remove duplicated span from const eval frame list
When the primary span for a const error is the same as the first frame in the const error report, skip it.
```
error[E0080]: evaluation of constant value failed
--> $DIR/issue-88434-removal-index-should-be-less.rs:3:24
|
LL | const _CONST: &[u8] = &f(&[], |_| {});
| ^^^^^^^^^^^^^^ explicit panic
|
note: inside `f::<{closure@$DIR/issue-88434-removal-index-should-be-less.rs:3:31: 3:34}>`
--> $DIR/issue-88434-removal-index-should-be-less.rs:10:5
|
LL | panic!()
| ^^^^^^^^ the failure occurred here
= note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
instead of
```
error[E0080]: evaluation of constant value failed
--> $DIR/issue-88434-removal-index-should-be-less.rs:10:5
|
LL | panic!()
| ^^^^^^^^ explicit panic
|
note: inside `f::<{closure@$DIR/issue-88434-removal-index-should-be-less.rs:3:31: 3:34}>`
--> $DIR/issue-88434-removal-index-should-be-less.rs:10:5
|
LL | panic!()
| ^^^^^^^^
note: inside `_CONST`
--> $DIR/issue-88434-removal-index-should-be-less.rs:3:24
|
LL | const _CONST: &[u8] = &f(&[], |_| {});
| ^^^^^^^^^^^^^^
= note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
note: erroneous constant encountered
--> $DIR/issue-88434-removal-index-should-be-less.rs:3:23
|
LL | const _CONST: &[u8] = &f(&[], |_| {});
| ^^^^^^^^^^^^^^^
```
r? ``@oli-obk``
The embedded bitcode should always be prepared for LTO/ThinLTO
Fixes#115344. Fixes#117220.
There are currently two methods for generating bitcode that used for LTO. One method involves using `-C linker-plugin-lto` to emit object files as bitcode, which is the typical setting used by cargo. The other method is through `-C embed-bitcode=yes`.
When using with `-C embed-bitcode=yes -C lto=no`, we run a complete non-LTO LLVM pipeline to obtain bitcode, then the bitcode is used for LTO. We run the Call Graph Profile Pass twice on the same module.
This PR is doing something similar to LLVM's `buildFatLTODefaultPipeline`, obtaining the bitcode for embedding after running `buildThinLTOPreLinkDefaultPipeline`.
r? nikic
Rollup of 9 pull requests
Successful merges:
- #137045 (Defer repeat expr `Copy` checks to end of type checking)
- #137171 (Suggest swapping equality on E0277)
- #137686 (Handle asm const similar to inline const)
- #137689 (Use `Binder<Vec<Ty>>` instead of `Vec<Binder<Ty>>` in both solvers for sized/auto traits/etc.)
- #137718 (Use original command for showing sccache stats)
- #137730 (checked_ilog tests: deal with a bit of float imprecision)
- #137735 (Update E0133 docs for 2024 edition)
- #137742 (unconditionally lower match arm even if it's unneeded for never pattern in match)
- #137771 (Tweak incorrect ABI suggestion and make suggestion verbose)
Failed merges:
- #137723 (Make `rust.description` more general-purpose and pass `CFG_VER_DESCRIPTION`)
r? `@ghost`
`@rustbot` modify labels: rollup
Tweak incorrect ABI suggestion and make suggestion verbose
Provide a better suggestion message, and make the suggestion verbose.
```
error[E0703]: invalid ABI: found `riscv-interrupt`
--> $DIR/riscv-discoverability-guidance.rs:17:8
|
LL | extern "riscv-interrupt" fn isr() {}
| ^^^^^^^^^^^^^^^^^ invalid ABI
|
= note: invoke `rustc --print=calling-conventions` for a full list of supported calling conventions
help: there's a similarly named valid ABI `riscv-interrupt-m`
|
LL | extern "riscv-interrupt-m" fn isr() {}
| ++
```
unconditionally lower match arm even if it's unneeded for never pattern in match
fixes#137708
Lowering arm body is skipped when lowering match arm with never pattern, but we may need the HirId for DefId in the body in later passes. And then we got the ICE `No HirId for DefId`.
Fixes this by lowering the arm body even if it's unneeded for never pattern in match, so that we can generate HirId and use it then.
r? `@compiler-errors`
Update E0133 docs for 2024 edition
The behavior of unsafe_op_in_unsafe_fn was changed in the 2024 edition. This updates this note in the E0133 docs to reflect that change.
Use original command for showing sccache stats
I used the newer advanced command after bumping Linux sccache to 0.9. However, Windows and macOS still use older sccache, so the command didn't work for them (the error was masked on CI though). It sucks that we don't see the Windows/macOS sccache stats, so until we update both of them, just use the older flag with slightly less information.
Use `Binder<Vec<Ty>>` instead of `Vec<Binder<Ty>>` in both solvers for sized/auto traits/etc.
It's more conceptually justified IMO, especially when binders get implications.
r? lcnr
Handle asm const similar to inline const
Previously, asm consts are handled similar to anon consts rather than inline consts. Anon consts are not good at dealing with lifetimes, because `type_of` has lifetimes erased already. Inline consts can deal with lifetimes because they live in an outer typeck context. And since `global_asm!` lacks an outer typeck context, we have implemented asm consts with anon consts while they're in fact more similar to inline consts.
This was changed in #137180, and this means that handling asm consts as inline consts are possible. While as `@compiler-errors` pointed out, `const` currently can't be used with any types with lifetime, this is about to change if #128464 is implemented. This PR is a preparatory PR for that feature.
As an unintentional side effect, fix#117877.
cc `@Amanieu`
r? `@compiler-errors`
Defer repeat expr `Copy` checks to end of type checking
Fixes#110443
Defers repeat expr checks that the element type is `Copy` when the length is > 1 (or generic) to end of typeck so that under `generic_arg_infer` repeat exprs are able to have an inferred count, e.g. `let a: [_; 1] = [String::new(); _];`.
Currently the deferring is gated under `generic_arg_infer` though I intend to separately types FCP deferring the checks even outside of `generic_arg_infer` if we wind up not going with an alternative.
Update cargo
11 commits in 1d1d646c06a84c1aa53967b394b7f1218f85db82..2622e844bc1e2e6123e54e94e4706f7b6195ce3d
2025-02-21 21:38:53 +0000 to 2025-02-28 12:33:57 +0000
- Bump `cc` to 1.2.16 to fix `x86` windows jobs in rust-lang/rust CI (rust-lang/cargo#15245)
- refactor(tree): Abstract the concept of a NodeId (rust-lang/cargo#15237)
- feat: implement RFC 3553 to add SBOM support (rust-lang/cargo#13709)
- refactor(tree): Abstract the concept of an edge (rust-lang/cargo#15233)
- chore: bump openssl to v3 (rust-lang/cargo#15232)
- fix(package): Register workspace member renames in overlay (rust-lang/cargo#15228)
- Implemented `build.build-dir` config option (rust-lang/cargo#15104)
- feat: add completions for `--manifest-path` (rust-lang/cargo#15225)
- chore: semver-check build-rs against beta channel (rust-lang/cargo#15223)
- chore: depend on openssl-sys to correctly pin its version (rust-lang/cargo#15224)
- chore: dont check cargo-util semver until 1.86 is released (rust-lang/cargo#15222)
Previously, we included a redundant prefix on the panic message and a postfix of the location of the panic. The prefix didn't carry any additional information beyond "something failed", and the location of the panic is redundant with the diagnostic's span, which gets printed out even if its code is not shown.
```
error[E0080]: evaluation of constant value failed
--> $DIR/assert-type-intrinsics.rs:11:9
|
LL | MaybeUninit::<!>::uninit().assume_init();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ evaluation panicked: aborted execution: attempted to instantiate uninhabited type `!`
```
```
error[E0080]: evaluation of `Fail::<i32>::C` failed
--> $DIR/collect-in-dead-closure.rs:9:19
|
LL | const C: () = panic!();
| ^^^^^^^^ evaluation panicked: explicit panic
|
= note: this error originates in the macro
`$crate::panic::panic_2015` which comes from the expansion of the macro
`panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
```
error[E0080]: evaluation of constant value failed
--> $DIR/uninhabited.rs:41:9
|
LL | assert!(false);
| ^^^^^^^^^^^^^^ evaluation panicked: assertion failed: false
|
= note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)
```
---
When the primary span for a const error is the same as the first frame in the const error report, skip it.
```
error[E0080]: evaluation of constant value failed
--> $DIR/issue-88434-removal-index-should-be-less.rs:3:24
|
LL | const _CONST: &[u8] = &f(&[], |_| {});
| ^^^^^^^^^^^^^^ evaluation panicked: explicit panic
|
note: inside `f::<{closure@$DIR/issue-88434-removal-index-should-be-less.rs:3:31: 3:34}>`
--> $DIR/issue-88434-removal-index-should-be-less.rs:10:5
|
LL | panic!()
| ^^^^^^^^ the failure occurred here
= note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
instead of
```
error[E0080]: evaluation of constant value failed
--> $DIR/issue-88434-removal-index-should-be-less.rs:10:5
|
LL | panic!()
| ^^^^^^^^ explicit panic
|
note: inside `f::<{closure@$DIR/issue-88434-removal-index-should-be-less.rs:3:31: 3:34}>`
--> $DIR/issue-88434-removal-index-should-be-less.rs:10:5
|
LL | panic!()
| ^^^^^^^^
note: inside `_CONST`
--> $DIR/issue-88434-removal-index-should-be-less.rs:3:24
|
LL | const _CONST: &[u8] = &f(&[], |_| {});
| ^^^^^^^^^^^^^^
= note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
---
Revert order of constant evaluation errors
Point at the code the user wrote first and std functions last.
```
error[E0080]: evaluation of constant value failed
--> $DIR/const-errs-dont-conflict-103369.rs:5:25
|
LL | impl ConstGenericTrait<{my_fn(1)}> for () {}
| ^^^^^^^^ evaluation panicked: Some error occurred
|
note: called from `my_fn`
--> $DIR/const-errs-dont-conflict-103369.rs:10:5
|
LL | panic!("Some error occurred");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
instead of
```
error[E0080]: evaluation of constant value failed
--> $DIR/const-errs-dont-conflict-103369.rs:10:5
|
LL | panic!("Some error occurred");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Some error occurred
|
note: called from `<() as ConstGenericTrait<{my_fn(1)}>>::{constant#0}`
--> $DIR/const-errs-dont-conflict-103369.rs:5:25
|
LL | impl ConstGenericTrait<{my_fn(1)}> for () {}
| ^^^^^^^^
= note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
Rollup of 9 pull requests
Successful merges:
- #136424 (fix: overflowing bin hex)
- #136824 (solver cycles are coinductive once they have one coinductive step)
- #137220 (Support `rust.channel = "auto-detect"`)
- #137712 (Clean up TypeckResults::extract_binding_mode)
- #137713 (Fix enzyme build errors)
- #137748 (Fix method name in `TyCtxt::hir_crate()` documentation)
- #137778 (update enzyme to handle range metadata)
- #137780 (Fix typo in query expansion documentation)
- #137788 (Bump `rustc_{codegen_ssa,llvm}` `cc` to 1.2.16 to fix `x86` Windows jobs on newest Windows SDK)
r? `@ghost`
`@rustbot` modify labels: rollup
linker: Fix escaping style for response files on Windows
If we use a С/С++ compiler as linker, then Posix-style escaping should be used.
Also temporarily fixup rustbuild to not fail at least in common scenarios, until the bootstrap compiler is updated.
Fixes https://github.com/rust-lang/rust/issues/137498
Fix Windows `Command` search path bug
Currently `Command::new` on Windows works differently depending on whether any environment variable is set. For example,
```rust
// Searches for "myapp" in the application and system paths first (aka Windows native behaviour).
Command::new("myapp").spawn();
// Search for "myapp" in `PATH` first
Command::new("myapp").env("a", "b").spawn();
```
This is a bug because the search path should only change if `PATH` is changed for the child (i.e. `.env("PATH", "...")`).
This was discussed in a libs-api meeting where the exact semantics of `Command::new` was not decided but there seemed to be broad agreement that this particular thing is just a bug that can be fixed.
r? libs-api
tests: use minicore more
minicore makes it much easier to add new language items to all of the existing `no_core` tests.
Most of the remaining tests that *could* use minicore either fail because..
1. LLVM IR output changes and doesn't pass the test as written. I didn't look into these further.
2. The test has revisions w/ different compilation flags, expecting some to fail, and when using minicore, minicore is compiled with those flags and fails in the expected way because of the flags rather than the test, and that's considered a failure.
But these tests can be changed and make adding new language items a lot easier.
r? ```@jieyouxu```
import `simd_` intrinsics
In most cases, we can import the simd intrinsics rather than redeclare them. Apparently, most of these tests were written before `std::intrinsics::simd` existed.
There are a couple of exceptions where we can't yet import:
- the intrinsics are not declared as `const fn` in the standard library, causing issues in the `const-eval` tests
- the `simd_shuffle_generic` function is not exposed from `std::intrinsics`
- the `simd_fpow` and `simd_fpowi` functions are not exposed from `std::intrinsics` (removed in https://github.com/rust-lang/rust/pull/137595)
- some tests use `no_core`, and therefore cannot use `std::intrinsics`
r? ```@RalfJung```
cc ```@workingjubilee``` do you have context on why some intrinsics are not exposed?
Fix (more) test directives that were accidentally ignored
Continuation of #137099 , caught by #137103 (and needed to unblock that one).
These test directives were accidentally using the old (`// ```@`)``` syntax
Update some comparison codegen tests now that they pass in LLVM20
Fixes#106107
Needed one tweak to the default `PartialOrd::le` to get the test to pass. Everything but the derived 2-field `le` test passes even without the change to the defaults in the trait.
Add FileCheck annotations to mir-opt/issues
This resolves a part of #116971 .
The directory `tests/mir-opt/issues` has only one test issue_75439.rs which should add FileCheck annotations.
Originally it was introduced in #75580 to confirm that there were duplicated basic blocks against or-patterns, but in #123067 the duplication was resolved. So FileCheck should ensure that there is no such duplication any more.
update enzyme to handle range metadata
r? `@oli-obk`
I landed two PRs over the last days, one of which is especially important because Enzyme now handles range metadata correctly. This allows a larger Rust project to compile.
Tracking:
- https://github.com/rust-lang/rust/issues/124509
Fix enzyme build errors
After [this PR](https://github.com/rust-lang/rust/pull/136428) was merged, I switched to master and attempted building `./x.py build --stage 1 library` with the config mentioned in the enzyme rustbook but it resulted in some errors tho the config.example.toml build succeeded
The errors were re:
### 1. Use of ref in match patterns
The errors were related to match ergonomics in Rust 2024, where ref is no longer needed when matching on references. Examples:
```
error: binding modifiers may only be written when the default binding mode is `move`
--> compiler/rustc_builtin_macros/src/autodiff.rs:136:31
|
136 | Annotatable::Item(ref iitem) => {
| ^^^ binding modifier not allowed under `ref` default binding mode
|
= note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/match-ergonomics.html>
note: matching on a reference type with a non-reference pattern changes the default binding mode
--> compiler/rustc_builtin_macros/src/autodiff.rs:136:13
|
136 | Annotatable::Item(ref iitem) => {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this matches on type `&_`
help: remove the unnecessary binding modifier
|
136 - Annotatable::Item(ref iitem) => {
136 + Annotatable::Item(iitem) => {
|
error: binding modifiers may only be written when the default binding mode is `move`
--> compiler/rustc_builtin_macros/src/autodiff.rs:146:36
|
146 | Annotatable::AssocItem(ref assoc_item, _) => {
| ^^^ binding modifier not allowed under `ref` default binding mode
|
= note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/match-ergonomics.html>
note: matching on a reference type with a non-reference pattern changes the default binding mode
--> compiler/rustc_builtin_macros/src/autodiff.rs:146:13
|
146 | Annotatable::AssocItem(ref assoc_item, _) => {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this matches on type `&_`
help: remove the unnecessary binding modifier
|
146 - Annotatable::AssocItem(ref assoc_item, _) => {
146 + Annotatable::AssocItem(assoc_item, _) => {
|
error: binding modifiers may only be written when the default binding mode is `move`
--> compiler/rustc_builtin_macros/src/autodiff.rs:174:31
|
174 | ... Annotatable::Item(ref iitem) => (iitem.vis.clone(), iitem.ide...
| ^^^ binding modifier not allowed under `ref` default binding mode
|
= note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/match-ergonomics.html>
note: matching on a reference type with a non-reference pattern changes the default binding mode
--> compiler/rustc_builtin_macros/src/autodiff.rs:174:13
|
174 | ... Annotatable::Item(ref iitem) => (iitem.vis.clone(), iitem.ident.c...
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this matches on type `&_`
help: remove the unnecessary binding modifier
|
174 - Annotatable::Item(ref iitem) => (iitem.vis.clone(), iitem.ident.clone()),
174 + Annotatable::Item(iitem) => (iitem.vis.clone(), iitem.ident.clone()),
|
error: binding modifiers may only be written when the default binding mode is `move`
--> compiler/rustc_builtin_macros/src/autodiff.rs:175:36
|
175 | Annotatable::AssocItem(ref assoc_item, _) => {
| ^^^ binding modifier not allowed under `ref` default binding mode
|
= note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/match-ergonomics.html>
note: matching on a reference type with a non-reference pattern changes the default binding mode
--> compiler/rustc_builtin_macros/src/autodiff.rs:175:13
|
175 | Annotatable::AssocItem(ref assoc_item, _) => {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this matches on type `&_`
help: remove the unnecessary binding modifier
|
175 - Annotatable::AssocItem(ref assoc_item, _) => {
175 + Annotatable::AssocItem(assoc_item, _) => {
|
error: could not compile `rustc_builtin_macros` (lib) due to 4 previous errors
warning: build failed, waiting for other jobs to finish...
Build completed unsuccessfully in 0:19:39
```
### 2. the use of external C blocks without unsafe in compiler/rustc_codegen_llvm/src/llvm/enzyme_ffi.rs (I don't have the error message handy)
The first commit fixes the errors above
---
## Additional Improvement:
`@ZuseZ4` suggested we consolidate the variants under `#[cfg(llvm_enzyme)]` and `#[cfg(not(llvm_enzyme))]` by conditionally checking for `cfg!(llvm_enzyme)` instead. This way, the autodiff code is compiled but not executed avoiding such regressions
r? `@ZuseZ4`
cc: `@oli-obk`
Clean up TypeckResults::extract_binding_mode
- Remove the `Option` from the result type, as `None` is never returned.
- Document the difference from the `BindingMode` in `PatKind::Binding`.
solver cycles are coinductive once they have one coinductive step
Implements the new cycle semantics in the new solver, dealing with the fallout from https://github.com/rust-lang/trait-system-refactor-initiative/issues/10.
The first commit has been extensively fuzzed via https://github.com/lcnr/search_graph_fuzz.
A trait solver cycle is now coinductive if it has at least one *coinductive step*. A step is only considered coinductive if it's a where-clause of an impl of a coinductive trait. The only coinductive traits are `Sized` and auto traits.
This differs from the current stable because where a cycle had to consist of exclusively coinductive goals. This is overly limiting and wasn't properly enforced as it (mostly) ignored all non-trait goals.
A more in-depth explanation of my reasoning can be found in this separate doc: https://gist.github.com/lcnr/c49d887bbd34f5d05c36d1cf7a1bf5a5. A summary:
- imagine using dictionary passing style: map where-bounds to additional "dictonary" fn arguments instead of monomorphization
- impls are the only source of truth and introduce a *constructor* of the dictionary type
- a trait goal holds if mapping its proof tree to dictionary passing style results in a valid corecursive function
- a corecursive function is valid if it is guarded: matching on it should result in a constructor in a finite amount of time. This property should recursively hold for all fields of the constructor
- a function is guarded if the recursive call is *behind* a constructor
- **and** this constructor is not *moved out of*, e.g. by accessing a field of the dictionary
- the "not moved out of" condition is difficult to guarantee in general, e.g. for item bounds of associated types. However, there is no way to *move out* of an auto trait as there is no information you can get from *the inside of* an auto trait bound in the trait system
- if we encounter a cycle/recursive call which involves an auto trait, we can always convert the proof tree into a non-recursive function which calls a corecursive function whose first step is the construction of the auto trait dict and which only recursively depends on itself (by inlining the original function until they reach the uses of the auto trait)
**we can therefore make any cycle during which we step into an auto trait (or `Sized`) impl coinductive**
----
To fix https://github.com/rust-lang/trait-system-refactor-initiative/issues/10 we could go with a more restrictive version which tries to restrict cycles to only allow code already supported on stable, potentially forcing cycles to be ambiguous if they step through an impl-where clause of a non-coinductive trait.
`PathKind` should be a strictly ordered set to allow merging paths without worry. We could therefore add another variant `PathKind::ForceUnknown` which is greater than `PathKind::Coinductive`. We already have to add such a third `PathKind` in #137314 anyways.
I am not doing this here due to multiple reasons:
- I cannot think of a principled reason why cycles using an impl to normalize differ in any way from simply using that impl to prove a trait bound. It feels unnecessary and like it makes it more difficult to reason about our cycle semantics :<
- This PR does not affect stable as coherence doesn't care about whether a goal holds or is ambiguous. So we don't yet have to make a final decision
r? `@compiler-errors` `@nikomatsakis`
fix: overflowing bin hex
**Overview:**
- This PR fixes#135404.
**Testing**
- Tested the updated functionality.
- previously emitted diagnostics:
```bash
error: literal out of range for `i32`
--> src/main.rs:2:9
|
2 | _ = 0x8FFF_FFFF_FFFF_FFFE;
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: the literal `0x8FFF_FFFF_FFFF_FFFE` (decimal `10376293541461622782`) does not fit into the type `i32` and will become `-2i32`
= help: consider using the type `i128` instead
= note: `#[deny(overflowing_literals)]` on by default
help: to use as a negative number (decimal `-2`), consider using the type `u32` for the literal and cast it to `i32`
|
2 | _ = 0x8FFF_FFFF_FFFF_FFFEu32 as i32;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
- current diagnostics:
```bash
error: literal out of range for `i32`
--> ../temp.rs:2:13
|
2 | let x = 0x8FFF_FFFF_FFFF_FFFE;
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: the literal `0x8FFF_FFFF_FFFF_FFFE` (decimal `10376293541461622782`) does not fit into the type `i32` and will become `-2i32`
= help: consider using the type `u64` instead
= note: `#[deny(overflowing_literals)]` on by default
help: to use as a negative number (decimal `-2`), consider using the type `u64` for the literal and cast it to `i32`
|
2 | let x = 0x8FFF_FFFF_FFFF_FFFEu64 as i32;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
