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

Vicente Romero vromero at openjdk.org
Thu May 15 17:31:02 UTC 2025


On Thu, 15 May 2025 16:37:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I think I see the problem now. I believe the issue is in `Check::checkMethod`. That method does this at the start:
> 
> ```
> if (inferenceContext.free(mtype)) {
>             inferenceContext.addFreeTypeListener(List.of(mtype),
>                     solvedContext -> checkMethod(solvedContext.asInstType(mtype), sym, env, argtrees, argtypes, useVarargs, solvedContext));
>             return mtype;
>         }
> ```
> 
> This is correct -- if `mtype` has some free type variable, we need to come back later and re-run this again (to set the correct type on the AST).
> 
> But there's an issue -- if we propagate (`Infer::shouldPropagate` is `true`), then the input inference context is NOT the inference context for the call being checked (in this case `supplyNull`) but the outer context, which contains the propagated vars.
> 
> While this was correct before the introduction of context minimization -- because in such case outer inference contexts were always strict supersets of nested inference contexts "contained", this is no longer true with minimization: we can have an outer context that omits some variables from the nested context. At which point, the listener above will "miss the memo" -- e.g. it will instantiate the method type using the outer context inferred vars -- but this will still leave "holes" (because the outer context will not contain all the variables that can appear in `mtype`).

correct, these were my findings too, and if we try to make the minimized context more `chubby` then for a lot of cases we will probably kill the whole point of doing the minimization at all. So the supplementary context was the solution I found to keep the whole minimization algo going while doing some bookkeeping in case it could be needed by an outer inference context

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

PR Comment: https://git.openjdk.org/jdk/pull/25011#issuecomment-2884566605


More information about the compiler-dev mailing list