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

Fix #18649: Use loBound of param types when materializing a context function. #18651

Merged
merged 1 commit into from
Oct 12, 2023

Conversation

sjrd
Copy link
Member

@sjrd sjrd commented Oct 5, 2023

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.


Giving this one to @nicolasstucki, since you've been playing with function types recently.

Copy link
Contributor

@nicolasstucki nicolasstucki left a comment

Choose a reason for hiding this comment

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

Otherwise LGTM

compiler/src/dotty/tools/dotc/transform/TreeChecker.scala Outdated Show resolved Hide resolved
@nicolasstucki nicolasstucki assigned sjrd and unassigned nicolasstucki 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 sjrd force-pushed the fix-wildcard-contextual-fun-param branch from 3ba4ce1 to 242e68f Compare October 12, 2023 09:11
@sjrd sjrd enabled auto-merge October 12, 2023 09:12
@sjrd sjrd merged commit 85d55e7 into scala:main Oct 12, 2023
16 checks passed
@sjrd sjrd deleted the fix-wildcard-contextual-fun-param branch October 12, 2023 10:53
@Kordyjan Kordyjan added this to the 3.4.0 milestone Dec 20, 2023
WojciechMazur added a commit that referenced this pull request Jun 20, 2024
… context function." to LTS (#20645)

Backports #18651 to the LTS branch.

PR submitted by the release tooling.
[skip ci]
WojciechMazur added a commit that referenced this pull request Jun 20, 2024
… context function." to LTS (#20698)

Backports #18651 to the LTS branch.

PR submitted by the release tooling.
[skip ci]
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.

Context function with wildcard generates nonsensical tasty with TYPEBOUNDS as the info a ValDef
3 participants