Error description:
In formatColon() the colon that should match a question mark gets
selected as the default case of the if-else ladder which is a guaranteed
" : ". Amongst the previous one there is the associated array matcher
which is selected since this is happening in an aa (it just checks for
surrounding []).
Solution:
Harden associated array if-condition. Existing data does not contain
enough information, store ternary conditional colon indices in
an array in ASTInformation. Before an associated array is matched,
confirm that it isn't part of ternary conditional.
If it is a ternary colon, it will fall through the if-ladder like
before.
I have formatted them both to look like the the individual bad output
and not like the actual output from formatting the issue0432.d file with
the current implementation. The current implementation makes it look
like a new / different problem.
Overview:
Array astInformation.structInitEndLocations is used to find index to use
in astInformation.indentInfoSortedByEndLocation.
Both are sorted, first is used to find the array index, second is
accessed at that index to get brace indentation information.
Problem:
structInitEndLocations is generated from struct initializers
exclusively while the brace information array also contains entries
for function literal initializers. Thus when function literal init(s)
are used, we get accumulating off by one errors in the second array:
match value in structInitEndLocations and take that index:
[3, 50]
^--> index 1
take brace indent information from that index:
[3, 15, 50]
| ^--> the one we want
^------> the one we get (function literal init)
Solution:
This guarantees that searching forward works.
While better search strategies than linear are possible, this should be
enough for any sane and most of the insane code files.
Multi-line tokens would be written with `LF`, regardless the `end_of_line` setting.
Fixes#228 and also produces end_of_line specified line-endings in strings.