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

Avoid impossible unionall normalization #42003

Merged
merged 1 commit into from
Sep 1, 2021

Conversation

martinholters
Copy link
Member

Cousin of #41976, fixing the second case of #41908 (comment).

If the unionall bounds are inconsistent with the wrapper's bound, avoid
throwing due to an impossible type instantiation.
@KristofferC
Copy link
Sponsor Member

bugfix? (and thus should be backported?)

@martinholters
Copy link
Member Author

I'd say yes.

@martinholters martinholters added backport 1.6 Change should be backported to release-1.6 backport 1.7 labels Aug 25, 2021
@vtjnash
Copy link
Sponsor Member

vtjnash commented Aug 25, 2021

I am not sure it is to be expected that apply type is infailable. There seem like other reasons (earlier) that it could also fail?

@martinholters
Copy link
Member Author

martinholters commented Aug 25, 2021

True, but that there are types T for which Tuple{T} fails seems a bit of a gotcha.
EDIT:
E.g., it comes unexpected when forming the dispatch tuple for a function call:

julia> foo(x) = abs(x::(Complex{T} where String<:T<:String))
foo (generic function with 1 method)

julia> code_typed(foo, (Any,))
ERROR: TypeError: in Complex, in T, expected T<:Real, got Type{String}
Stacktrace:
  [1] argtypes_to_type
[...]

With this PR, inference succeeds.

@vtjnash vtjnash added the merge me PR is reviewed. Merge when all tests are passing label Aug 25, 2021
@vtjnash vtjnash merged commit b5b0684 into master Sep 1, 2021
@vtjnash vtjnash deleted the mh/avoid-imposssible-unionall-normalization branch September 1, 2021 17:43
KristofferC pushed a commit that referenced this pull request Sep 2, 2021
If the unionall bounds are inconsistent with the wrapper's bound, avoid
throwing due to an impossible type instantiation.

(cherry picked from commit b5b0684)
KristofferC pushed a commit that referenced this pull request Sep 3, 2021
If the unionall bounds are inconsistent with the wrapper's bound, avoid
throwing due to an impossible type instantiation.

(cherry picked from commit b5b0684)
KristofferC pushed a commit that referenced this pull request Sep 6, 2021
If the unionall bounds are inconsistent with the wrapper's bound, avoid
throwing due to an impossible type instantiation.

(cherry picked from commit b5b0684)
@DilumAluthge DilumAluthge removed the merge me PR is reviewed. Merge when all tests are passing label Sep 6, 2021
@KristofferC KristofferC removed backport 1.6 Change should be backported to release-1.6 backport 1.7 labels Sep 7, 2021
LilithHafner pushed a commit to LilithHafner/julia that referenced this pull request Feb 22, 2022
If the unionall bounds are inconsistent with the wrapper's bound, avoid
throwing due to an impossible type instantiation.
LilithHafner pushed a commit to LilithHafner/julia that referenced this pull request Mar 8, 2022
If the unionall bounds are inconsistent with the wrapper's bound, avoid
throwing due to an impossible type instantiation.
staticfloat pushed a commit that referenced this pull request Dec 23, 2022
If the unionall bounds are inconsistent with the wrapper's bound, avoid
throwing due to an impossible type instantiation.

(cherry picked from commit b5b0684)
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.

4 participants