Skip to content

Conversation

@som-snytt
Copy link
Contributor

Fixes #24562
by improving the fidelity of the rewrite of constructor proxy call to new, just for references to exported members.

@som-snytt som-snytt force-pushed the issue/24562-import-exported-member branch from 83cc29a to 7cfdda5 Compare December 1, 2025 16:00
@som-snytt
Copy link
Contributor Author

som-snytt commented Dec 1, 2025

The existing behavior (essentially "dealiasing") is always fine because the exported type must be accessible.

The argument for the change is that p.C() means the same as new p.C() (not dealiased) and not the underlying new q.X().

There is no downside in that it is "just an alias".

package p:
  object X:
    export q.C

package q:
  class C
  object C:
    trait cops:
      extension (c: C) def ok = "hello, world"
    given cops

package test:
  @main def main = println:
    val c: p.X.C = p.X.C()
    //val c = p.X.C()
    c.ok

The fix uses current behavior if there is no "sibling type" to the exported companion (maybe that can't happen); the other question is whether looking for the "sibling" in the owner will induce cycles.

The alternative fix is to use an attachment for "fidelity", as is used for renaming import, for recovering the original name. The attachment would only need a symbol to look up (p.X.C) for its name and prefix.

What does it do with import p.X.C as D? Then newExpr should preserve the attachment in tpt. Maybe typedNew in turn preserves it, but for the resulting New, where the lint would not look for it?

Edit: the import rename is handled with the fix. I'll add the test...

@som-snytt
Copy link
Contributor Author

[123-1] X requests.RequestTests.gzipError 98ms 
[123-1]   requests.RequestFailedException: Request to https://api.github.com/users/lihaoyi failed with status code 403
@som-snytt som-snytt marked this pull request as ready for review December 1, 2025 17:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant