-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Do not mix normalized and unnormalized caller bounds when constructing param-env for receiver_is_dispatchable
#138941
Do not mix normalized and unnormalized caller bounds when constructing param-env for receiver_is_dispatchable
#138941
Conversation
did you forget to commit that test? |
probably :) |
086e683
to
cd7c99b
Compare
// after normalizing `<PF as TraitC>::Value = <PF as TraitD>::Scalar`. Since | ||
// `normalize_param_env_or_error` ends up re-elaborating `PF: TraitD`, we'd | ||
// end up with both versions of this predicate (normalized and unnormalized). | ||
// Since these projections preds are not equal, we'd fail with ambiguity. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
its during normalize_param_env_or_error
that we error due to there being two candidates? or is this a weird case where it doesnt wind up actually normalizing like it should
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We error during normalize_param_env_or_error
b/c we have two candidates for normalizing <PF as TraitC>::Value
, which shows up in the supertrait TraitB<Self::Value>
. The first candidate comes from normalizing the param-env the first time in the param_env
query, and the second comes from the second time we normalize it.
…g param-env for receiver_is_dispatchable
cd7c99b
to
4f2baaa
Compare
k i added a comment |
@bors r+ rollup |
Rollup of 14 pull requests Successful merges: - rust-lang#135295 (Check empty SIMD vector in inline asm) - rust-lang#138003 (Add the new `amx` target features and the `movrs` target feature) - rust-lang#138823 (rustc_target: RISC-V: add base `I`-related important extensions) - rust-lang#138913 (Remove even more instances of `@ts-expect-error` from search.js) - rust-lang#138941 (Do not mix normalized and unnormalized caller bounds when constructing param-env for `receiver_is_dispatchable`) - rust-lang#139060 (replace commit placeholder in vendor status with actual commit) - rust-lang#139102 (coverage: Avoid splitting spans during span extraction/refinement) - rust-lang#139191 (small opaque type/borrowck cleanup) - rust-lang#139200 (Skip suggest impl or dyn when poly trait is not a real trait) - rust-lang#139208 (fix dead link netbsd.md) - rust-lang#139210 (chore: remove redundant backtick) - rust-lang#139212 (Update mdbook to 0.4.48) - rust-lang#139214 (Tell rustfmt to use the 2024 edition in ./x.py fmt) - rust-lang#139225 (move autodiff from EnzymeAD/Enzyme to our rust-lang/Enzyme soft-fork) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#138941 - compiler-errors:receiver-is-dispatchable-bounds, r=BoxyUwU Do not mix normalized and unnormalized caller bounds when constructing param-env for `receiver_is_dispatchable` See comments in code and in test I added. r? `@BoxyUwU` since you reviewed the last PR, or reassign Fixes rust-lang#138937
See comments in code and in test I added.
r? @BoxyUwU since you reviewed the last PR, or reassign
Fixes #138937