Skip to main content
Jump to: navigation, search

Difference between revisions of "JDT Core Programmer Guide/ECJ/AST"

(Created page with "AST and bindings are the two main data structures of the compiler. AST nodes directly capture all semantically relevant aspects of...")
 
Line 3: Line 3:
 
AST nodes directly capture all semantically relevant aspects of the source code. In many regards the type hierarchy below <code>org.eclipse.jdt.internal.compiler.ast.ASTNode</code> corresponds to the standard approach in compiler construction.
 
AST nodes directly capture all semantically relevant aspects of the source code. In many regards the type hierarchy below <code>org.eclipse.jdt.internal.compiler.ast.ASTNode</code> corresponds to the standard approach in compiler construction.
  
===Traversing the tree===
+
==Traversing the tree==
 
* Three main compiler phases are implemented with explicit traversals below these methods of class CompilationUnitDeclaration:
 
* Three main compiler phases are implemented with explicit traversals below these methods of class CompilationUnitDeclaration:
 
** resolve()
 
** resolve()
Line 12: Line 12:
 
** method ASTNode.traverse(ASTVisitor, BlockScope), plus variants for other scope types
 
** method ASTNode.traverse(ASTVisitor, BlockScope), plus variants for other scope types
  
===Special encodings===
+
==Special encodings==
 
Throughout all AST classes, '''source positions''' are recorded as linear text indices.
 
Throughout all AST classes, '''source positions''' are recorded as linear text indices.
 
* Fields sourceStart and sourceEnd typically hold the start and end of that region that should be highlighted if an error(/warning/info) has been detected concerning a given AST node.
 
* Fields sourceStart and sourceEnd typically hold the start and end of that region that should be highlighted if an error(/warning/info) has been detected concerning a given AST node.
Line 31: Line 31:
 
Similar bitsets are <code>TypeBinding.tagBits</code> and <code>ReferenceBinding.typeBits</code>, see [[JDT Core Programmer Guide/ECJ/Bindings|Bindings]].
 
Similar bitsets are <code>TypeBinding.tagBits</code> and <code>ReferenceBinding.typeBits</code>, see [[JDT Core Programmer Guide/ECJ/Bindings|Bindings]].
  
 +
==Additional types in package ast==
  
The special node class <code>FakedTrackingVariable</code> does '''not''' correspond to any source element, but is used to map resource leak analysis to the existing infrastructure of null analysis. See [[JDT Core Programmer Guide/ECJ/Analyse|Analyse]].
+
===Additional classification===
 
+
 
+
 
The AST structure very sparingly uses '''interfaces''' for additional classification:
 
The AST structure very sparingly uses '''interfaces''' for additional classification:
 
* IJavadocTypeReference: subsumes JavaSingleTypeReference and JavaQualifiedTypeReference
 
* IJavadocTypeReference: subsumes JavaSingleTypeReference and JavaQualifiedTypeReference
Line 40: Line 39:
 
* Invocation: subsumes AllocationExpression, ExplicitConstructorCall and MessageSend (used during type inference)
 
* Invocation: subsumes AllocationExpression, ExplicitConstructorCall and MessageSend (used during type inference)
 
* IPolyExpression: expressions that can be poly expressions according to [https://docs.oracle.com/javase/specs/jls/se14/html/jls-15.html#jls-15.2 JLS §15.2].
 
* IPolyExpression: expressions that can be poly expressions according to [https://docs.oracle.com/javase/specs/jls/se14/html/jls-15.html#jls-15.2 JLS §15.2].
 +
 +
===Synthetic ast node===
 +
The special node class <code>FakedTrackingVariable</code> does '''not''' correspond to any source element, but is used to map resource leak analysis to the existing infrastructure of null analysis. See [[JDT Core Programmer Guide/ECJ/Analyse|Analyse]].
 +
 +
 +
===Algorithm implementations===
 +
 +
Class '''NullAnnotationMatching''' provides static methods for 'type-checking' null annotations. Some of these methods use instances of NullAnnotationMatching to communicate the exact result of the analysis.
 +
 +
 +
Class '''UnlikelyArgumentCheck''' provides static methods for advanced 'type-checking' of arguments of well-known methods like <code>contains</code> and <code>remove</code> of interface <code>Collection&lt;T&gt;</code>, see {{Bug|410218}}. Both check methods return an instance of UnlikelyArgumentCheck to communicate the exact result of the analysis.
  
 
[[Category:JDT]]
 
[[Category:JDT]]

Revision as of 15:37, 2 July 2020

AST and bindings are the two main data structures of the compiler.

AST nodes directly capture all semantically relevant aspects of the source code. In many regards the type hierarchy below org.eclipse.jdt.internal.compiler.ast.ASTNode corresponds to the standard approach in compiler construction.

Traversing the tree

  • Three main compiler phases are implemented with explicit traversals below these methods of class CompilationUnitDeclaration:
    • resolve()
    • analyseCode()
    • generateCode()
  • For various smaller tasks the visitor pattern is used, see
    • class org.eclipse.jdt.internal.compiler.ASTVisitor
    • method ASTNode.traverse(ASTVisitor, BlockScope), plus variants for other scope types

Special encodings

Throughout all AST classes, source positions are recorded as linear text indices.

  • Fields sourceStart and sourceEnd typically hold the start and end of that region that should be highlighted if an error(/warning/info) has been detected concerning a given AST node.
  • Complex nodes have more locations, like bodyStart, bodyEnd etc.
  • In some cases, a pair of start & end position is encoded in a single long variable. This is used specifically where a list of positions is needed, like QualifiedTypeReference.sourcePositions (encoding the position of each text segment).
    • To create the long value, use (((long) start) << 32) + end
    • To extract the start position use (int) (position>>>32)
    • To extract the end position use (int) position


The field ASTNode.bits is used as a bitset. Unfortunately the use of bits in this vector is quite crowded, some bits are used with different semantics in different kinds of nodes. See class ASTNode for constants and their terse documentation.

  • Some flags are set right during parsing, like IsDiamond
  • Other flags store information gathered throughout compilation.
  • Bits in ParenthesizedMASK encode the number of enclosing pairs of parentheses, so that no AST node ParenthesizedExpression is needed.
  • Flags HasAllMethodBodies, HasBeenResolved and HasBeenGenerated remember whether a given compilation step has already been performed for this node.


Similar bitsets are TypeBinding.tagBits and ReferenceBinding.typeBits, see Bindings.

Additional types in package ast

Additional classification

The AST structure very sparingly uses interfaces for additional classification:

  • IJavadocTypeReference: subsumes JavaSingleTypeReference and JavaQualifiedTypeReference
  • InvocationSite: holds some context for resolving a reference to a member
  • Invocation: subsumes AllocationExpression, ExplicitConstructorCall and MessageSend (used during type inference)
  • IPolyExpression: expressions that can be poly expressions according to JLS §15.2.

Synthetic ast node

The special node class FakedTrackingVariable does not correspond to any source element, but is used to map resource leak analysis to the existing infrastructure of null analysis. See Analyse.


Algorithm implementations

Class NullAnnotationMatching provides static methods for 'type-checking' null annotations. Some of these methods use instances of NullAnnotationMatching to communicate the exact result of the analysis.


Class UnlikelyArgumentCheck provides static methods for advanced 'type-checking' of arguments of well-known methods like contains and remove of interface Collection<T>, see bug 410218. Both check methods return an instance of UnlikelyArgumentCheck to communicate the exact result of the analysis.

Back to the top