-
Notifications
You must be signed in to change notification settings - Fork 13.3k
ICE in cargo doc with optin_builtin_traits #55321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
My bad, I appear to have accidentally used a version of rust that wasn't up to date.
Sorry again about that. |
It looks like |
Fixes rust-lang#55321 When AutoTraitFinder begins examining a type, it checks for an explicit negative impl. However, it wasn't checking for negative impls found when calling 'select' on predicates found from nested obligations. This commit makes AutoTraitFinder check for negative impls whenever it makes a call to 'select'. If a negative impl is found, it immediately bails out. Normal users of SelectioContext don't need to worry about this, since they stop as soon as an Unimplemented error is encountered. However, we add predicates to our ParamEnv when we encounter this error, so we need to handle negative impls specially (so that we don't try adding them to our ParamEnv).
Looks like this error has been there the whole time that synthetic impls have been there - that sample fails all the way back to 1.26.0. |
…sakis Check for negative impls when finding auto traits Fixes #55321 When AutoTraitFinder begins examining a type, it checks for an explicit negative impl. However, it wasn't checking for negative impls found when calling 'select' on predicates found from nested obligations. This commit makes AutoTraitFinder check for negative impls whenever it makes a call to 'select'. If a negative impl is found, it immediately bails out. Normal users of SelectioContext don't need to worry about this, since they stop as soon as an Unimplemented error is encountered. However, we add predicates to our ParamEnv when we encounter this error, so we need to handle negative impls specially (so that we don't try adding them to our ParamEnv).
Hi, I noticed a weird internal error using
cargo doc
. The smallest example I could make to reproduce the bug is an basic library project (cargo init --lib
) whose lib.rs contains:cargo build
,cargo build --release
, andcargo check
all work fine; and as mentioned in the code, the place whereB
is declared seems to matter.Here is the output and trace of
cargo doc --verbose
: [log was from an out of date nightly rust, see my comment below for the log for the latest nightly as of this edit]Have a nice day.
The text was updated successfully, but these errors were encountered: