-
Couldn't load subscription status.
- Fork 49.7k
[compiler] repro for dep merging edge case (non-hir) #31035
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
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice find!!!! Yeah this makes sense, seems like we can adjust the merging logic to account for this case to keep the impact of fixing this case pretty limited.
Found when writing #31037, summary copied from comments: This is an extreme edge case and not code we'd expect any reasonable developer to write. In most cases e.g. `(a?.b != null ? a.b : DEFAULT)`, we do want to take a dependency on `a?.b`. I found this trying to come up with edge cases that break the current dependency + CFG merging logic. I think it makes sense to error on the side of correctness. After all, we still take `a` as a dependency if users write `a != null ? a.b : DEFAULT`, and the same fix (understanding the `<hoistable> != null` test expression) works for both. Can be convinced otherwise though! ghstack-source-id: cc06afd Pull Request resolved: #31035
Stack from ghstack (oldest at bottom):
Found when writing #31037, summary copied from comments:
This is an extreme edge case and not code we'd expect any reasonable developer to write. In most cases e.g.
(a?.b != null ? a.b : DEFAULT), we do want to take a dependency ona?.b.I found this trying to come up with edge cases that break the current dependency + CFG merging logic. I think it makes sense to error on the side of correctness. After all, we still take
aas a dependency if users writea != null ? a.b : DEFAULT, and the same fix (understanding the<hoistable> != nulltest expression) works for both. Can be convinced otherwise though!