-- Applied changeset
Cool.
-- BigDecimal
yeah probably .. eventually
-- main args and callExpr
If the args are inserted as synthesized AST Nodes ( like the rest of the setup in
IdentifyMainPhase.createMainWrapper) and as per your example then every backend will generate the code conversion implicitly whether its appropriate or not re arg types and namings or alternatively the backend has to recognise a main method ( user or wrapped) and do the right thing to it in spite of what the user or wrapper may have specified.
Setting explicit attribute flags generally allows the backends to then ignore (C#) or handle specially ( java) as desired/needed for the backend.
The flag on CallExpr is because the wrapper invocation of the user supplied entry point is a callExpr and needs to use the same named Identifier as the args to the wrapped main method passed to the user version. Thats the point of .hasMainParams in Method and .hasMainArgs in CallExpr
( This is then explicit and coupled in the backend though perhaps not very obvious).
(Its a specific issue for Java cos it has a particular requirement for a specific form of a method to be recognised as a main method ).
Admittedly the main method cases aren't too different between C# and Java but they can/will be for other back ends ( e.g main method args for C/C++ or whatever ObjC does for main methods).
This is another reason for having '
cue main' explicitly up front in Cobra language since its then specially marked the backends can just handle it.
main methods
are special.
More long term wrt the existing code this entire code+approach is wrong ( identifying a main candidate, synthesizing a blob of Cobra AST Nodes for a wrapper if the candidate differs from the desired form in one aspect specific to one platform).
The flagging I added for Java isnt sufficient for other platform/backends I can think of and would require more specific tweaking for different main method forms .
What it should do is identify the candidate method and flag it ( or have it implicitly flagged by the language ('
cue main') and pass the entire handling/wrapping/arg synthesis off to the backend implementation to generate in one hit (simply, clearly and in one place).
Main method forms and restrictions are backend specific after all..
-- \n removal
Hmm - I'd feel better about that if you could actually point to an example of (Test or other ) failure
Examining the (C#) code gen shows the (new) line has the same line number marker as the condition check which is the same line number as the previous aggregated condition so I believe your belief is unfounded (
).