Skip to content

[core] Language lifecycle#4060

Merged
adangel merged 61 commits into
pmd:pmd/7.0.xfrom
oowekyala:pmd7-language-lifecycle
Feb 10, 2023
Merged

[core] Language lifecycle#4060
adangel merged 61 commits into
pmd:pmd/7.0.xfrom
oowekyala:pmd7-language-lifecycle

Conversation

@oowekyala

@oowekyala oowekyala commented Jul 22, 2022

Copy link
Copy Markdown
Member

Describe the PR

(This contains #4049)

I'm opening this a bit early because I think it's a crucial step forward for the PMD 7 branch and I want to give it visibility. I will spend some more time adding tests and documentation, and improving the PR description.

This introduces the following binary incompatibilities:

  • LanguageVersion::getLanguageVersionHandler is removed
  • BaseLanguageModule is removed

Related issues

Ready?

  • Added unit tests for fixed bug/feature
    • Missing unit tests for new language
  • Passing all unit tests
  • Complete build ./mvnw clean verify passes (checked automatically by github actions)
  • Added (in-code) documentation (if needed)
    • doc: Finish language_properties.md
    • doc: Update adding_a_new_javacc_based_language.md and adding_a_new_antlr_based_language.md
    • doc: Update release notes

@oowekyala oowekyala added this to the 7.0.0 milestone Jul 22, 2022
@oowekyala oowekyala marked this pull request as ready for review February 1, 2023 23:15

@adangel adangel left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks for the amazing work! 🎉

I've updated the task list on the PR description and added some doc tasks - I'll work on them and update this PR.
Could you have a look at the task "Missing unit tests for new language" whether this is done or still needed? I'm not sure what you mean by that.

Other than that, I don't think my other comments need to be addressed immediately (especially extracting LanguageHandler into own classes, which could create another bunch of changes, that are better done separately).

Comment thread docs/pages/pmd/languages/language_properties.md Outdated
Comment thread docs/pages/pmd/languages/language_properties.md
Comment thread docs/pages/pmd/languages/language_properties.md Outdated

// TODO replace those with actual language properties when the
// CLI syntax is implemented.
props.setProperty(LanguagePropertyBundle.SUPPRESS_MARKER, config.getSuppressMarker());

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Maybe that's worth to document: with the cli option for suppress marker, you configure it for all languages. With the env var for the property, you configure it for a specific language.

If both a present, one should take precedence. I think, the more specific one should override the general one - that means, if both CLI option for suppressmarker is given and the env for the language property, the env should be used.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Ok, it seems the implementation is the other way around as I expected. Then it's all the more important to have the behavior documented to avoid surprises.

--suppress-marker overrides any configuration, that is provided by env vars.

Comment thread pmd-apex/src/main/java/net/sourceforge/pmd/lang/apex/ApexLanguageProcessor.java Outdated
*/

package net.sourceforge.pmd.lang.apex.internal;
package net.sourceforge.pmd.lang.apex;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Maybe ApexLanguageProcessor should stay internal - at least, JavaLanguageProcessor is internal as well...

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Actually the language processors should probably be published at some point. I would like rules to be able to use them to initialize themselves exactly once, for instance, parse their property values into JClassTypes using the TypeSystem.

@adangel adangel added the an:enhancement An improvement on existing features / rules label Feb 2, 2023
Comment thread docs/pages/7_0_0_release_notes.md

@oowekyala oowekyala left a comment

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Thanks for the review Andreas!

the task "Missing unit tests for new language" is about adding unit tests for the new language base classes. I'll finish this on the weekend

Comment thread pmd-core/src/main/java/net/sourceforge/pmd/lang/ast/AstInfo.java Outdated
Comment thread docs/pages/pmd/languages/language_properties.md

@adangel adangel left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks! I'll merge this next 🎉

@adangel adangel merged commit eee8b95 into pmd:pmd/7.0.x Feb 10, 2023
This was referenced Feb 10, 2023
@oowekyala oowekyala deleted the pmd7-language-lifecycle branch May 13, 2024 21:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

an:enhancement An improvement on existing features / rules

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[core] Language properties

2 participants