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

Handle generic tuples when inlining #14209

Closed
wants to merge 3 commits into from

Conversation

nicolasstucki
Copy link
Contributor

Fixes #14182

@nicolasstucki nicolasstucki self-assigned this Jan 4, 2022
@nicolasstucki nicolasstucki force-pushed the fix-#14182 branch 6 times, most recently from 87e76a9 to 8d8ef51 Compare January 5, 2022 10:23
// If we take the `tree1` then it is impossible to select the `_1` field. If we take the parameter type we can lose singletons references that we should keep.
// Ideally we should ascribe it to a `tup.type & Tuple2[Int, Int]` but that is not working because we have the some special sub-typing rule that makes
// `1 *: 2 *: EmptyTuple <:< Tuple2[Int, Int]`. Therefore the glb of the two types ends up being `tup.type` which drops the extra information we need to add.
// None of the following attempts work.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

An alternative would be to teach member resolution that if we have a generic tuple with a known size that erases to TupleN it has the members of that TupleN class. For example a Int *: EmptyTuple would have the member _1 because it has the members of TupleN.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This member selection issue is not contained in inlining. It was fairly straightforward to reproduce using type parameters in #14215.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@odersky said to look at
Line 3848 Typer: pt match
case pt: SelectionProto =>
insert type ascription and readapt

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.

Cyclic stuff and stale symbol in macro
1 participant