Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Judicious shadowing of implicits from scope#11052

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
som-snytt wants to merge2 commits intoscala:2.13.x
base:2.13.x
Choose a base branch
Loading
fromsom-snytt:issue/12351-implicit-in-self-type

Conversation

som-snytt
Copy link
Contributor

@som-snyttsom-snytt commentedMay 6, 2025
edited
Loading

Fixesscala/bug#12351
Fixesscala/bug#9208

Retire both the old and new "implicit shadowing" mechanisms in favor of usingctx.lookupSymbol.

Tweak whenctx.implicitss collects implicits from a class by waiting to useowner.thisType.implicitMembers.

A notable improvement in correctness is that overloaded implicits are handled correctly (seeneg/t729.scala). The spec for lexically scoped implicits is that the value must be "accessible without a prefix". (Probably a member was seen once in a nested context and then again as an overload in the class type, which was taken as shadowed.)

The shadowing test inisQualifyingImplicit is removed; further clean-up of removed code is still needed after more testing.

There are two test tweaks to address which are due to existing cyclic error handling: in one case (t712), where one implicit member causes a cycle, the other implicit member is not collected; in the other case (virtpatmat_typetag), an explicit type is spuriously required for a class tag, also due to an existing cyclic error.

Also 2509 switched order when reporting ambiguous, which is supposed to have "winner" first. Maybe benign or progress.

@scala-jenkinsscala-jenkins added this to the2.13.17 milestoneMay 6, 2025
@lrytz
Copy link
Member

sounds good! i'll need to find some time to look into it. want to run a community build on it early?

@som-snytt
Copy link
ContributorAuthor

som-snytt commentedMay 6, 2025
edited
Loading

@lrytz thanks, before late bedtime I almost gave you a heads up to ask if you'd like me to continue the PR.

Before spending electrons on CB, I'll try some projects locally. I expect to discover more behaviors.

Edit: the cycle will need fixing first, I hit it right away. I'll leave the PR open out of sheer optimism.

@som-snytt
Copy link
ContributorAuthor

som-snytt commentedMay 11, 2025
edited
Loading

Maybe there's nothing better to do than catch & ignore.

This is current behavior, regular type check fails in "assign type to tree" because asking if it's a refinement (typedDefDef) means checking all overrides. I see dotty has a<refinement> artifact. My bigger idea was thatlookupSymbol need not force inlookupInPrefix, since it just needs to search parents for the name to detect that there is a symbol with that name; actually getting the (possibly overloaded) symbol is not necessary when probing. typedIdent tries a few strategies; I hoped gentler probing might help with cycles, but maybe wishful thinking.

[log typer] collect local implicits List(primary constructor $anon, type T, getter tTag, value tTag )[log typer] collect local implicits List(<$anon: <empty>.this.Extractors>)[log typer] collect local implicits List(type skolem S&0, value a, value evidence$1)[log typer] collect local implicits List()[log typer] collect local implicits List(primary constructor C, method extractorMatch)huh.scala:20: tTag is not a valid implicit value for reflect.this.ClassTag[$anon.this.T] because:illegal cyclic reference involving getter tTag    (new Extractors { type T = S; val tTag = classTag[T] })(a)                                                     ^

I haven't looked at what problem is solved by "pre-filtering".typedImplicit already says we're checking shadowing to reduce ambiguity, andtypedIdent is basically just the lookup. It's nice to think that filtering is efficient, but not at the cost of correctness; and maybe it had more benefit in ancient days.

@som-snyttsom-snyttforce-pushed theissue/12351-implicit-in-self-type branch from2b25baf to111db9dCompareMay 11, 2025 18:42
@som-snyttsom-snyttforce-pushed theissue/12351-implicit-in-self-type branch from111db9d to23a43f2CompareMay 11, 2025 18:50
@som-snyttsom-snytt marked this pull request as ready for reviewMay 13, 2025 18:58
@lrytz
Copy link
Member

Has a conflict. I'll try to make some time for reviewing this change.

@som-snytt
Copy link
ContributorAuthor

I'll freshen the PR and look at it with fresh eyes; my eyes will be fresh right after a cup of coffee.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
2.13.17
Development

Successfully merging this pull request may close these issues.

Type inference affects on implicit parameters inside traits? Implicit lookup interacts with import order
3 participants
@som-snytt@lrytz@scala-jenkins

[8]ページ先頭

©2009-2025 Movatter.jp