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.
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.
Now when an error in formatting happens, it never outputs anything and
doesn't override the file when working inplace.
Additionally dfmt is no longer able to fail in the middle of a file, as
now we first write everything to a buffer and only if everything was
successful, that buffer is printed to stdout or written to the inplace
file.
This should also guard against segfaults with inplace file formatting
erasing parts of the file, as well as the user thinking it was
successful, even though dfmt didn't finish properly.
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
WebFreak001
Robert Schadek
Eugen Wissner
Razvan Nitu
Iain Buclaw
Andrey Proskurin
Bastiaan Veelo
skyline131313
Max Haughton
Bastiaan Veelo
Martin Kinkelin
Sönke Ludwig
Amin Yahyaabadi