[BUG] scanner run fails with => Error (1): Attribute without value => PMD internal error => No adapter exists for type com.google.summit.ast.declaration.VariableDeclarationGroup

[vnehess]

Description:
When the scanner is run on a specific file in my apex source tree, the scanner will fail and exit with the following message
`
Error (1): Attribute without value
Line: 4
Column: 1
Char: >

`

I've traced this down to an invalid XML payload from the PMD engine

The problem appears to be this string returned from PMD:
<pmd xmlns= \"http://pmd.sourceforge.net/report/2.0.0\" xmlns:xsi= \"http://www.w3.org/2001/XMLSchema-instance\" xsi:schemaLocation= \"http://pmd.sourceforge.net/report/2.0.0 http://pmd.sourceforge.net/report_2_0_0.xsd\" version= \"7.0.0\" timestamp= \"2024-04-16T14:14:33.966\" No adapter exists for type com.google.summit.ast.declaration.VariableDeclarationGroup\nNo adapter exists for type com.google.summit.ast.declaration.VariableDeclarationGroup\nNo adapter exists for type com.google.summit.ast.declaration.VariableDeclarationGroup\n>\n<file name= \"/Users/ronhess/Repositories/PLM/src/main/default/classes/AuditTrail.cls\">\n<violation...

Note this is invalid XML because the string 'No adapter exists for type com.google.summit.ast.declaration.VariableDeclarationGroup'.
does not have the form Attribute="value"

Documentation:
Please find attached the XML generated by PmdEngine.js : processStdOut()
Untitled-1.txt

Steps To Reproduce:
I have a specific file that causes this (PMD) to fail when specified as the target.
A full run of all Apex class files works as expected.

Expected Behavior:
The individual file is scanned and issues are reported.

Screenshots:

Desktop:

Additional Context:
The issue does not occur for every file, only a few individual files.
My goal is to run the scanner on files changed in a Pull Request, I would like to specify only a few files on the command line.
If I run the scanner on my entire apex code base, it does work as expected, only when an individual or small group of classes is run does this failure occur.
example :
fails: sf scanner run -f html -o ~/scannerapex.html --target ./src/main/default/classes/AuditTrail.cls --category '!Documentation,!Design'
works sf scanner run -f html -o ~/scannerapex.html --target ./src/main/default/classes/ --category '!Documentation,!Design'

Workaround:

I've tried to limit the rule set reported, but that does not resolve the issue

Urgency:

prevents me from using the v4.0.0 scanner in my CI pipeline

[jag-j]

Thanks for reporting this @vnehess and tracking down the root cause. Though this appears to be an issue on the PMD side, we should be able to handle this gracefully. I'll go ahead and create a bug for us to look into this. Thanks!

[git2gus]

This issue has been linked to a new work item: W-15708421

[stephen-carter-at-sf]

@vnehess would it be possible to narrow it down to the file that is causing the issue and then send us that file so that we can reproduce it. Then on our end, we hopefully will be able to surface this error much better.

[stephen-carter-at-sf]

@gavignon you mentioned that you too might be impacted by this. Do you have a single file that you can share with either us or directly with the PMD folks so that we can reproduce and forward this issue over to them?

[codefriar]

@stephen-carter-at-sf I am also affected by this bug. While I cannot post the offending class causing this issue in a public forum, if you have a way for me to securely get it to you, I can.

[codefriar]

@stephen-carter-at-sf

Actually, I just spent some time and boiled it down. I'm still happy to give you the class, in a secure fashion, but for now, here's an example that fails.

I've redacted symbol names only:

public with sharing class PseudoNamesapce_ClassName {
    @InvocableMethod(Label='Write To Integration Provider' Category='Notes' Callout=true)
    public static List<String> writeNote(List<Parameters> paramsList) {
        List<String> returnStrings = new List<String>();
        List<VCC_Progress_Note__c> pnList = new List<VCC_Progress_Note__c>();
        for (Parameters params : paramsList) {
            switch on params.theObjectWeManipulateInTheInvocable {
                when TypeOne castVarOne {
                    // The contents of the when block don't actaully matter for this bug.
                }
                when TypeTwo CastVarTwo {
                    // The contents of the when block don't actaully matter for this bug.
                }
            }
        }
    }

    /**
    * @description Inner class representing the parameters being passed into to the parent invocable.
    */
    public class Parameters {
        @InvocableVariable
        public CustomMetadata__mdt configurationCustomMetadata;

        @InvocableVariable
        public SObject theObjectWeManipulateInTheInvocable;

        @InvocableVariable
        public PseudoNamespace_ConfigObjectOne paramsOne;

        @InvocableVariable
        public PseudoNamespace_ConfigObjectTwo paramsTwo;
    }
}

However, switching from switch to if/else like this works fine: (only demonstrating the replacement of the switch statement.)

if (params.theObjectWeManipulateInTheInvocable instanceof TypeOne) {
    // Contents of this block don't matter to this bug.
} else if (params.theObjectWeManipulateInTheInvocable instanceof TypeTwo) {
    // Contents of this block don't matter to this bug.
}

My armchair coaching makes me think this is a failure of the parser to generate an XML AST for Switch statements in some conditions. Though, I'm not sure why. Perhaps it's a switch in a for loop or switch referencing an inner class object?

Help us Salesforce! you're our only hope!

[jfeingold35]

@codefriar , thank you for your patience. We've done some investigating and it looks like this is a two-part problem.
Part 1 is that PMD is improperly interleaving its logs into the output in some edge cases. We have logged an Issue with them to get this addressed, and we'll keep tabs on that issue and provide updates here as and when they become available.
Part 2 is that we really shouldn't be using the stdout to get PMD's results in the first place. We'll aim to address this at the earliest opportunity.

[jfeingold35]

@codefriar , I've been informed that PMD has fixed this problem in PMD 7.4, so when we upgrade to that, this issue should go away.