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

Fix SI-8202 and improve support for splicing patterns into vals #3455

Merged
merged 4 commits into from Feb 16, 2014

Conversation

densh
Copy link
Contributor

@densh densh commented Feb 1, 2014

Fixes:

  • SI-8202 makes quasiquote parse q"val (x: Int) = 1" the same as q"val x: Int = 1"
  • Splicing of patterns into vals which was quite broken previously

review @xeno-by @retronym

@ghost ghost assigned xeno-by Feb 1, 2014
qname
else if (sym.name.toTermName == nme.ERROR)
s"<$qname: error>"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Used to NPE on me before the change.

Copy link
Member

Choose a reason for hiding this comment

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

Use sym.isErroneous instead

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That method is not available there.

Copy link
Member

Choose a reason for hiding this comment

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

What do you mean? It's reflect/internal/Printers.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Must have been a glitch, I've used it there and had compilation error. Not anymore.

@xeno-by
Copy link
Member

xeno-by commented Feb 2, 2014

Why not parse val (x: Int) = 1 as a type match pattern? There was also one JIRA issue updated recently that could be fixed by that.

@densh
Copy link
Contributor Author

densh commented Feb 2, 2014

@xeno-by I'd love to see that happen. But it looks like there are some concerns about change of behavior in existing code. We need to discuss it one of next week's meetings.

@xeno-by
Copy link
Member

xeno-by commented Feb 2, 2014

@densh What are the concerns? Could you comment? /cc @retronym @adriaanm

@densh
Copy link
Contributor Author

densh commented Feb 2, 2014

@retronym doesn't like the fact that code like:

val (x: Int) = 1

Will change meaning from 2.10 to 2.11 (compile-time check will become run-time check.) It will be 100% source compatible though and I doubt that anyone uses such a form anyway considering the fact that it's exactly the same as the one without parens atm.

@densh
Copy link
Contributor Author

densh commented Feb 5, 2014

ping @xeno-by

@xeno-by
Copy link
Member

xeno-by commented Feb 6, 2014

What are the performance implications of this pull request?

@densh
Copy link
Contributor Author

densh commented Feb 6, 2014

After discussion today the conclusion was that the behavior of val (x: T) = ... will not change in 2.11 but should be discussed again in 2.12 cycle. Therefore fix that breaks quasiquotes to be broken in the same way as the parser is appropriate here.

@adriaanm
Copy link
Contributor

adriaanm commented Feb 6, 2014

Thinking about it some more, it seems we can likely just fix this in 2.12 outright, ideally with an opt-in warning that lets users detect where their program is affected. (As part of the style/lint checker)

@adriaanm
Copy link
Contributor

adriaanm commented Feb 6, 2014

(Where "this" is consistent interpretation of tuple patterns in val and for)

@densh
Copy link
Contributor Author

densh commented Feb 6, 2014

@xeno-by what kind of performance are you talking about? Runtime isn't affected in any way. Compile-time of the quasiquote will perform implodePatDefs transform on every parsed tree.

@xeno-by
Copy link
Member

xeno-by commented Feb 6, 2014

@densh I see. Thanks

@densh
Copy link
Contributor Author

densh commented Feb 7, 2014

@adriaanm Sounds good. Looking forward too it.

Previously construction logic used to be in Parsers and deconstruction in
Placeholders making it easy to forget one if you change the other.
Also use sym.isErrorneous instead of manual name check.
This commits adds construction-only support for splicing patterns into
vals (a.k.a. PatDef). Due to non-locality of the desugaring it would
have been quite expensive to support deconstruction as the only way to
do it with current trees is to perform implodePatDefs transformation on
every single tree.
@densh
Copy link
Contributor Author

densh commented Feb 9, 2014

@xeno-by Just rebased and added some extra tests to support q"val $pat: $tpt = $rhs" case and minor refactoring of placeholders.

@adriaanm adriaanm modified the milestones: 2.12.0-M1, 2.11.0-RC1 Feb 10, 2014
@densh
Copy link
Contributor Author

densh commented Feb 13, 2014

ping @xeno-by, please merge early to prevent rebasing issues with reflection pr

@retronym
Copy link
Member

LGTM

xeno-by added a commit that referenced this pull request Feb 16, 2014
Fix SI-8202 and improve support for splicing patterns into vals
@xeno-by xeno-by merged commit b0ac4da into scala:master Feb 16, 2014
@adriaanm adriaanm added the 2.12 label Oct 29, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants