Summary: store and compare primitive type names instead of using BasicType enum.
Udpate unit tests and add a few more cases.
Change-Id: If4e5bb33d11793813839b82cf8beb043aad2ce34
Changed method for how the Visualforce strings are reconstructed from the AST. The previous implementation had incorrect assumptions about the structure of the AST. Added tests to more thoroughly test these situations.
Changed name of IdentifierType to DataType. This information can be stored on either ASTIdentifier or ASTLiteral nodes.
Changes based on PR feedgack:
- Restored ParserOptionsTest in order to avoid binary compatibilty issues.
- Changed ParserOptions to contain a PropertySource instead of extending AbtractPropertySource.
LanguageVersionHandler#getTypeResolutionFacade is deprecated. Moved the VfExpressionTypeVisitor creation and execution to VfParser#parse instead.
ParsingOptionsTest located in pmd-test wasn't running previously because it was in the src/main hierarchy. Moved this test into the src/test hierarchy and consolidated the methods from the
similarly named class from pmd-core.
Store the IdentifierType on ASTIdentifier node instead of in a separate map.
Use the existing TypeResolution pattern to configure the visitor instead deriving from an abstract rule.
Changed ParserOptions to extend AbstractPropertySource with the ability to override the defaults via environment variables.
Allow subclasses of AbstractRuleSetFactoryTest to filter out languages
that show up in the classpath but should not be tested.
Change VFTestContstants to final instead of abstract.
Renamed ExpressionType to IdentifierType since this is more accurate.
Removed usage of google.collect classes that were causing UnsupportedClassVersionError exception in the Travis CI run.
Addresses the general issue raised in https://github.com/pmd/pmd/issues/1092 This commit removes false positives from expressions in apex tags. The specific use case raised in 1092 isn't reproducible and represents a false negative that will be fixed separately.
The existing Visualforce rules don't have any information about the data types referenced in the Visualforce page. This results in false positives when attempting to identify expressions that are vulnerable to XSS attacks. The rules should not warn about XSS attacks when the expression refers to a type such as Integer or Boolean.
The VfExpressionTypeVisitor visits the Visualforce page and extracts the datatypes from Salesforce metadata. Data type information can come from either Apex classes or Object Fields. The Salesforce metadata is generally located in a sibling directory of the Visualforce directory. By default the code looks in directories relative to the Visualforce file to find the metadata. The conventional locations for the metadata are "../classes" and "../objects", the user can override this default with other directories if required.
