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.

Sign up for GitHub

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

Jump to bottom

Importing private extension function is suggested even after importing #22429

Open
andrzejressel opened this issue Jan 21, 2025 · 2 comments · May be fixed by #22430
Open

Importing private extension function is suggested even after importing #22429

andrzejressel opened this issue Jan 21, 2025 · 2 comments · May be fixed by #22430
Labels
area:extension-methods area:reporting Error reporting including formatting, implicit suggestions, etc better-errors Issues concerned with improving confusing/unhelpful diagnostic messages itype:language enhancement

Comments

@andrzejressel
Copy link
Contributor

Compiler version

3.3.4
3.6.3

Minimized code

https://scastie.scala-lang.org/9ViV1YHoQVaaRBfcq066Kg

import Playground.Extensions.testExt

object Extensions {
  extension (s: String) {
    private def testExt() = {
    
    }
  }
}

"abc".testExt()

Output

value testExt is not a member of String, but could be made available as an extension method.

The following import might fix the problem:

  import Playground.Extensions.testExt

Expectation

Something about testExt having too restricted visibility. At least not suggesting import when it already exists.
@andrzejressel andrzejressel added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels Jan 21, 2025
@som-snytt som-snytt linked a pull request Jan 22, 2025 that will close this issue
Draft
@som-snytt som-snytt added itype:language enhancement better-errors Issues concerned with improving confusing/unhelpful diagnostic messages and removed itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels Jan 22, 2025
@som-snytt
Copy link
Contributor

I posted a quick draft PR that only shows candidates with restricted access if there are no others.

When showing those candidate imports, mention if there is already such an import but the member is inaccessible.

Probably the usual case is that there is one such extension, but we overlook that a member is private; sometimes we are working on a module with access, then write some code elsewhere and suddenly none of our idioms work.

I am mostly guessing about the use case.

@andrzejressel
Copy link
Contributor Author

My case was refactoring. Private extension functions work fine from within surrounding class. During refactoring I've extracted it to separate file.

@Gedochao Gedochao added area:reporting Error reporting including formatting, implicit suggestions, etc area:extension-methods labels Jan 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area:extension-methods area:reporting Error reporting including formatting, implicit suggestions, etc better-errors Issues concerned with improving confusing/unhelpful diagnostic messages itype:language enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Restrict import suggestions or mention accessibility som-snytt/dotty
3 participants
@som-snytt @andrzejressel @Gedochao