Skip to content

Fix #9751: Fix Inline purity checks #9753

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

Merged
merged 1 commit into from
Sep 10, 2020

Conversation

nicolasstucki
Copy link
Contributor

@nicolasstucki nicolasstucki commented Sep 8, 2020

We wrongly identified most inline references as pure as they are effectively erased.
Only erased terms are always pure.
Most of the purity of inline references follows from the normal purity rules except for inline parameters.
These parameters lose their binding when inlined and no purity guaranty can be ensured from the reference.

@nicolasstucki nicolasstucki changed the title Fix #9751: Widen references to catch inline parameters with unit type Fix #9751: Identify Inlined trees and make Inline impure Sep 9, 2020
@nicolasstucki nicolasstucki changed the title Fix #9751: Identify Inlined trees and make Inline impure Fix #9751: Fix Inline purity checks Sep 9, 2020
We wrongly identified most inline references as pure as they are effectively erased.
Only erased terms are always pure.
Most of the purity of inline references follows from the normal purity rules except for inline parameters.
These parameters lose their binding when inlined and no purity guaranty can be ensured from the reference.
Copy link
Contributor

@liufengyun liufengyun left a comment

Choose a reason for hiding this comment

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

Otherwise, LGTM

&& !ctx.isAfterTyper
&& !tree.isInstanceOf[Inlined]
&& isPureExpr(tree)
&& !isSelfOrSuperConstrCall(tree)
Copy link
Contributor

Choose a reason for hiding this comment

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

tree.isInstanceOf[Inlined] : can an inlined tree be pure? What about handle inlined trees in isPureExpr?

Copy link
Contributor Author

@nicolasstucki nicolasstucki Sep 10, 2020

Choose a reason for hiding this comment

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

The Inlined trees can be pure which is correctly identified in isPureExpr. Here we special case a
Inlined calls that inserted a pure expression in a statement position as these are only pure due to other constraints that may change. For example, the assert can take a reference to an Inlined true value which converts it in a no-op and we do not want to warn that this is a pure expression in statement position.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for the explanation. It might be good to add a short comment after the line.

@@ -47,7 +47,7 @@ abstract class TransformByNameApply extends MiniPhase { thisPhase: DenotTransfor
ref(defn.cbnArg).appliedToType(argType).appliedTo(arg).withSpan(arg.span)
arg match {
case Apply(Select(qual, nme.apply), Nil)
if qual.tpe.derivesFrom(defn.FunctionClass(0)) && isPureExpr(qual) =>
if qual.tpe.derivesFrom(defn.FunctionClass(0)) && (isPureExpr(qual) || qual.symbol.isAllOf(Inline | Param)) =>
Copy link
Contributor

Choose a reason for hiding this comment

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

Does it matter? If I were correct, the body of inlined methods is never executed, thus only the TASTY matters.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In theory that seems to be the case. But I caught one that came for the DottyPredef.assert when compiling dotty itself. It might be a re-bootstrapping issue.

Copy link
Contributor

Choose a reason for hiding this comment

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

I see. It could be some invariants after the typer -- and it's always good to do so.

@nicolasstucki nicolasstucki merged commit 8639874 into scala:master Sep 10, 2020
@nicolasstucki nicolasstucki deleted the fix-#9751 branch September 10, 2020 08:12
@Kordyjan Kordyjan added this to the 3.0.0 milestone Aug 2, 2023
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.

3 participants