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

Make apply_type_nothrow robust against TypeVars in upper bounds #49863

Merged
merged 2 commits into from
May 19, 2023

Conversation

martinholters
Copy link
Member

For types like Foo{S, T<:S}, apply_type_nothrow could in some situations check whether the argument is a subtype of the upper bound of T, i.e. S, but subtyping agaist a plain TypeVar would fail. Instead return false in this case.

Fixes #49785.

For types like `Foo{S, T<:S}`, `apply_type_nothrow` could in some
situations check whether the argument is a subtype of the upper bound of
`T`, i.e. `S`, but subtyping agaist a plain `TypeVar` would fail.
Instead return `false` in this case.

Fixes #49785.
@martinholters
Copy link
Member Author

┌ Error: Error during loading of extension Extension of HasExtensions, use `Base.retry_load_extensions()` to retry.
│   exception =
│    1-element ExceptionStack:
│    LoadError: TypeError: in typeassert, expected String, got a value of type Base.UUID

everywhere. Is that happening elsewhere, too? Or could this PR have caused it?

@KristofferC
Copy link
Member

Just needs a rebase. (which I did)

@martinholters martinholters merged commit 1acec74 into master May 19, 2023
@martinholters martinholters deleted the mh/fix-49785 branch May 19, 2023 10:04
@martinholters martinholters added the backport 1.9 Change should be backported to release-1.9 label May 19, 2023
@@ -1665,7 +1665,7 @@ function apply_type_nothrow(𝕃::AbstractLattice, argtypes::Vector{Any}, @nospe
end
else
istype || return false
if !(T <: u.var.ub)
if isa(u.var.ub, TypeVar) || !(T <: u.var.ub)
Copy link
Member

Choose a reason for hiding this comment

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

This could also do has_free_typevars(u.var.ub) to cover some other (even more rare) cases

@KristofferC KristofferC mentioned this pull request Jun 6, 2023
36 tasks
KristofferC pushed a commit that referenced this pull request Jun 27, 2023
…49863)

For types like `Foo{S, T<:S}`, `apply_type_nothrow` could in some
situations check whether the argument is a subtype of the upper bound of
`T`, i.e. `S`, but subtyping agaist a plain `TypeVar` would fail.
Instead return `false` in this case.

Fixes #49785.

(cherry picked from commit 1acec74)
KristofferC pushed a commit that referenced this pull request Jun 27, 2023
…49863)

For types like `Foo{S, T<:S}`, `apply_type_nothrow` could in some
situations check whether the argument is a subtype of the upper bound of
`T`, i.e. `S`, but subtyping agaist a plain `TypeVar` would fail.
Instead return `false` in this case.

Fixes #49785.

(cherry picked from commit 1acec74)
@KristofferC KristofferC removed the backport 1.9 Change should be backported to release-1.9 label Jul 10, 2023
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.

mapping a NamedTuple prints Internal error: encountered unexpected error in runtime
4 participants