Open nikomatsakis opened 3 years ago
Implementation steps:
chalk_ir
with a FnDefTy { fn_def_id, substitution }
(analogous to ProjectionTy
) and reference it from TyKind::FnDef
DomainGoal
with a NormalizeFn(FnDefTy, Ty)
predicate; the output type will (in practice) always be a FnDef
type, but it's a pain to encode that I think so not worth it
FnDefTy
represents the FnDef
for the unnormalized trait method TraitDatum
probably needs a list of functions (FnDefTy
) for each thing in the traitImplDatum
needs to have "fn-def values" for each method in the implRustIrDatabase
needs a way to query for information about a fn-def value
Actually, I think we have function signature and other information already accessible for FnDef
, so we should leverage that.
The program_clauses_that_could_match
function needs to be extended so that when we try to prove a NormalizeFn
goal, we go to the relevant impls, and we generate NormalizeFn
rules.
We ought to be able to write unit tests that include fn foo<A>() { }
in them. We may want to include ABI and argument types -- I think we already have some of that logic in order to generate the impls of the Fn
traits, so we just want to extend it to be included within traits and impls.
@rustbot assign @lf-
I am working on this on https://github.com/lf-/chalk/tree/source-impl (obviously it will be rebased and commits cleaned up when it's ready for proper review; I'm posting this for reference)
So far done:
To do as I keep going:
Confused about:
What to generate for program clauses for NormalizeFn(FnDefTy, Ty)
. I would really like an example of something reasonable for this from the stdlib for instance. I'm currently unsure what exact info this goal needs to encode and what program clauses to make.
So that was a lie. It turns out the lowering and parsing contains way more lowering and parsing than I thought ðŸ˜. Moving slowly but getting places. Total diff has already crossed 1000 lines :V
@rustbot release-assignment
@jackh726, is this up for grabs? i would be interested in continuing the work in the linked PR. been looking for some chalk work.
I think in theory yes. But this is more of a question for Niko. He said he has thoughts for a different approach :)
@compiler-errors I'd be very psyched to see you continue with this work!
I did have thoughts for another approach, but essentially what I wanted to do was to make "methods" kind of a special sort of associated type, I believe. We could schedule some time to talk about it at https://calendly.com/nikomatsakis/, @compiler-errors.
I think it would be cool to treat associated types, consts, and methods similarly in how we resolve them (thinking with #745 in mind)
As part of rust-analyzer/rust-analyzer#4558, we would like to extend chalk so that it can identify the fn that will run. The basic idea is to model this in a similar fashion to how associated type normalization works.
Summary of the idea
Given:
where
method
has the typeFnDef(X, [_])
we will generate a program clause likeRust-analyzer can then do a query like
NormalizeFn(<Foo as Bar<u32>>::method => ?X)
to find theFnDef
type for the method that will run (which includes its unique id and the values of all its relevant type parameters).