-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[apex] Summit-AST Apex module - Part 1 #4093
Conversation
Operators - Create operator enums to wrap internal Jorje operators. - Create getters returning new operator enums in operator-expression nodes. Deprecate old getters. - Refactor metrics classes to use new operator enums. Tests - Remove references to internal Jorje nodes.
Hi @oowekyala, |
- Remove Jorje dependencies - Add Summit-AST dependency - Comment out code until compilation succeeds
- Replace `ApexNode` type arguments with `Void` - Remove `ApexNode.getNode` - Remove `ASTCommentContainer` type parameter - Deprecate `ASTUserClassOrInterface` type parameter
Remove `node` field from `AbstractApexNode` to remove restriction of wrapping a single node. Create `AbstractApexNode.Single` subclass that wraps a single node. Other subclasses can be created as needed for common cases, or `AbstractApexNode` can be extended directly in irregular cases.
- Add call to `SummitAST` in `ApexParser` - Fix NPE involving `suppressMap` to allow `ApexTreeBuilder` to run - Remove unused `TopLevelVisitor`
Replace `CompilationUnit` with `TypeDeclaration` as the top-level node to match the AST produced by Jorje.
- Replace `ApexTreeBuilder.java` with `ApexTreeBuilder.kt` - Set up tree builder foundation - Build `TypeDeclaration` nodes
- Add `AbstractApexNode.Many`
- Add `buildChildren` function to tree builder
8a4547d
to
2977bd8
Compare
My bad, thanks for clarifying. I just fixed it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this!
I noticed, that the CI build is not enabled for this branch - I'll see, whether I can let gh action execute a build for the branch experimental-apex-parser as well - without publishing the snapshots...
pmd-apex/src/main/java/net/sourceforge/pmd/lang/apex/ApexJorjeLogging.java
Show resolved
Hide resolved
FYI @eklimo @aaronhurst-google I've updated the branch experimental-apex-parser to the latest master. Now we've got a couple of conflicts, probably due to #4081 and maybe #4092 and #4097. |
… part-1 Change-Id: I254208dd5d1b9dbf5335a59a51372ec1d55f8535
Merge conflicts resolved. @adangel With the piecemeal PR strategy, the tests won't pass until completion. How do you want to handle this in the experimental branch, temporarily?
|
Thanks!
Ignoring or disabling tests is always dangerous. If you are confident, that the failing test situation is only temporarily and will be resolved at some point, I think, we can risk it to ignore the failures for now (only in this experimental branch). The PR/branch builds will of course fail. Before the experimental branch can be merged back into master, the tests need to pass, obviously. When the time has come to merge, we know hopefully more about possible compatibility issues (e.g. to answer the question, whether it's really feasible to replace jorje in a minor version). I also think, merging the experimental branch will require another overall big review in the end to check, that there are no leftovers (I see a couple of commented out sections with some TODOs). The overall review will hopefully be quicker because we have seen the code already in the smaller PRs. When should we merge this PR into the experimental branch? Is this Part 1 ready from your side? |
* this information. | ||
*/ | ||
@Deprecated | ||
T getNode(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no longer a 1:1 mapping between PMD and the AST. Either this deprecated API needed to be reword or eliminated... the latter seemed like the clear choice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having access to the underlaying Jorje node made it possible to have the Jorje classes leak into PMDs AST - that's why we deprecated this method. It makes sense to have this removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
*/ | ||
@Deprecated | ||
@InternalApi | ||
public static abstract class Single<T extends Node> extends AbstractApexNode { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a point worth calling out. Since even the (internal) mapping between PMD and the Summit AST isn't 1:1, we use subclass for the different relations between the two. For example, most nodes continue to wrap a Single
AST node, but there are a few that wrap Many
.
@adangel Definitely: a fully-passing testsuite is the only acceptable merge state. A final review pass (from all of us) also sounds essential. The pieces can go in to the experimental branch whenever you're finished giving review feedback. (The next several ones are based on top of this but are otherwise ready to submit.) As @eklimo mentioned, we've already had a few rounds of review before creating these, but want to get your early validation of the overall organization, class structure, etc. I called at out least two points to look at. Also, some complexity arises in |
@Deprecated("internal") | ||
@InternalApi | ||
@Suppress("DEPRECATION") | ||
class ApexTreeBuilder(val sourceCode: String, val parserOptions: ApexParserOptions) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm concerned that your converting existing classes to kotlin will make the merge conflicts with pmd 7 much harder to handle. The java version of this class has been changed in pmd 7 and will conflict. I think it's fine to use kotlin for new classes but I see no solid reason to convert existing classes to kotlin when they already work - at least while we have three parallel development branches.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This class serves the same functional purpose but is essentially a wholesale rewrite. (The input is obviously different, but the general structure changed to handle the many:many relation between the two ASTs.)
Any concerns about specific common pieces that we might want to factor out and share? I can rework to preserve those in ApexTreeBuilder and move the Summit-specific bits to a new class.
@@ -4,6 +4,7 @@ | |||
|
|||
package net.sourceforge.pmd.lang.apex.ast; | |||
|
|||
import com.google.summit.ast.CompilationUnit; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: That's probably an unused import (like in the other test classes).
I'm going to merge this now into As this is for sure not the last change - we still have the ability to tackle the mentioned issues (e.g. ApexTreeParser and compatibility with PMD 7). I'd defer these issues until later. |
Thanks. I've created a doc "PMD Apex Front-end Tracker" to capture and track some of the tasks that span beyond a specific CL but need to be addressed before completion. I've shared with @adangel and @oowekyala and will keep it up-to-date (but feel free to comment / edit). |
Describe the PR
First part of Summit-AST-based Apex module.
Changes
ApexTreeBuilder
Upcoming changes
Related issues