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 21258 - Tuple parameters use the first element of a default tuple value #11749

Merged
merged 1 commit into from
Sep 18, 2020

Conversation

Geod24
Copy link
Member

@Geod24 Geod24 commented Sep 17, 2020

The logic tried to use a single variable for both keeping track of the
original index and the extended index, but actually only tracked the
extended index.
Since if (tupleStartIdx < eidx) tupleStartIdx = eidx would be true
for every iteration, we would always assign the value at index 0.

@Geod24 Geod24 added the Review:stable-priority A regression fix to stable that should receive higher priority label Sep 17, 2020
@dlang-bot
Copy link
Contributor

Thanks for your pull request, @Geod24!

Bugzilla references

Auto-close Bugzilla Severity Description
21258 regression Tuple parameters with defaults use the first tuple element for all defaults since 2.094.0-beta.1

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "stable + dmd#11749"

@UplinkCoder
Copy link
Member

@Geod24 very nice!

@Geod24
Copy link
Member Author

Geod24 commented Sep 17, 2020

Let's hold on for a couple hours, maybe someone will suggest additional tests (that someone might be me).

@UplinkCoder
Copy link
Member

@Geod24 If you could improve the commit message, to say what the typo caused that'd be good.

@Geod24
Copy link
Member Author

Geod24 commented Sep 17, 2020

Heh, the logic was flawed anyway and failed for tuples > 2 elements. Should be properly fixed now.

@rmanthorpe
Copy link
Contributor

Thanks for sorting it out so quickly!

src/dmd/typesem.d Outdated Show resolved Hide resolved
@Geod24
Copy link
Member Author

Geod24 commented Sep 18, 2020

Fixed: Changed static array to two variables.

@@ -1494,7 +1494,11 @@ extern(C++) Type typeSemantic(Type type, const ref Loc loc, Scope* sc)
// Now that we completed semantic for the argument types,
// run semantic on their default values,
// bearing in mind tuples have been expanded.
size_t tupleStartIdx = size_t.max;
// We need to keep a pair of [oidx, eidx] (original index,
// extended index), so we now to run semantic when the original
Copy link
Contributor

Choose a reason for hiding this comment

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

grammar. get rid of to.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good catch. Actually the sentence wasn't quite accurate so I rephrased it.

… value

The logic tried to use a single variable for both keeping track of the
original index and the extended index, but actually only tracked the
extended index.
Since `if (tupleStartIdx < eidx) tupleStartIdx = eidx` would be true
for every iteration, we would always assign the value at index 0.
@dlang-bot dlang-bot merged commit e0a9304 into dlang:stable Sep 18, 2020
@Geod24 Geod24 deleted the fix-21258 branch September 18, 2020 02:50
@Geod24 Geod24 mentioned this pull request Sep 18, 2020
@UplinkCoder
Copy link
Member

Confirmed to fix our code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Merge:auto-merge Review:stable-priority A regression fix to stable that should receive higher priority Severity:Bug Fix
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants