Skip to content

Merge 2.12 to 2.13#5850

Merged
lrytz merged 5 commits intoscala:2.13.xfrom
lrytz:merge-2.12-to-2.13-apr-13
Apr 13, 2017
Merged

Merge 2.12 to 2.13#5850
lrytz merged 5 commits intoscala:2.13.xfrom
lrytz:merge-2.12-to-2.13-apr-13

Conversation

@lrytz
Copy link
Copy Markdown
Member

@lrytz lrytz commented Apr 13, 2017

> git fetch upstream -f
> git checkout -b merge-2.12-to-2.13-apr-13
Switched to a new branch 'merge-2.12-to-2.13-apr-13'
> git lg -n 1 | cat
*   6f0f1624d0 - (HEAD -> merge-2.12-to-2.13-apr-13, upstream/2.13.x, 2.13.x) Merge pull request #5849 from lrytz/partest-1.1.1 (2 minutes ago) <Lukas Rytz>
> export mb=$(git merge-base upstream/2.12.x 2.13.x)
> git log --graph --oneline --decorate $mb..upstream/2.12.x | cat
*   21d12e9f5e (upstream/2.12.x) Merge pull request #5845 from adriaanm/t10261
|\
| * 747e223223 Actually retract clashing synthetic apply/unapply
|/
* 12c240d69b Merge pull request #5844 from adriaanm/rework-5816
* 2804c6316e Revert some of ade53a123. Use completer factory methods.
> git merge upstream/2.12.x

No conflicts

adriaanm and others added 5 commits April 11, 2017 11:05
Scalameta et al need to be able to customize the
type completer behavior, so we must use factory methods
to instantiate them, rather than instantiating the classes
directly.
Revert some of ade53a1. Use completer factory methods.
The completer set the IS_ERROR flag and I assumed the typer
dropped a synthetic tree with a symbol with that flag, because
the tree was not shown in -Xprint output.

It turns out, as explained by lrytz, that the mechanism was
fragile because it relied on the order in which completers are
run. We now cover both the case that:

  - the completer was run (and the `IS_ERROR` flag was set)
  before `addSynthetics` in `typedStat` iterates over the scope
  (since the symbol is already unlinked, the tree is not added,
  irrespective of its flags). For this case, we also remove the
  symbol from the synthetics in its unit.
  - the completer is triggered during the iteration in `addSynthetics`,
  which needs the check for the `IS_ERROR` flag during the iteration.

Thankfully, the community build caught my mistake, and lrytz provided
a good analysis and review.

Fix scala/bug#10261
Actually retract clashing synthetic apply/unapply
@scala-jenkins scala-jenkins added this to the 2.13.0-M2 milestone Apr 13, 2017
@lrytz lrytz requested a review from SethTisue April 13, 2017 11:06
@lrytz
Copy link
Copy Markdown
Member Author

lrytz commented Apr 13, 2017

Merging so I can test the release process.

@lrytz lrytz merged commit 97319fb into scala:2.13.x Apr 13, 2017
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.

4 participants