RFR: 8339296: Record deconstruction pattern in switch fails to compile
Vicente Romero
vromero at openjdk.org
Mon Sep 30 17:17:36 UTC 2024
On Mon, 30 Sep 2024 17:05:43 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:
> > > The approach seems good. I left some modelling questions. As you notice, I'm skeptical that just handling unknown types better is going to be the last time we see issues like this. E.g. the switch code in `Attr` seems to be doing way too much when we're in speculative mode.
> >
> >
> > I agree with Maurizio that we are probably doing too much in speculative mode in the switch. I wonder if this patch should be part of the code that will refactor what we are doing there. I would expect any refactoring of what it is done in the switch code to affect this current PR
>
> That depends on what the merit of this PR is. There's a type that is inherently unsafe in javac (`Symtab.unknownType`) and leads to problems like `StackOverflowError` when sent to various methods on `Types`. This PR considers the specific problem with pattern matching switch just as a symptom of the problem with the type, and fixes the problem with the type. The intent in this PR is that any change to what is done during speculative attribution of pattern matching switches shouldn't affect it much.
>
> Note that even though we don't know about any usecase right now where the problem would happen outside of speculative attribution, as long as `Attr.PostAttrAnalyzer` will set the `unknownType` to AST nodes, there's always a potential it will break unless the `unknownType` is fixed.
yep that makes sense to me we can revisit this issue later on if needed
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20990#issuecomment-2383748651
More information about the compiler-dev
mailing list