FunctionSignatureParser does not handle calling convention

[DrFrugalOfficial]

Describe the bug
The class FunctionSignatureParser is used for parsing a C-style function signature string into it's FunctionSignature representation via the parse method.
For the easy signatures without explicit calling convention this works well, as far as I tested it, but as soon as a calling convention is passed, the script errors.
The root cause is most likely the handling in extractReturnType not expecting calling conventions in the String, and parse not handling them at all.

To Reproduce
Run the following Java GhidraScript:

FunctionSignatureParser fsp = new FunctionSignatureParser(currentProgram.getDataTypeManager(), null);
FunctionSignature fs = fsp.parse(null, "void* __cdecl test(void * arg0)");
println("sig: " + fs.toString());

You should see an error pop up like this:

Can't resolve return type: void* __cdecl
ghidra.app.util.cparser.C.ParseException: Can't resolve return type: void* __cdecl
	at ghidra.app.util.parser.FunctionSignatureParser.extractReturnType(FunctionSignatureParser.java:267)
	at ghidra.app.util.parser.FunctionSignatureParser.parse(FunctionSignatureParser.java:114)
	at DrFrugal.run(DrFrugal.java:39)
	at ghidra.app.script.GhidraScript.executeNormal(GhidraScript.java:460)
	at ghidra.app.script.GhidraScript.doExecute(GhidraScript.java:314)
	at ghidra.app.script.GhidraScript.execute(GhidraScript.java:290)
	at ghidra.app.plugin.core.script.RunScriptTask.run(RunScriptTask.java:46)
	at ghidra.util.task.Task.monitoredRun(Task.java:134)
	at ghidra.util.task.TaskRunner.lambda$startTaskThread$0(TaskRunner.java:106)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1583)

---------------------------------------------------
Build Date: 2025-Dec-05 1355 EST
Ghidra Version: 12.0
Java Home: C:\Program Files\Amazon Corretto\jdk21.0.5_11
JVM Version: Amazon.com Inc. 21.0.5
OS: Windows 11 10.0 amd64
Workstation: KARAZHAN

Expected behavior
The parse function can handle the available calling conventions (the string for unknown / default would be good to be handled too).
In case of the calling convention not being present in the string, it should use the default as it is already doing.

Screenshots
not needed

Attachments
not needed

Environment (please complete the following information):

• OS: Windows 11 25H2 26200.7462
• Java Version: 21.0.5_11
• Ghidra Version: 12.0
• Ghidra Origin: official GitHub distro

Additional context
Add any other context about the problem here.

[astrelsky]

I barely handles anything.

[ryanmkurtz]

I barely handles anything.

I think you forgot a crucial letter somewhere in there 🤣

[astrelsky]

I barely handles anything.

I think you forgot a crucial letter somewhere in there 🤣

I think you're right. It's still an accurate statement though.

[DrFrugalOfficial]

I have looked at this during the past days, and of course I found more things that would be good to handle.
You can call the setNoReturn(true) method on the Function object, in order to mark it as non-returning.
When the signature of this function is then serialized, it looks a bit weird.

Here is a snippet of what I executed:

Address address = toAddr("00400399"); // best to choose an offset where there is nothing at yet
Function function = getFunctionAt(address);
if(function != null) {
	removeFunction(function); // delete if already exists
}
function = createFunction(currentAddress, "DEBUG_FUNCTION"); // (re)create function
function.setCallingConvention("__fastcall");
function.setNoReturn(true);
String signatureString = function.getSignature().toString();
println("signatureString: " + signatureString);

FunctionSignatureParser fsp = new FunctionSignatureParser(currentProgram.getDataTypeManager(), null);
FunctionDefinitionDataType fddt = fsp.parse(null, signatureString);
println("fddt: " + fddt.toString());

The output is: noreturn undefined __fastcall DEBUG_FUNCTION(void) and an error, because it can not parse correctly.

This generates __fastcall for the calling convention, which it can not parse again, but which i would grade as fair enough, and noreturn at the very start, which I feel is a bit weird for valid C/C++ grammer or compiler specific syntax (I would expact __noreturn for example).

I am fully aware that this whole topic is pretty complex, if you wanna do it properly.
Probably it would be helpful to break this task of improving the usability of FunctionSignatureParser into multiple parts, with increasing complexity.
In my eyes a good metric for determining that it works ok is, that any function signature that Ghidra produces via function.getSignature().toString() is parsable by Ghidra's own FunctionSignatureParser.

Is there any conclusive/targeted C or compiler specific syntax which was decided on?
__fastcall was introduced by MSVC from what I know, and some other compilers introduced macros in order to rewrite those in their own preferred syntax, in order to be able to parse it.
Does that happen because Ghidra knows that the binary was compiled with MSVC?