Skip to content

Do not set/reset flags that are part of FromStartFlags/AfterLoadFlags #4202

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
Merged
merged 2 commits into from
Mar 30, 2018
Merged

Do not set/reset flags that are part of FromStartFlags/AfterLoadFlags #4202

merged 2 commits into from
Mar 30, 2018

Conversation

smarter
Copy link
Member

@smarter smarter commented Mar 27, 2018

No description provided.

@smarter
Copy link
Member Author

smarter commented Mar 27, 2018

@sjrd Do you remember the context around 0ebf36b ? It's problematic because Mutable is currently a FromStartFlags so it should never be set/reset after creation. I assume this was used in the Scala.js backend but could be replaced by a more indirect check like if (sym.isSetter and sym.is(Scala2x)).

@smarter
Copy link
Member Author

smarter commented Mar 27, 2018 •
edited
Loading

Ah, but 0ebf36b happens in a treetransformer, so whether or not Mutable is FromStartFlags does not make a difference here I think.

Here are the remaining flag mutations I believe are problematic but didn't know how to fix:

The following are also problematic but are only used to do error recovery so maybe ok (EDIT: decided they were indeed ok):

@smarter smarter requested a review from odersky March 27, 2018 20:07
@smarter smarter changed the title Do not set/reset flags that are part of FromStartFlags Do not set/reset flags that are part of FromStartFlags/AfterLoadFlags Mar 27, 2018
@smarter smarter force-pushed the fix/FromStart-flags branch from b2816d3 to 2a71214 Compare March 27, 2018 20:13
@sjrd
Copy link
Member

sjrd commented Mar 27, 2018

Do you remember the context around 0ebf36b ?

Yes, the context was indeed to simplify the work of the Scala.js back-end, because in the IR it is absolutely forbidden to mutate a val outside of a constructor. Note that it is also forbidden in Java 9's bytecode format, so you probably don't want to regress about this. scalac has somewhere an issue where they're trying to fix this going forward, I think.

Using an indirect test would be fine too, as long as it's reliable. But then you'll need to tell -Ycheck that mutating a mixed-in val from a Scala2 trait is OK too (or at least, I hope you need to tell that to -Ycheck, otherwise it would mean that -Ycheck is letting through invalid assignments).

odersky
odersky approved these changes Mar 29, 2018
View reviewed changes
compiler/src/dotty/tools/dotc/core/Flags.scala Outdated
@@ -454,17 +454,18 @@ object Flags {
/** Flags representing access rights */
final val AccessFlags = Private | Protected | Local

/** Flags guaranteed to be set upon symbol creation */
/** Flags that are not (re)set when completing the denotation */
Copy link
Contributor

Choose a reason for hiding this comment

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

I think both the old and the new comment are useful. Can we combine them?

Copy link
Member Author

@smarter smarter Mar 29, 2018 •
edited
Loading

Choose a reason for hiding this comment

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

I think the old comment is misleading. These flags are not guaranteed to be set upon symbol creation, as can be witnessed by them appearing in setFlag/resetFlag calls in various places. I think that correctness only requires them to not appear in completers and InfoTransformers, but they're free to appear in other places such as TreeTransformers (e.g, the setFlag(Mutable) in Memoize I mentioned above).

compiler/src/dotty/tools/dotc/core/Flags.scala Outdated
/** Flags guaranteed to be set upon symbol creation, or, if symbol is a top-level
* class or object, when the class file defining the symbol is loaded (which
* is generally before the symbol is completed
/** Flags that are not (re)set when completing the denotation, or, if symbol is
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here

@smarter smarter force-pushed the fix/FromStart-flags branch 2 times, most recently from fde700c to 228678b Compare March 29, 2018 17:42
smarter added 2 commits March 29, 2018 23:49
@smarter
TreeUnpickler: Don't set Method flag late
3567d30 
Method is part of FromStartFlags
@smarter
Fix pickling of param setters
94a3cf2 
We now explicitly pickle the fact that they're param setters so that we
can set the flag ParamAccessor at symbol creation, this is necessary
because ParamAccessor is a FromStarts flag.

Since this change isn't binary-compatible, bump TASTY to 6.0.
@smarter smarter force-pushed the fix/FromStart-flags branch from 228678b to 94a3cf2 Compare March 29, 2018 21:50
@smarter smarter mentioned this pull request Mar 29, 2018
Open
3 tasks
@smarter
Copy link
Member Author

smarter commented Mar 29, 2018

I've opened #4221 to follow-up on the remaining issues.

@smarter smarter merged commit 944b892 into scala:master Mar 30, 2018
@allanrenucci allanrenucci deleted the fix/FromStart-flags branch March 30, 2018 07:09
@smarter smarter mentioned this pull request Apr 5, 2018
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@odersky odersky odersky approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@smarter @sjrd @odersky