JDK-8244229 : [lworld] Need more robust handling of .ref and .val reference in source code
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: repo-valhalla
  • Priority: P4
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2020-05-01
  • Updated: 2024-03-26
  • Resolved: 2024-03-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
repo-valhallaResolved
Related Reports
Blocks :  
JDK-8252205 - [lworld] JLS 6.5 "Determining the Meaning of a Name" needs updates for handling .ref and .val tokens
Relates :  
JDK-8245310 - Sealed Classes: Clarify treatment of `non-sealed` as a keyword
Relates :  
JDK-8237072 - [lworld] Add support for denoting and deriving the reference projection
Relates :  
JDK-8264977 - [lworld] A primitive class field by name val confuses javac
Description
JDK-8237072 implements a quick and dirty scheme to handle .ref and .val as tokens in source code. We need a more robust treatment of these that is in alignment with meaning of names as spelled out in JLS chapter 6 (with any suitable spec tweaks called for)
Comments
not valid any more
26-03-2024
See JDK-8245310 for related questions about contextual keywords used by sealed classes. A draft of spec changes for a more unified treatment of contextual keywords is here: http://cr.openjdk.java.net/~dlsmith/8245310/8245310-20200522/specs/contextual-keywords-jls.html On top of that change, here I think we'd want to: - Enhance Type and related productions to include ClassName.ref and ClassName.val. - Add 'ref' and 'val' to the list of ContextualKeywords (treated as keywords when they are used in a Type production) - Add 'ref' and 'val' to the list of TypeIdentifier exclusions. (You can't declare or reference a class/interface/type var named 'ref' or 'val'.) - For disambiguation, prohibit qualified names from using 'ref' or 'val' as identifiers at all. The last one might be too strong—these are reasonable field names, for example—but it would be really nice if we didn't have to do ambiguous name resolution before deciding whether 'ref' is an Identifier or a Keyword. It's a safe baseline, anyway. However those details are sorted out, I think it would be the wrong approach to pretend 'ref' and 'val' are valid pieces of a TypeName—Foo.ref is *not* a class name, and should not be treated as one in the grammar. (Let's also keep in mind that these particular choices of names are subject to change.)
24-08-2020
Issue reported by Maurizio: Given: inline class V { int y = 52; static class ref { int x; } void m(V.ref vref) { vref.x = 12; } } Which gives: error: cannot find symbol vref.x = 12; ^ symbol: variable x location: variable vref of type V$ref In other words, the compiler is always resolving .ref to a projection - which is fine for now, but there's a deeper question as to whether we're ok with this behavior and if we want to even allow defining a nested class called ref or val inside an inline class.
01-05-2020
Issues reported by Maurizio: package a; import a.V.ref; inline class V { int x = 0; } // results in: error: import requires canonical name for V$ref import a.V.ref;
01-05-2020