-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
inference: Remove special case for typename
#55273
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
This was introduced in [1] to improve constant propagation. These days this is handled via concrete eval and the special case is no longer required. [1] 0292c42
There's a remaining question here of whether we're losing any precision for the ::Type case and if so whether that matters. |
We do lose this one:
Before:
After:
Let me think about whether there's something that can be tweaked here with effect annotations. |
If not, the easy answer is just to put this one in |
I think I'll probably just do this. The key extra bit of information that the compiler does not know is that checking that they're all equal retroactively makes taking union components out legal, but I don't see a good generic way to annotate that. |
As mentioned in #55271, the `istopfunction` binding-based comparisons are problematic. In #55272 and #55273, I attempted to remove the inference special cases for `>:` and `typename` (respectively) entirely, but for differing reasons (`>:` gets too many extra specializations, `typename` loses precision), those PRs are suboptimal. As discussed in #55273, this PR instead moves these functions to Core, so that both `Core.Compiler` and `Base` share the function object, allowing inference to detect them and apply the special handling by simple value-comparison.
As mentioned in #55271, the `istopfunction` binding-based comparisons are problematic. In #55272 and #55273, I attempted to remove the inference special cases for `>:` and `typename` (respectively) entirely, but for differing reasons (`>:` gets too many extra specializations, `typename` loses precision), those PRs are suboptimal. As discussed in #55273, this PR instead moves these functions to Core, so that both `Core.Compiler` and `Base` share the function object, allowing inference to detect them and apply the special handling by simple value-comparison.
As mentioned in #55271, the `istopfunction` binding-based comparisons are problematic. In #55272 and #55273, I attempted to remove the inference special cases for `>:` and `typename` (respectively) entirely, but for differing reasons (`>:` gets too many extra specializations, `typename` loses precision), those PRs are suboptimal. As discussed in #55273, this PR instead moves these functions to Core, so that both `Core.Compiler` and `Base` share the function object, allowing inference to detect them and apply the special handling by simple value-comparison.
This PR is going to be replaced by #55289 . |
…alue As mentioned in #55271, the `istopfunction` binding-based comparisons are problematic. In #55272 and #55273, I attempted to remove the inference special cases for `>:` and `typename` (respectively) entirely, but for differing reasons (`>:` gets too many extra specializations, `typename` loses precision), those PRs are suboptimal. As discussed in #55273, this PR instead moves these functions to Core, so that both `Core.Compiler` and `Base` share the function object, allowing inference to detect them and apply the special handling by simple value-comparison.
…55289) As mentioned in #55271, the `istopfunction` binding-based comparisons are problematic. In #55272 and #55273, I attempted to remove the inference special cases for `>:` and `typename` (respectively) entirely, but for differing reasons (`>:` gets too many extra specializations, `typename` loses precision), those PRs are suboptimal. As discussed in #55273, this PR instead moves these functions to Core, so that both `Core.Compiler` and `Base` share the function object, allowing inference to detect them and apply the special handling by simple value-comparison. --- - closes #55273
…uliaLang#55289) As mentioned in JuliaLang#55271, the `istopfunction` binding-based comparisons are problematic. In JuliaLang#55272 and JuliaLang#55273, I attempted to remove the inference special cases for `>:` and `typename` (respectively) entirely, but for differing reasons (`>:` gets too many extra specializations, `typename` loses precision), those PRs are suboptimal. As discussed in JuliaLang#55273, this PR instead moves these functions to Core, so that both `Core.Compiler` and `Base` share the function object, allowing inference to detect them and apply the special handling by simple value-comparison. --- - closes JuliaLang#55273
This was introduced in [1] to improve constant propagation. These days this is handled via concrete eval and the special case is no longer required.
[1] 0292c42