Skip to content

Fix usage of outer type argument in extension inline unapply #15189

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

Closed
wants to merge 15 commits into from

Conversation

gorilskij
Copy link

@gorilskij gorilskij commented May 14, 2022

Fixes #15191

@prolativ
Copy link
Contributor

@gorilskij I'm a bit confused. Is this a duplicate of #15191 fixing #15188 ?

@gorilskij
Copy link
Author

@prolativ Sorry, I messed up a bit with the first issue
#15191 is a fix for #8577 (#15053 was the first pull for this but I accidentally closed it, better this way)
#15189 is a fix for #15188 which is an issue that appears only once the first fix is implemented

@prolativ
Copy link
Contributor

Somehow I managed to reproduce #15188 on the main branch even without #15191.
But I don't think it would be a good idea to merge a PR knowing that it introduces a bug, especially that there's already a fix for it. Why don't you just merge these 2 PRs then? As the tests are actually the same and the implementations are quite concise I think that would be the most elegant solution in this case.

${ implUnapplyD('ctx, 'input) }

// miscompilation
// val macroD"$xD" = 4
Copy link
Contributor

Choose a reason for hiding this comment

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

If the intentional that this should not compile?
If so, you could create a separate netagive test in tests/neg/

}
}

// {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this section commented out?

@gorilskij
Copy link
Author

@prolativ you're right, my bad, I thought initially it was dependent but it isn't. Even the code I posted in the issue has the same error with #15191 as without it. These are separate issues, only the test cases of #15189 depend on #15191. They probably should be merged, is there an easy way to do this or should I make a new PR for both?

@prolativ
Copy link
Contributor

IMO you can just get all the code changes into one of the PRs and close the other

@nicolasstucki nicolasstucki self-assigned this May 23, 2022
@gorilskij
Copy link
Author

Folded into #15191

@gorilskij gorilskij closed this Jun 13, 2022
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.

3 participants