Skip to content
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

Don't even try to combine consts with incompatible types #108947

Merged
merged 2 commits into from
Mar 11, 2023

Conversation

compiler-errors
Copy link
Member

@compiler-errors compiler-errors commented Mar 9, 2023

I left a more detailed explanation for why this fixes this issue in the UI test, but in general, we should not try to unify const infer vars and rigid consts if they have incompatible types. That's because we don't want something like a ConstArgHasType predicate to suddenly go from passing to failing, or vice versa, due to a shallow resolve.

  1. Use the type_of for a parameter in try_eval_lit_or_param, instead of the "expected" type from a WithOptConstParam def id.
  2. Don't combine consts that have incompatible types.

Fixes #108781

@rustbot
Copy link
Collaborator

rustbot commented Mar 9, 2023

r? @wesleywiser

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 9, 2023
@compiler-errors
Copy link
Member Author

oops forgor to r?

r? @BoxyUwU

@rustbot rustbot assigned BoxyUwU and unassigned wesleywiser Mar 9, 2023
@rustbot

This comment was marked as outdated.

Comment on lines 11 to 13
// and unify it against impl #2's trait ref with fresh vars. The trait ref of
// impl #1 is `S<Const(Param(N/#0): usize)>` because of astconv using the type
// from the `L` substitution of struct `S`. This unifies successfully with impl #2,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The trait ref of impl #1 is S<Const(Param(N/#0): usize)> because of astconv using the type from the L substitution of struct S.

I guess I could be a bit more explicit here -- I'm talking about this code:

(GenericParamDefKind::Const { .. }, GenericArg::Const(ct)) => {
ty::Const::from_opt_const_arg_anon_const(
tcx,
ty::WithOptConstParam {
did: ct.value.def_id,
const_param_did: Some(param.def_id),
},
)
.into()
}

So when instantiating the substs for S<N>, we use the const param did from L, and end up with S<Const(Param(N/#0): usize)>, even though N has the type i32 at its declaration. This is surprising, I guess, but also makes sense from the implementation of the astconv code.

@compiler-errors
Copy link
Member Author

Alternative fix to this would be, uh, replacing this

let impl1_trait_ref = tcx.impl_trait_ref(impl1_def_id).unwrap().subst_identity();

with

let impl1_trait_ref = tcx.impl_trait_ref(impl1_def_id).unwrap().subst(tcx, ty::InternalSubsts::identity_for_item(tcx, impl1_def_id));

Or making subst_identity do that in general... Or just delaying a span bug where the original ICE happens. But those both seem like like a spot fix to a bigger problem, where we don't necessarily want/need to do const infer when the consts' types don't match up right due to WF issues.

@compiler-errors compiler-errors force-pushed the ct-infer-no-shapeshifting branch from 78f0613 to f714613 Compare March 9, 2023 20:53
@BoxyUwU
Copy link
Member

BoxyUwU commented Mar 9, 2023

r=me if CI passes

@compiler-errors
Copy link
Member Author

@bors r=BoxyUwU

@bors
Copy link
Contributor

bors commented Mar 9, 2023

📌 Commit f714613 has been approved by BoxyUwU

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Mar 9, 2023

🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 9, 2023
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 11, 2023
…iaskrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#106921 (Add documentation about the memory layout of `Cell`)
 - rust-lang#108828 (Emit alias-eq when equating numeric var and projection)
 - rust-lang#108834 (Do not ICE when we have fn pointer `Fn` obligations with bound vars in the self type)
 - rust-lang#108900 (fix(lexer): print whitespace warning for \x0c)
 - rust-lang#108930 (feat: implement better error for manual impl of `Fn*` traits)
 - rust-lang#108937 (improve readability of winnowing)
 - rust-lang#108947 (Don't even try to combine consts with incompatible types)
 - rust-lang#108976 (Update triagebot rust-analyzer team mention)
 - rust-lang#108983 (Forbid `#[target_feature]` on safe default implementations)

Failed merges:

 - rust-lang#108950 (Directly construct Inherited in typeck.)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 145e620 into rust-lang:master Mar 11, 2023
@rustbot rustbot added this to the 1.70.0 milestone Mar 11, 2023
@compiler-errors compiler-errors deleted the ct-infer-no-shapeshifting branch August 11, 2023 19:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
5 participants