This is split off as a sub-task of JDK-8224228, which seeks to add @SuppressWarnings support for lexical features.
In order for @SuppressWarnings to work for source code bits that are handled by the parser (for example, new lexical features subject to preview warnings), these bits need to be located within the innermost enclosing @SuppressWarnings-supporting declaration, i.e., module, package, class, method, or variable declaration. Since these are lexical bits, not Java members or symbols with "owners", etc., this requires we know the starting and ending positions of such enclosing declarations.
The parser does not normally store lexical end positions in an EndPositionTable unless this is requested explicitly. So we can't rely on that, and we don't want to make the EndPositionTable mandatory for performance reasons.
Instead, we can just add a new "int endPos" field to the five corresponding AST node classes: JCModuleDecl, JCPackageDecl, JCClassDecl, JCMethodDecl, and JCVariableDecl. This field can be populated as part of the normal parsing of these node types, which already supports the (optional) tracking of end positions.
In order for @SuppressWarnings to work for source code bits that are handled by the parser (for example, new lexical features subject to preview warnings), these bits need to be located within the innermost enclosing @SuppressWarnings-supporting declaration, i.e., module, package, class, method, or variable declaration. Since these are lexical bits, not Java members or symbols with "owners", etc., this requires we know the starting and ending positions of such enclosing declarations.
The parser does not normally store lexical end positions in an EndPositionTable unless this is requested explicitly. So we can't rely on that, and we don't want to make the EndPositionTable mandatory for performance reasons.
Instead, we can just add a new "int endPos" field to the five corresponding AST node classes: JCModuleDecl, JCPackageDecl, JCClassDecl, JCMethodDecl, and JCVariableDecl. This field can be populated as part of the normal parsing of these node types, which already supports the (optional) tracking of end positions.
- links to
-
Review(master) openjdk/jdk/23669