-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Add @publicInBinary
annotation and -WunstableInlineAccessors
linting flag
#18402
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -22,6 +22,8 @@ import staging.CrossStageSafety | |
import config.Printers.inlining | ||
import util.Property | ||
import staging.StagingLevel | ||
import dotty.tools.dotc.reporting.Message | ||
import dotty.tools.dotc.util.SrcPos | ||
|
||
object PrepareInlineable { | ||
import tpd.* | ||
|
@@ -71,6 +73,7 @@ object PrepareInlineable { | |
sym.isTerm && | ||
(sym.isOneOf(AccessFlags) || sym.privateWithin.exists) && | ||
!sym.isContainedIn(inlineSym) && | ||
!sym.hasPublicInBinary && | ||
!(sym.isStableMember && sym.info.widenTermRefExpr.isInstanceOf[ConstantType]) && | ||
!sym.isInlineMethod && | ||
(Inlines.inInlineMethod || StagingLevel.level > 0) | ||
|
@@ -86,6 +89,11 @@ object PrepareInlineable { | |
|
||
override def transform(tree: Tree)(using Context): Tree = | ||
postTransform(super.transform(preTransform(tree))) | ||
|
||
protected def checkUnstableAccessor(accessedTree: Tree, accessor: Symbol)(using Context): Unit = | ||
if ctx.settings.WunstableInlineAccessors.value then | ||
val accessorTree = accessorDef(accessor, accessedTree.symbol) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Something I'm now wondering: if this annotation doesn't in fact change the bytecode we generate, then why do we bother going through the inline accessor when calling non-annotated protected/package-private methods? Couldn't we always make a direct call even if the method isn't annotated? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We need the annotation as a way to tell MiMa that this protected/package-private method can be used from outside the scope where it is defined. We might be able to do this optimization once we have established There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We could start using some of those package-private methods directly now but still generate the accessor. I will look into it after this PR and after the 3.4 release. |
||
report.warning(reporting.UnstableInlineAccessor(accessedTree.symbol, accessorTree), accessedTree) | ||
} | ||
|
||
/** Direct approach: place the accessor with the accessed symbol. This has the | ||
|
@@ -100,7 +108,11 @@ object PrepareInlineable { | |
report.error("Implementation restriction: cannot use private constructors in inline methods", tree.srcPos) | ||
tree // TODO: create a proper accessor for the private constructor | ||
} | ||
else useAccessor(tree) | ||
else | ||
val accessor = useAccessor(tree) | ||
if tree != accessor then | ||
checkUnstableAccessor(tree, accessor.symbol) | ||
accessor | ||
case _ => | ||
tree | ||
} | ||
|
@@ -179,6 +191,8 @@ object PrepareInlineable { | |
accessorInfo = abstractQualType(addQualType(dealiasMap(accessedType))), | ||
accessed = accessed) | ||
|
||
checkUnstableAccessor(tree, accessor) | ||
|
||
val (leadingTypeArgs, otherArgss) = splitArgs(argss) | ||
val argss1 = joinArgs( | ||
localRefs.map(TypeTree(_)) ++ leadingTypeArgs, // TODO: pass type parameters in two sections? | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we instead have a refcheck to enforce that overrides have the annotation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the SIP we ended up with
We should follow this or amend this detail in the SIP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm,
allOverriddenSymbols
might be expensive and no other annotations is inherited as far as I know, so I'd really prefer if we were more strict in the implementation (the sip is still experimental, so the implementation and spec don't need to exactly match yet)