Parser options for now are just implemented for decoration. There's no API for PMD to configure them, and they can only be used if you use the parser directly.

• It will likely be never supported to have a rule choose special parser options. This is because, if several rules need different sets of options, we'd have to parse files several time.
• There would also be several ways to parse trees, meaning it's harder to get a hand on the API and start writing rules.
• Nontrivial ParserOptions are implemented in the following modules only:
  • Ecmascript:
    

    pmd/pmd-javascript/src/main/java/net/sourceforge/pmd/lang/ecmascript/EcmascriptParserOptions.java

    Lines 60 to 68 in 11c2b20

    	public static final BooleanProperty RECORDING_COMMENTS_DESCRIPTOR = new BooleanProperty("recordingComments",
    	"Specifies that comments are produced in the AST.", Boolean.TRUE, 3.0f);
    	public static final BooleanProperty RECORDING_LOCAL_JSDOC_COMMENTS_DESCRIPTOR = new BooleanProperty(
    	"recordingLocalJsDocComments", "Specifies that JsDoc comments are produced in the AST.", Boolean.TRUE,
    	4.0f);
    	public static final EnumeratedProperty<Version> RHINO_LANGUAGE_VERSION = new EnumeratedProperty<>(
    	"rhinoLanguageVersion",
    	"Specifies the Rhino Language Version to use for parsing. Defaults to Rhino default.", VERSION_LABELS,
    	Version.values(), 0, Version.class, 5.0f);

    • The rhino version should be translated to a LanguageVersion, not a ParserOption
    • Preserving comments is done by default and we could just remove those options
  • [javascript] Remove JS parser options #2837
  • XML:
    

    pmd/pmd-xml/src/main/java/net/sourceforge/pmd/lang/xml/XmlParserOptions.java

    Lines 23 to 43 in 11c2b20

    	public static final BooleanProperty COALESCING_DESCRIPTOR = new BooleanProperty("coalescing",
    	"Specifies that the XML parser convert CDATA nodes to Text nodes and append it to the adjacent (if any) text node.",
    	Boolean.FALSE, 3.0f);
    	public static final BooleanProperty EXPAND_ENTITY_REFERENCES_DESCRIPTOR = new BooleanProperty(
    	"expandEntityReferences", "Specifies that the XML parser expand entity reference nodes.", Boolean.TRUE,
    	4.0f);
    	public static final BooleanProperty IGNORING_COMMENTS_DESCRIPTOR = new BooleanProperty("ignoringComments",
    	"Specifies that the XML parser ignore comments.", Boolean.FALSE, 5.0f);
    	public static final BooleanProperty IGNORING_ELEMENT_CONTENT_WHITESPACE_DESCRIPTOR = new BooleanProperty(
    	"ignoringElementContentWhitespace",
    	"Specifies that the XML parser eliminate whitespace in element content. Setting this to 'true' will force validating.",
    	Boolean.FALSE, 6.0f);
    	public static final BooleanProperty NAMESPACE_AWARE_DESCRIPTOR = new BooleanProperty("namespaceAware",
    	"Specifies that the XML parser will provide support for XML namespaces.", Boolean.TRUE, 7.0f);
    	public static final BooleanProperty VALIDATING_DESCRIPTOR = new BooleanProperty("validating",
    	"Specifies that the XML parser will validate documents as they are parsed. This only works for DTDs.",
    	Boolean.FALSE, 8.0f);
    	public static final BooleanProperty XINCLUDE_AWARE_DESCRIPTOR = new BooleanProperty("xincludeAware",
    	"Specifies that the XML parser will process XInclude markup.", Boolean.FALSE, 9.0f);
    	public static final BooleanProperty LOOKUP_DESCRIPTOR_DTD = new BooleanProperty("xincludeAware",
    	"Specifies whether XML parser will attempt to lookup the DTD.", Boolean.FALSE, 10.0f);

    • The ASTs PMD produces should be "low-level" enough that code style issues can be detected. Coalescing CDATA nodes, or expanding entity references, defeats this purpose.
    • PMD should probably not be attempting to validate schemas in the parser. If anything schema validation should maybe be a rule.
    • Namespace awareness is kind of like symbol resolution in other languages and should be kept enabled by default
  • [xml] Remove xml dom rule and parser options #2971 [xml] Remove XML parser options

I think parser options can go away completely, and language properties (#2518) may be used to replace its only functionality (the comment marker). This would also allow suppress markers to be set per-language, as a happy consequence.

On master we need to

• Deprecate ParserOptions and its language-specific subclasses (Apex, Ecmascript, XML)
• Deprecate Rule::getParserOptions
  Both done with [core] Deprecate parser options #2675

It's still ok to use ParserOptions on master (though not the language-specific subclasses), because LanguageVersionHandler::getParser takes a ParserOptions parameter for the suppress marker. In 7.0 we should however introduce an overload that takes no parameter.