RFR: 8325859: potential information loss during type inference [v7]

Maurizio Cimadamore mcimadamore at openjdk.org
Tue May 20 10:14:03 UTC 2025


On Mon, 19 May 2025 21:47:14 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> When an inference context (`IC`) is minimized, the minimized inference context (`MIC`) contains a proper subset of `IC's` inference vars (`IC_IV`). In other words there will be at least one inference variable `T` that belongs to `IC_IV` which doesn't belong to the minimized context inference variable's set (`MIC_IV`). MIC can be propagated to another inference context (AIC) as part of the type inference algo. If at any moment a type containing `T` needs, for example, to be instantiated `AIC` won't be able to perform that operation as it lacks the information to realize that `T` is a free variable it was supposed to know about hadn't a minimization step been performed. This PR is proposing to fix this issue without reducing the universe of inference contexts we apply the minimization algo to.
>> 
>> We are basically proposing to add a field to class InferenceContext which will be supplementary inference context that can be used to look for additional information if necessary. Also when registering a free type listener to an inference context, it could be that it won't be registered in the inference context the client could expect but in a supplementary inference context if it is found out that it contains and instantiation to all the free variables related to the listener. See also some comments inlined in the code,
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   field renamed

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/InferenceContext.java line 280:

> 278:     void addFreeTypeListener(List<Type> types, FreeTypeListener ftl) {
> 279:         List<Type> myFreeVars = freeVarsIn(types);
> 280:         if (parentIC == null) {

I'm not sure I get this. In the sense: I get what the code is doing, but I'm not sure I understand why it's needed. E.g. the problem we're trying to solve is when an outer method has some inference variables that have not been propagated. This means that when the outer inference context is solved, calling `asInstTypes` on that outer context won't replace all the types. But your new patch to `asInstTypes` collects (correctly) all the inference variables from all parent contexts -- and uses those to do the type subst. Isn't that enough?

I'm a bit surprised that we also need to be picky when adding listeners -- as I'd assume that once the outer inference context is solved, all the nested inference contexts will also be solved too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25011#discussion_r2097572273


More information about the compiler-dev mailing list