prevents some reflection APIs from destroying rangeposes

This commit continues the work started in fcb3932b32.

As we've figured out the hard way, exposing internally maintained trees
(e.g. macro application) to the user is dangerous, because they can mutate
the trees in place using one of the public APIs, potentially corrupting our
internal state.

Therefore, at some point we started duplicating everything that comes from the user
and goes back to the user. This was generally a good idea due to the reason
described above, but there was a problem that we didn't foresee - the problem
of corrupted positions.

It turns out that Tree.duplicate focuses positions in the tree being processed,
turning range positions into offset ones, and that makes it impossible for macro
users to make use of precise position information.

I also went through the calls to Tree.duplicate to see what can be done
to them. In cases when corruptions could happen, I tried to replace duplicate
with duplicateAndKeepPositions.

Some notes:

1) Tree rehashing performed in TreeGen uses duplicates here and there
(e.g. in mkTemplate or in mkFor), which means that if one deconstructs
a macro argument and then constructs it back, some of the positions in
synthetic trees might become inaccurate. That's a general problem with
synthetic trees though, so I don't think it should be addressed here.

2) TypeTree.copyAttrs does duplication of originals, which means that
even duplicateAndKeepPositions will adversely affect positions of certain
publicly accessible parts of type trees. I'm really scared to change this
though, because who knows who can use this invariant.

3) Some methods that can be reached from the public API (Tree.substituteXXX,
c.reifyXXX, c.untypecheck, ...) do duplicate internally, but that shouldn't be
a big problem for us, because nothing is irreversibly corrupted here.
It's the user's choice to call those methods (unlike with TypeTree.copyAttrs)
and, if necessary, they can fixup the positions themselves afterwards.

4) Macro engine internals (macro impl binding creation, exploratory typechecking
in typedMacroBody) use duplicate, but these aren't supposed to be seen by the user,
so this shouldn't be a problem.

5) Certain parser functions, member syntheses and typer desugarings also duplicate,
but in those cases we aren't talking about taking user trees and screwing them up,
but rather about emitting potentially imprecise positions in the first place.
Hence this commit isn't the right place to address these potential issues.

1 files changed, 1 insertions, 0 deletions

diff --git a/test/files/run/macro-rangepos-subpatterns.flags b/test/files/run/macro-rangepos-subpatterns.flags
new file mode 100644
index 0000000000..fcf951d907
--- /dev/null
+++ b/test/files/run/macro-rangepos-subpatterns.flags
@@ -0,0 +1 @@
+-Yrangepos
\ No newline at end of file