Inherited Class constructor parsing error

[xixiaofinland]

It works in PA but errors in sfapex.

public class A {
  public class B {
    public A.B() {
    }
  }
}

[aheber]

I don't see this working on platform.

If I try and save a class such as

public class TestClass {
    public class TestClassAgain {
        public TestClass.TestClassAgain(){
            
        }
    }
}

It fails to save with an error of Invalid constructor name: TestClass.TestClassAgain

Could you point me to a class example that looks like your example but saves into Salesforce? Maybe I'm not understanding correctly.

[xixiaofinland]

Interesting. Originally many errors were reported from apex-rollup, and one of them was this file content below. I quickly narrowed down the issue, removed apex-rollup repo locally, and reported it here.

Now I cloned the repo back locally, but the error is no more. It seems maybe those files were located in .sfdx and they were not valid Apex? I'm not sure under what circulations those files were generated at the time.

[xixiaofinland]

Found this one locally from NPSP, but I think the files in .sfdx were generated on the fly when/after I cloned the repo. It wasn't in the github repo.

NPSP/.sfdx/tools/252/StandardApexLibrary/System/QueueableDuplicateSignature.cls

global class QueueableDuplicateSignature {
	global static System.QueueableDuplicateSignature.Builder builder() { }
	global Object clone() { }
	global String toString() { }
global class Builder {
	global QueueableDuplicateSignature.Builder() { }
	global System.QueueableDuplicateSignature.Builder addId(Id id) { }
	global System.QueueableDuplicateSignature.Builder addInteger(Integer i) { }
	global System.QueueableDuplicateSignature.Builder addString(String s) { }
	global System.QueueableDuplicateSignature build() { }
	global Object clone() { }
	global Integer getMaxSize() { }
	global Integer getRemainingSize() { }
	global Integer getSize() { }

}

}

[aheber]

I have seen that pattern in the files provided by the Apex langauge server before and discussed them with the team that owns it. I don't know that they are going to get fixed anytime soon.

Those files are automatically generated from the internal files at Salesforce for the platform APIs. They are not real code but just enough representation to help with auto-complete and such in the IDE.

So do we expand this... it would make some errors go away but allow invalid structures. We can blame Salesforce and if they ever fix their files we could remove parsing support.

It doesn't hurt this parser to allow it aside from knowing that the parsed file couldn't execute, which is something we have in many places right now.

Thoughts? If this is to serve a practical purpose maybe it needs to parse those file even if they are actually invalid?

[xixiaofinland]

@aheber no, as org doesn't allow them to be pushed, I don't think we should support it.

It appears only in my battle test script log. I can easily exclude this false positive error to be logged.

[aheber]

I'll go with that for now. I'm going to leave this open because I think the long run either Salesforce should correct those files or this parser should learn to parse them. This will help me to remember to follow up with that team and push a consensus.