From 77917e94c70759602be0dae833e798e894999254 Mon Sep 17 00:00:00 2001 From: Adriaan Moors Date: Wed, 12 Apr 2017 11:31:54 -0700 Subject: Actually retract clashing synthetic apply/unapply [backport] Also make this whole retraction of apply/unapply in case of a clashing user-defined member conditional on `-Xsource:2.12`. It turns out, as explained by lrytz, that the retraction 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, the `IS_ERROR` flag was set, and the symbol was unlinked from its scope 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 (for cleanliness). - the completer is triggered during the iteration in `addSynthetics`, which needs the check for the `IS_ERROR` flag during the iteration. Before, the completer just unlinked the symbol and 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. In reality, the completer just always happened to run before the addSynthetics loop and unlinked the symbol from its scope in the test cases I came up with (including the 2.11 community build). Thankfully, the 2.12 community build caught my mistake, and lrytz provided a good analysis and review. Fix scala/bug#10261 --- test/files/neg/userdefined_apply.flags | 1 + 1 file changed, 1 insertion(+) create mode 100644 test/files/neg/userdefined_apply.flags (limited to 'test/files/neg/userdefined_apply.flags') diff --git a/test/files/neg/userdefined_apply.flags b/test/files/neg/userdefined_apply.flags new file mode 100644 index 0000000000..0acce1e7ce --- /dev/null +++ b/test/files/neg/userdefined_apply.flags @@ -0,0 +1 @@ +-Xsource:2.12 -- cgit v1.2.3