Closed jurgenvinju closed 1 month ago
I think this is ready for review, but I should want that the number of changes is quite enormous.
implicitDeclarations
to the M3 model, and including lambda's in a way in the M3 model such that a complete call graph construction algorithm is possible with only M3 as source data. However, that would add more noise to the current PR so I'm pushing that to the future. Am still working to run the astNodeSpecification
checker over all the ASTs. Errors keep popping up. Those are going to be minor changes of list.insert
to list.append
and such.
Ok all the Java ASTs now pass all of the AST specification. The M3 specification (made based on the C++ support) is not robust enough yet to be able to be used as a quality gate.
Attention: Patch coverage is 56.46186%
with 411 lines
in your changes are missing coverage. Please review.
Project coverage is 49%. Comparing base (
6bb94a2
) to head (efa6401
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Thanks @DavyLandman As soon as the tests run on the server, I'll merge.
Aha! The type-checker is now forcing us to update JavaToObjectFlow :-) good catch.
This branch starts from the main branch where Java support for M3 and ASTs was done up to level 8 of the Java Language Standard (JLS8).
However several key concepts were missing from the syntax trees namely type parameters and modifiers and annotations here and there. Some of these concepts were represented only in the M3 database, and at the time it was decided that double representation was not good for memory consumption. Today and with experience from the C++/C M3 models, PHP and Ada, this design decision has shifted: every AST must be fully informative, and the AST model must be aligned with the M3 model by sharing
src
(physical location),decl
(logical location) andtyp
resolved static types keyword parameters on representative AST nodes. The full specification of a correct AST nodes is a boolean predicate in lang::analysis::M3..length
field accesses tojava+arrayLength:///TypeName[]
to fix a number of inconsistencies around these hidden fields.