-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Implement fallback for effect param #115727
Conversation
Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
This comment has been minimized.
This comment has been minimized.
@@ -1577,6 +1577,14 @@ pub struct ConstVid<'tcx> { | |||
pub phantom: PhantomData<&'tcx ()>, | |||
} | |||
|
|||
/// An **effect** **v**ariable **ID**. |
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.
Why are effects being represented with a separate vid?
There's a weird dichotomy happening here where effects are kinda treated like const and kinda like their own kind, and it's not exactly clear why.
Shouldn't we be able to store whether a const vid comes from an effect parameter in the const vid table so it can participate in fallback later?
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.
I kinda just followed how int and float type variables also have their own vids. We'd probably want to ensure that we know all variables instantiated for an effect param are actually for an effect param, and having a separate vid helped by catching things like relating a normal const var with an effect var which should never happen.
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.
Yeah, maybe that's better. This definitely needs documentation though -- that's a design decision that (afaict? maybe i'm just out of the loop) isn't written anywhere, and it should be probably 😺
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.
added a comment
0b9ab98
to
84a4907
Compare
@@ -443,6 +448,14 @@ impl<'tcx> CanonicalVarValues<'tcx> { | |||
}; | |||
ty::Region::new_late_bound(tcx, ty::INNERMOST, br).into() | |||
} | |||
// todo eh? |
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.
leftover comment
@@ -873,14 +873,14 @@ fn should_encode_attrs(def_kind: DefKind) -> bool { | |||
| DefKind::AssocConst | |||
| DefKind::Macro(_) | |||
| DefKind::Field | |||
| DefKind::Impl { .. } => true, | |||
| DefKind::Impl { .. } | |||
| DefKind::ConstParam => true, |
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.
do we need to encode const param attrs in metadata? I'd assume we'd get all the information from ty::Generics
if it's from an upstream crate
// todo what about using effect var here | ||
if self.tcx.has_attr(param.def_id, sym::rustc_host) { |
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.
hmm 🤔 I guess we could add a is_host_effect: bool
field to GenericParamDefKind::Const
to make this simpler. it's not going to increase the size of GenericParamDefKind
, even if we change it to an enum at some point to encode different effect kinds
fn effect_unification_error<'tcx>( | ||
tcx: TyCtxt<'tcx>, | ||
a_is_expected: bool, | ||
(a, b): (EffectVarValue<'tcx>, EffectVarValue<'tcx>), | ||
) -> TypeError<'tcx> { | ||
TypeError::ConstMismatch(ExpectedFound::new(a_is_expected, a.as_const(tcx), b.as_const(tcx))) | ||
} |
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.
Can this be hit at all at present?
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.
The tests pass with changing this to a bug
so probably not (but we also don't test effects that much lol) I'll change this to panic and then see if we can get a better diagnostic if we actually hit it.
This PR changes Stable MIR cc @oli-obk, @celinval, @spastorino |
@bors r+ |
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#115335 (fix overflow in array length computation) - rust-lang#115440 (bootstrap/format: remove unnecessary paths.push) - rust-lang#115702 (Update mailmap) - rust-lang#115727 (Implement fallback for effect param) - rust-lang#115739 (Call `LateLintPass::check_attribute` from `with_lint_attrs`) - rust-lang#115743 (Point out if a local trait has no implementations) - rust-lang#115744 (Improve diagnostic for generic params from outer items (E0401)) - rust-lang#115752 (rustdoc: Add missing "Aliased type" title in the sidebar) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#115727 - fee1-dead-contrib:effect-fallback, r=oli-obk Implement fallback for effect param r? `@oli-obk` or `@lcnr` tracking issue for this ongoing work: rust-lang#110395
…ler-errors Remove a hack for effects Fallback was implemented in rust-lang#115727, which addresses the inference errors mentioned in the comments.
Rollup merge of rust-lang#118246 - fee1-dead-contrib:rm-hack, r=compiler-errors Remove a hack for effects Fallback was implemented in rust-lang#115727, which addresses the inference errors mentioned in the comments.
r? @oli-obk or @lcnr
tracking issue for this ongoing work: #110395