Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix issue 578 #591

Merged
merged 6 commits into from
Oct 22, 2023
Merged

Fix issue 578 #591

merged 6 commits into from
Oct 22, 2023

Conversation

danielzuncke
Copy link
Contributor

The infos are in the commit message, a bit odd is the position of the new array in ASTInformation (all other size_t[] arrays come before the BraceIndentInfo and StructInitializerInfo array). The idea is to prevent breaking any intializers someone may have if this is used as an import. I think that's unlikely though, let me know if I should order it by type.

Github tells me this merges 5 commits, but it should only be the last one Fix issue 578. I am not too familiar with github, if I am doing it wrong please let me know.

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.
Using different variable to iterate to guarantee unchanged behaviour
if anything doesn't work as intended.
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.
auto aa1 = [0: true ? 1 : 0];
auto aa2 = [0: true ? (false ? 1 : 2) : 3];

auto aa3 = [0: true ? false ? 1: 2 : 3];
Copy link
Member

@WebFreak001 WebFreak001 Oct 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this seems to be a part of the issue you said would be fixed in the title, no?

Still got broken formatting here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My bad I misunderstood libdparse, I fix it

@WebFreak001 WebFreak001 merged commit 35e55bc into dlang-community:master Oct 22, 2023
1 check passed
@WebFreak001
Copy link
Member

please don't work on the master branch locally anymore, create branches for your fixes. You will have problems updating your master branch with upstream now unless you force push or recreate your fork

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants