-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Context function with wildcard generates nonsensical tasty with TYPEBOUNDS as the info a ValDef #18649
Labels
Comments
sjrd
added
itype:bug
area:typer
stat:needs triage
Every issue needs to have an "area" and "itype" label
labels
Oct 4, 2023
sjrd
added a commit
to dotty-staging/dotty
that referenced
this issue
Oct 5, 2023
…ext function. Since the param types come from type arguments to `ContextFunctionN[...]`, nothing prevents them a priori from being wildcard type params, i.e., `TypeBounds`. However, that is not a valid type to give to a concrete term param. We can arbitrarily choose any type that conforms to the bounds, which realistically means one of the two bounds. Since type inference already chooses the lower bound when explicitly writing the context function, we align and choose the lower bound when materializing it.
sjrd
removed
the
stat:needs triage
Every issue needs to have an "area" and "itype" label
label
Oct 5, 2023
sjrd
added a commit
to dotty-staging/dotty
that referenced
this issue
Oct 12, 2023
…ext function. Since the param types come from type arguments to `ContextFunctionN[...]`, nothing prevents them a priori from being wildcard type params, i.e., `TypeBounds`. However, that is not a valid type to give to a concrete term param. We can arbitrarily choose any type that conforms to the bounds, which realistically means one of the two bounds. Since type inference already chooses the lower bound when explicitly writing the context function, we align and choose the lower bound when materializing it.
sjrd
added a commit
that referenced
this issue
Oct 12, 2023
…unction. (#18651) Since the param types come from type arguments to `ContextFunctionN[...]`, nothing prevents them a priori from being wildcard type params, i.e., `TypeBounds`. However, that is not a valid type to give to a concrete term param. We can arbitrarily choose any type that conforms to the bounds, which realistically means one of the two bounds. Since type inference already chooses the lower bound when explicitly writing the context function, we align and choose the lower bound when materializing it.
WojciechMazur
pushed a commit
that referenced
this issue
Jun 19, 2024
…unction. Since the param types come from type arguments to `ContextFunctionN[...]`, nothing prevents them a priori from being wildcard type params, i.e., `TypeBounds`. However, that is not a valid type to give to a concrete term param. We can arbitrarily choose any type that conforms to the bounds, which realistically means one of the two bounds. Since type inference already chooses the lower bound when explicitly writing the context function, we align and choose the lower bound when materializing it. [Cherry-picked 242e68f]
WojciechMazur
pushed a commit
that referenced
this issue
Jun 20, 2024
…unction. Since the param types come from type arguments to `ContextFunctionN[...]`, nothing prevents them a priori from being wildcard type params, i.e., `TypeBounds`. However, that is not a valid type to give to a concrete term param. We can arbitrarily choose any type that conforms to the bounds, which realistically means one of the two bounds. Since type inference already chooses the lower bound when explicitly writing the context function, we align and choose the lower bound when materializing it. [Cherry-picked 242e68f]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Compiler version
3.3.1
Minimized code
Output
Decoded TASTy Trees:
Note in particular the
DEFDEF
starting at address 63:The
PARAM
at address 66 with nameevidence$1
has aTYPEBOUNDS
as itsinfo
. This makes no sense: term symbols cannot have aTYPEBOUNDS
as their info.Alternative view: with
-Xprint:typer
, we get:which also shows that the
evidence$1
has an "empty" type. It's actually how the type printer "prints" aTypeBounds
of>: Nothing <: Any
.Expectation
The type should be
Nothing
instead, or in general, the lower bound of the wildcard.The text was updated successfully, but these errors were encountered: