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

Lift arguments of explicitly constructed annotations #22553

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

mbovel
Copy link
Member

@mbovel mbovel commented Feb 7, 2025

Fixes #22526.

@mbovel mbovel requested a review from lrytz February 7, 2025 17:00
@mbovel mbovel force-pushed the mb/annot-default-new branch 2 times, most recently from 8cc0706 to a9557b6 Compare February 7, 2025 17:10
@@ -13,3 +13,6 @@ def test =
@annot(44) val z3 = 45
@annot2(y = Array("Hello", y)) val z4 = 45

// Arguments are still lifted if the annotation class is instantiated
// explicitly. See #22526.
val z5 = new annot2(y = Array("World"), x = 1)
Copy link
Member

Choose a reason for hiding this comment

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

What happens on @annot(y = new A, x = new annot(y = new B, x = new C))?

I think in principle, the AST should be

new annot(
  x = { val y$1 = new B; val x$1 = new C; new annot(x = x$1, y = y$1) }
  y = new A)

Copy link
Member Author

@mbovel mbovel Feb 10, 2025

Choose a reason for hiding this comment

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

I have just pushed a commit that addresses that.

I can agree with the principle in this case. But in general, it should be noted that trees in annotation arguments are currently not guaranteed to be valid by any definition. We should spec it.

Copy link
Member

@lrytz lrytz left a comment

Choose a reason for hiding this comment

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

Looks good to me.

The Scala 3 typer seems to use modes a bit different than Scala 2.

Scala 2 clears mode bits in several places, e.g. in typedArg. Mode flags can be declared to stay active when passing those thresholds. I didn't spot anything like that in Scala 3.

Scala 3 also seems to use expected types (FunProto, PolyProto) for things that are done with modes in Scala 2 (FUNmode, POLYmode).

I'm just saying I'm not familiar with modes in Scala 3, so maybe someone else should also review this.

@mbovel
Copy link
Member Author

mbovel commented Feb 10, 2025

Thanks for the review @lrytz !

@smarter would you have time to review this PR as well ? I am asking because you reviewed the two previous PRs about lifting arguments in annotations (#22035 and #22046).

Comment on lines +539 to +540
if wideFormal eq formal then ctx.retractMode(Mode.InAnnotation)
else ctx.retractMode(Mode.InAnnotation).withNotNullInfos(ctx.notNullInfos.retractMutables)
Copy link
Member

Choose a reason for hiding this comment

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

Can this flag be added to argCtx in

def argCtx(app: untpd.Tree)(using Context): Context =
instead ? That seems more generic. Also the reason for doing that should be documented (and the flag InAnnotation should document that it's turned off for arguments).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Arguments should be lifted in explicit constructor calls of annotation classes
3 participants