Indirect checking for return_type through an extra function#26836
Indirect checking for return_type through an extra function#26836
Conversation
It's definitely wrong to treat a second copy of But, also, this won't (shouldn't?) do anything, since you can't alter the type-infer method table at runtime. |
I don't care if it's wrong as long as it works and is useful ;). Also, I would question your "related in any way" assertion. After all, they implement the same semantics.
I'm not altering the type-infer method table, I'm loading a second copy of inference where |
Compiler.return_type is a bit of an odd beast because we basically treat it like a built-in, but it's defined in the compiler. When working on inference, it can be useful to load a second copy of inference with the new changes (e.g. to test changes before the changes are capable of running correctly on all input). This works quite well, but was causing problems with return type, because Base's notion of return_type and the second inference copy's notion of return_type were different. This patch adds a simple is_return_type(f) predicate that we can overload in our second inference copy in order to make it recognize both Core.Compiler.return_type and return_type (from the second copy's perspective as the return_type builtin).
|
Needed this again. I rebased this. Since it doesn't affect the regular use case, but is very useful for my development purposes, I plan to merge this once CI goes through. |
Compiler.return_type is a bit of an odd beast because we basically treat
it like a built-in, but it's defined in the compiler. When working on
inference, it can be useful to load a second copy of inference with
the new changes (e.g. to test changes before the changes are capable
of running correctly on all input). This works quite well, but was
causing problems with return type, because Base's notion of
return_type and the second inference copy's notion of return_type
were different. This patch adds a simple
is_return_type(f)predicatethat we can overload in our second inference copy in order to make it
recognize both
Core.Compiler.return_typeandreturn_type(fromthe second copy's perspective as the return_type builtin).
@jrevels this fixes that weird non-inference of matvec we saw yesterday