| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #132388 (Implement `#[cfg]` in `where` clauses)
- #134900 (Fix parsing of ranges after unary operators)
- #136938 (Remove `:` from `stack-protector-heuristics-effect.rs` Filecheck Pattern)
- #137054 (Make phantom variance markers transparent)
- #137525 (Simplify parallelization in test-float-parse)
- #137618 (Skip `tidy` in pre-push hook if the user is deleting a remote branch)
- #137741 (Stop using `hash_raw_entry` in `CodegenCx::const_str`)
- #137849 (Revert "Remove Win SDK 10.0.26100.0 from CI")
- #137862 (ensure we always print all --print options in help)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix pretty printing of unsafe binders
We used to render `unsafe<> i32` as `i32`, and `unsafe<'a> &'a i32` as `for<'a> &'a i32`.
r? oli-obk
Review with whitespace b/c adding a new argument changes some the wrapping of some function calls.
|
|
Rollup of 6 pull requests
Successful merges:
- #137103 ({json|html}docck: catch and error on deprecated syntax)
- #137632 (rustdoc: when merging target features, keep the highest stability)
- #137684 (Add rustdoc support for `--emit=dep-info[=path]`)
- #137794 (make qnx pass a test)
- #137801 (tests: Unignore target modifier tests on all platforms)
- #137826 (test(codegen): add looping_over_ne_bytes test for #133528)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
When encountering a resolve E0575 error for an associated method (when a type was expected), see if it could have been an intended return type notation bound.
```
error[E0575]: expected associated type, found associated function `Trait::method`
--> $DIR/bad-inputs-and-output.rs:31:36
|
LL | fn foo_qualified<T: Trait>() where <T as Trait>::method(i32): Send {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^ not a associated type
|
help: you might have meant to use the return type notation syntax
|
LL - fn foo_qualified<T: Trait>() where <T as Trait>::method(i32): Send {}
LL + fn foo_qualified<T: Trait>() where T::method(..): Send {}
|
```
|
|
|
|
|
|
ensure we always print all --print options in help
Closes #137853
Refactors the PRINT_KINDS map into a public const so we always print every option for print. the list is quite long now, and idk if long term we want to keep printing all these options from --help.
|
|
Fix parsing of ranges after unary operators
Fixes https://github.com/rust-lang/rust/issues/134899.
This PR aligns the parsing for unary `!` and `-` and `*` with how unary `&` is already parsed [here](https://github.com/rust-lang/rust/blob/5c0a6e68cfdad859615c2888de76505f13e6f01b/compiler/rustc_parse/src/parser/expr.rs#L848-L854).
|
|
Implement `#[cfg]` in `where` clauses
This PR implements #115590, which supports `#[cfg]` attributes in `where` clauses.
The biggest change is, that it adds `AttrsVec` and `NodeId` to the `ast::WherePredicate` and `HirId` to the `hir::WherePredicate`.
|
|
|
|
Otherwise this test will include a future incompatibility warning
on some targets but not others.
|
|
|
|
|
|
tests: Unignore target modifier tests on all platforms
These tests can be `check-pass` and do not need dynamic libraries.
Also remove other unnecessary stuff from them.
Follow up to https://github.com/rust-lang/rust/pull/133138.
|
|
make qnx pass a test
[tests/ui/attributes/used_with_archive.rs](https://github.com/rust-lang/rust/blob/b2024300840c3ef94a97273531bdb37d56d50fb5/tests/ui/attributes/used_with_archive.rs) fails when executed for QNX targets, because its stdout does not match [this content](https://github.com/rust-lang/rust/blob/b2024300840c3ef94a97273531bdb37d56d50fb5/tests/ui/attributes/used_with_archive.run.stdout)
|
|
|
|
|
|
rustc_target: Add msync target feature and enable it on powerpcspe targets
Some older PowerPC processors do not have the `sync` (`sync 0`) and `lwsync` (`sync 1`) instructions, but instead have the `msync` instruction. (IIRC `msync` and `sync` will be assembled into the same bit-pattern, but `lwsync` will be SIGILL. See also https://gcc.gnu.org/legacy-ml/gcc-patches/2006-11/msg01238.html.)
LLVM recognizes this as the [`msync` feature](https://github.com/llvm/llvm-project/blob/cc5d8a4b2fc765c3c432f1ad0b185dae518d41bd/llvm/lib/Target/PowerPC/PPC.td#L140) and enables for some cpus such as [e500](https://github.com/llvm/llvm-project/blob/cc5d8a4b2fc765c3c432f1ad0b185dae518d41bd/llvm/lib/Target/PowerPC/PPC.td#L644).
powerpcspe is a target for CPUs such as e500 ([Debian Wiki](https://wiki.debian.org/PowerPCSPEPort)). However, the `msync` feature is currently not enabled except for vxworks, and at least since 2022-04, powerpc-unknown-linux-gnuspe was known to not work on real hardware without `-C target-cpu` (e.g., #96394, #117361).
https://github.com/rust-lang/rust/blob/8c392966a013fd8a09e6b78b3c8d6e442bc278e1/compiler/rustc_target/src/spec/targets/powerpc_wrs_vxworks_spe.rs#L28
Fixes #117361
cc `@BKPepe` ([powerpc-unknown-linux-muslspe target maintainer](https://doc.rust-lang.org/nightly/rustc/platform-support/powerpc-unknown-linux-muslspe.html#target-maintainers))
cc `@glaubitz` (who added powerpc-unknown-linux-gnuspe in https://github.com/rust-lang/rust/pull/48484)
cc `@th0ma7` (who opened #117361)
r? workingjubilee
`@rustbot` label +O-PowerPC +A-target-feature
|
|
r=workingjubilee
improve `simd_select` error message when used with invalid mask type
followup to https://github.com/rust-lang/rust/pull/137828
This PR improves the error message for an invalid `simd_select` mask type, and adds testing for `simd_scatter` and `simd_gather` being used with invalid mask types.
the `simd_masked_load` and `simd_masked_store` intrinsics already generated a better error message:
https://github.com/rust-lang/rust/blob/0c72c0d11adeba449886089c6bd5d48363f7a2cd/tests/ui/simd/masked-load-store-build-fail.rs#L24-L37
r? `@workingjubilee`
|
|
typeck
|
|
|
|
|
|
Tweak invalid RTN errors
Make suggestions verbose.
When encountering `method(type)` bound, suggest `method(..)` instead of `method()`.
```
error: argument types not allowed with return type notation
--> $DIR/bad-inputs-and-output.rs:9:23
|
LL | fn foo<T: Trait<method(i32): Send>>() {}
| ^^^^^
|
help: remove the input types
|
LL - fn foo<T: Trait<method(i32): Send>>() {}
LL + fn foo<T: Trait<method(..): Send>>() {}
|
```
When encountering both return type and arg list that isn't `..`, suggest replacing both.
```
error: return type not allowed with return type notation
--> $DIR/bad-inputs-and-output.rs:12:25
|
LL | fn bar<T: Trait<method() -> (): Send>>() {}
| ^^^^^^
|
help: use the right argument notation and remove the return type
|
LL - fn bar<T: Trait<method() -> (): Send>>() {}
LL + fn bar<T: Trait<method(..): Send>>() {}
|
```
When encountering a return type, suggest removing it including the leading whitespace.
```
error: return type not allowed with return type notation
--> $DIR/bad-inputs-and-output.rs:24:45
|
LL | fn bay_path<T: Trait>() where T::method(..) -> (): Send {}
| ^^^^^
|
help: remove the return type
|
LL - fn bay_path<T: Trait>() where T::method(..) -> (): Send {}
LL + fn bay_path<T: Trait>() where T::method(..): Send {}
|
```
r? ``@compiler-errors``
|
|
|
|
|
|
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`` )
|
|
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``
|
|
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`
|
|
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`
|
|
Suggest swapping equality on E0277
Closes: #132695 .
|
|
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.
|
|
On mips64-openwrt-linux-musl target.
|
|
Rollup of 10 pull requests
Successful merges:
- #134943 (Add FileCheck annotations to mir-opt/issues)
- #137017 (Don't error when adding a staticlib with bitcode files compiled by newer LLVM)
- #137197 (Update some comparison codegen tests now that they pass in LLVM20)
- #137540 (Fix (more) test directives that were accidentally ignored)
- #137551 (import `simd_` intrinsics)
- #137599 (tests: use minicore more)
- #137673 (Fix Windows `Command` search path bug)
- #137676 (linker: Fix escaping style for response files on Windows)
- #137693 (Re-enable `--generate-link-to-defintion` for tools internal rustdoc)
- #137770 (Fix sized constraint for unsafe binder)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove `NtPat`, `NtMeta`, and `NtPath`
Another part of #124141.
r? `@petrochenkov`
|
|
Make suggestions verbose.
When encountering `method(type)` bound, suggest `method(..)` instead of `method()`.
```
error: argument types not allowed with return type notation
--> $DIR/bad-inputs-and-output.rs:9:23
|
LL | fn foo<T: Trait<method(i32): Send>>() {}
| ^^^^^
|
help: remove the input types
|
LL - fn foo<T: Trait<method(i32): Send>>() {}
LL + fn foo<T: Trait<method(..): Send>>() {}
|
```
When encountering both return type and arg list that isn't `..`, suggest replacing both.
```
error: return type not allowed with return type notation
--> $DIR/bad-inputs-and-output.rs:12:25
|
LL | fn bar<T: Trait<method() -> (): Send>>() {}
| ^^^^^^
|
help: use the right argument notation and remove the return type
|
LL - fn bar<T: Trait<method() -> (): Send>>() {}
LL + fn bar<T: Trait<method(..): Send>>() {}
|
```
When encountering a return type, suggest removing it including the leading whitespace.
```
error: return type not allowed with return type notation
--> $DIR/bad-inputs-and-output.rs:24:45
|
LL | fn bay_path<T: Trait>() where T::method(..) -> (): Send {}
| ^^^^^
|
help: remove the return type
|
LL - fn bay_path<T: Trait>() where T::method(..) -> (): Send {}
LL + fn bay_path<T: Trait>() where T::method(..): Send {}
|
```
|
|
|
|
Instead, we adopt the position that introducing an `unsafe` field
itself carries a safety invariant: that if you assign an invariant
to that field weaker than what the field's destructor requires,
you must ensure that field is in a droppable state in your
destructor.
See:
- https://github.com/rust-lang/rfcs/pull/3458#discussion_r1971676100
- https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/unsafe.20fields.20RFC/near/502113897
|
|
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)
```
|
|
|
|
These tests can be `check-pass` and do not need dynamic libraries.
Also remove other unnecessary stuff from them.
|
|
Fix sized constraint for unsafe binder
Fixes #137705
r? oli-obk
|
|
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?
|
|
r=notriddle
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
|
|
Fixes tests/ui/attributes/used_with_archive.rs fail
|
|
|
|
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`
|
