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 19213 - goto skips declaration of variable in std.algorithm… #6803

Merged
merged 1 commit into from
Dec 31, 2018

Conversation

edi33416
Copy link
Contributor

….iteration.joiner

@dlang-bot
Copy link
Contributor

dlang-bot commented Dec 12, 2018

Thanks for your pull request and interest in making D better, @edi33416! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

  • My PR is fully covered with tests (you can see the annotated coverage diff directly on GitHub with CodeCov's browser extension
  • My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
  • I have provided a detailed rationale explaining my changes
  • New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.


If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close Bugzilla Severity Description
19213 regression goto skips declaration of variable in std.algorithm.iteration.joiner

Testing this PR locally

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

dub fetch digger
dub run digger -- build "stable + phobos#6803"

@edi33416
Copy link
Contributor Author

Changes to popBackEmptyElements were made to be consistent with the changes required by popFrontEmptyElements.

Note: the regression can be fixed just with the changes done in popFrontEmptyElements

Copy link
Member

@wilzbach wilzbach left a comment

Choose a reason for hiding this comment

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

Needs a test

// we need to .save each subrange we traverse.
static if (isForwardRange!RoR && isForwardRange!(ElementType!RoR))
_current = _items.front.save;
if (!_items.empty)
Copy link
Member

Choose a reason for hiding this comment

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

This is sub-optimal as it will be executed one-more time than strictly necessary.

Copy link
Member

Choose a reason for hiding this comment

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

It should be faster to do sth. this:

while (!_items.empty) {
   if (!_items.front.empty) {
      _items.popFront();
   } else {
     // <- static if code here
     break;
   }
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I still need the outside if (!_items.empty) { } else { } block, or the compiler will complain with Error: one path skips field _current.

This is because, in the case of an empty ROR, _current won't be initialised.

end:
assert(1); // required to avoid 'EOF instead of statement' error
{
_current = typeof(_current).init;
Copy link
Member

Choose a reason for hiding this comment

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

Why is this required?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The compiler requires that _current is initialised on all possible paths.

else
_currentBack = _items.back;
_current = typeof(_current).init;
_currentBack = typeof(_currentBack).init;
Copy link
Member

Choose a reason for hiding this comment

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

Why is this required?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Please see above comments

// consumed when a .save'd copy of ourselves is iterated over. So
// we need to .save each subrange we traverse.
static if (isForwardRange!RoR && isForwardRange!(ElementType!RoR))
if (!_items.empty)
Copy link
Member

Choose a reason for hiding this comment

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

This is sub-optimal as it will be executed one-more time than strictly necessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Please see above comments

@edi33416 edi33416 force-pushed the issue_19213 branch 2 times, most recently from 48e2215 to 17b7366 Compare December 14, 2018 13:08
@edi33416 edi33416 changed the base branch from master to stable December 14, 2018 13:09
auto results = [[1,2], [3,4]]
.map!(q => q.map!Rec.chunkBy!"a.foo")
.joiner;
}));
Copy link
Member

Choose a reason for hiding this comment

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

No need to use __traits(compiles here. Use the range directly and even assert that its still iterated correctly.
Also, it would be good to add a test for iterating this range backwards and checking the result.

@@ -2948,6 +2955,20 @@ if (isInputRange!RoR && isInputRange!(ElementType!RoR))
assert(!equal(js2, js));
}

// Bugzilla issue 19213
Copy link
Member

Choose a reason for hiding this comment

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

Use links to Bugzilla.

{
auto results = [[1,2], [3,4]].map!(q => q.chunkBy!"a").joiner;
int i = 1;
foreach(ref e; results)
Copy link
Member

Choose a reason for hiding this comment

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

Style target fails here due to missing whitespace after foreach. Why not use equals?
Also, we should probably test the bidirectional code too (use e.g. retro)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The result is not a bidirectional range, so I can't use retro.

@wilzbach wilzbach dismissed their stale review December 31, 2018 11:52

ok let's at least fix the bug before 2.084

@wilzbach wilzbach merged commit 07ea0e0 into dlang:stable Dec 31, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants