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.
Daniel Zuncke
Daniel Zuncke
WebFreak001
Razvan Nitu
Eugen Wissner
Bastiaan Veelo
Martin Kinkelin
Sönke Ludwig