proposal - support struct literal shorthand notation

[softwareCobbler]

I see there is also an "CFMLExpressionInterpreter.java" but doing this all in the AbstrCFMLExprTransformer seemed to work.

{x} is now equivalent to {x : x} scope lookup rules are unchanged.

I've tried to model the behavior of Adobe's implementation, i.e. identifiers cannot be dotted-paths, so {variables.identifier} and {userStruct.value} are not valid. The ambiguity with ordered-structs is resolved by not supporting the shorthand syntax in that case (i.e. [a] is always "just" [a] and never possibly [a:a])

this should not affect arrays or ordered struct literals.

I've tested this on my machine by hand but can't get the coldbox tests portion of the build to run so I'd be interested to see the results there.

https://luceeserver.atlassian.net/browse/LDEV-2200

[CLAassistant]

All committers have signed the CLA.

[softwareCobbler]

Some failures appear due to floating point precision (i.e. "expected [0.795398830184] but received [0.7953988301841436]"), which is probably an easy fix.

I'm not sure what to do about the following:

Error:  Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (ant-magic) on project lucee: An Ant BuildException has occured: The following error occurred while executing this line:
Error:  /home/runner/work/Lucee/Lucee/ant/build-core.xml:511: Java returned: 1
Error:  around Ant part ...<ant antfile="../ant/build-core.xml" target="buildLoaderMaven"/>... @ 17:67 in /home/runner/work/Lucee/Lucee/loader/target/antrun/build-main.xml
Error:  -> [Help 1]

I was hitting this problem on a fresh repo clone. I posted a slack thing about it, so far my only solution was to temporarily drop the __buildTestBox dependency from the __build target. Any guidance would be appreciated.

[softwareCobbler]

I see a bunch of recent commits about touching up tests, so I gave another build run a go, and got a build working on a Linux box. Added a small test for the shorthand notation as well.

[michaeloffner]

i did like the idea a lot, the approach is interesting, but not consistent with the current implementation of the compiler. there is no need for changing the compiler itself, instead we simply can add a function evaluator, also error handling was a bit to basic. Here my implementation for this https://luceeserver.atlassian.net/browse/LDEV-4790 @softwareCobbler thanks a lot for your work on this, very appreciated!