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
SI-8030 force symbols on presentation compiler initialization #3262
Conversation
|
||
implicit def implicitView: Option[Int] = None | ||
def implicitArg1(implicit i: Int) = i + 2 | ||
def implicitArg2[T: Fooable] = implicitly[Fooable[T]] |
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.
for more variations: view bounds, upper/lower bounds
@densh You forgot to commit |
@retronym Yeap, |
This commit forces a number of built-in symbols in presentation compiler to prevent them from being entered during parsing. The property “parsing doesn’t enter new symbols” is tested on a rich source file that contains significant number of variations of Scala syntax.
Just added |
LGTM |
SI-8030 force symbols on presentation compiler initialization
Set(UnitClass, BooleanClass, ByteClass, | ||
ShortClass, IntClass, LongClass, FloatClass, | ||
DoubleClass, NilModule, ListClass) ++ TupleClass.seq | ||
symbols.foreach(_.initialize) |
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.
@densh Sorry for being late to the party, but why isn't fullyInitializeSymbol
used in place of the simpler initialize
? @retronym suggested using fullyInitializeSymbol
in the related ticket (I'm inlining below his comment):
And I would change that to
fullyInitializeSymbol
to be on the safe side as you have the tuple class, module, and module class symbols to worry about.
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.
It doesn't really matter for the parser, which only needs to refer to the symbols, and doesn't trigger any computations that force the related symbols. The test case here shows this is sufficient.
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.
So, we should update https://github.com/scala-ide/scala-ide/pull/595/files. Thanks for clarifying.
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.
I don't think it does any harm to initialize the related symbols, though.
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.
Right. But keeping the two aligned will allow us to remove the ad-hoc initialization logic from our side once we drop 2.10 support.
This pull request forces a number of built-in symbols in presentation compiler to prevent them from being entered during parsing.
The property “parsing doesn’t enter new symbols” is tested on a rich source file that contains significant number of variations of Scala syntax.
review @retronym