Skip to content
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

[java] Add permitted subtypes to symbol API #5352

Merged
merged 9 commits into from
Nov 22, 2024

Conversation

oowekyala
Copy link
Member

Describe the PR

Follow up on #5246. Add permitted subclasses to the symbol API and ensure that the AST and ASM implementations match.

Related issues

Ready?

  • Added unit tests for fixed bug/feature
  • Passing all unit tests
  • Complete build ./mvnw clean verify passes (checked automatically by github actions)
  • Added (in-code) documentation (if needed)

@pmd-test
Copy link

1 Message
📖 Compared to main:
This changeset changes 0 violations,
introduces 0 new violations, 0 new errors and 0 new configuration errors,
removes 0 violations, 0 errors and 0 configuration errors.
Download full report as build artifact

Generated by 🚫 Danger

Comment on lines +165 to +170
/**
* In order to test simultaneously types defined in the same compilation unit,
* we must store them somewhere. The fixture stores the parsed AST and allows
* convenient access to the parsed types. This makes sure that we don't parse
* the file once per lookup.
*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this only works if you keep the Fixture instance around… which is never the case for SymImplementation.getSymbol / SymImplementation.getDeclaration

maybe we shouldn't bother with this at this stage, and eventually consider having JavaParsingHelper.DEFAULT.parseClass implement an LRU-cache directly instead?

Copy link
Member Author

@oowekyala oowekyala Nov 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes but the tests that use those methods test a single type anyway, so it doesn't matter for them. It's useful in the new tests I added though, because several types are defined in the same source file, and we want to test the connections between those symbols.

To clarify, it's there for correctness, not as an optimization. So I think we shouldn't make the caching implicit in javaparsinghelper

@jsotuyod jsotuyod added in:type-resolution Affects the type resolution code in:symbol-table Affects the symbol table code labels Nov 22, 2024
@jsotuyod jsotuyod added this to the 7.8.0 milestone Nov 22, 2024
@jsotuyod jsotuyod removed the in:type-resolution Affects the type resolution code label Nov 22, 2024
@jsotuyod jsotuyod merged commit 187f41d into pmd:main Nov 22, 2024
3 checks passed
@oowekyala oowekyala deleted the issue4813-switch-exhaustive-patmat branch November 22, 2024 17:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in:symbol-table Affects the symbol table code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants