| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
Fix broken 'Symbol-handling code in CleanUp
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Looks like the transformation did never happen because the pattern
failed to match. Why did the pattern fail to match? Because the
Symbol.apply we see in the tree claims to be a method while
Symbol_apply defined in Definitions wants to be a value.
This issue was caused because nonPrivateMember starts spitting out
overloaded symbols after erasure.
This issue has been fixed in the earlier commit, so what happens in
this commit is adding tests and fixing documentation.
|
| |\ \
| | |
| | | |
Issue/si 4287
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Default arguments are always retained on the <init> method (i.e.,
the class' constructor). Therefore, when the <init> parameters are
created, we need to use `duplicateAndKeepPositions` to make sure that
if a default argument is present, its opaque position is retained as
well. This is necessary because when parameter accessors (i.e.,
`fieldDefs`) are created, all default arguments are discared ( as you
can see in the code, the right-hand-side of a `field` is always an
`EmptyTree`) - see changes in TreeGen.scala
* When constructing the `fieldDefs`, it is important to adapt their
range position to avoid overlappings with the positions of default
arguments. It is worth noting that updating the field's end position
to `vd.rhs.pos.start` would be incorrect, because `askTypeAt(pos)`
could return the incorrect tree when the position is equal to
`vd.rhs.pos.start` (because two nodes including that point position
would exist in the tree, and `CompilerControl.locateTree(pos)` would
return the first tree that includes the passed `pos`). This is why
`1` is subtracted to `vd.rhs.pos.start`. Alternatively, we could have
used `vd.tpt.pos.end` with similar results. However the logic would
have become slightly more complex as we would need to handle the case
where `vd.tpt` doesn't have a range position (for instance, this can
happen if `-Yinfer-argument-types` is enabled). Therefore, subtracting
`1` from `vd.rhs.pos.start` seemed the cleanest solution at the
moment. - see changes in TreeGen.scala.
* If the synthetic constructor contains trees with an opaque range
position (see point above), it must have a transparent position.
This can only happen if the constructor's parameters' positions are
considered, which is why we are now passing `vparamss1` to
`wrappingPos` - see changes in TreeGen.scala.
* The derived primary constructor should have a transparent position
as it may contain trees with an opaque range position. Hence, the
`primaryCtor` position is considered for computing the position of the
derived constructor - see change in Typers.scala.
Finally, below follows the printing of the tree for test t4287, which
you should compare with the one attached with the previous commit
message:
```
[[syntax trees at end of typer]] // Foo.scala
[0:63]package [0:0]<empty> {
[0:37]class Baz extends [9:37][39]scala.AnyRef {
[10:20]<paramaccessor> private[this] val f: [14]Int = _;
[14]<stable> <accessor> <paramaccessor> def f: [14]Int = [14][14]Baz.this.f;
<10:31>def <init>(<10:31>f: [17]<type: [17]scala.Int> = [23:31]B.a): [9]Baz = <10:31>{
<10:31><10:31><10:31>Baz.super.<init>();
<10:31>()
}
};
[6]<synthetic> object Baz extends [6][6]AnyRef {
[6]def <init>(): [9]Baz.type = [6]{
[6][6][6]Baz.super.<init>();
[9]()
};
[14]<synthetic> def <init>$default$1: [14]Int = [30]B.a
};
[39:63]object B extends [48:63][63]scala.AnyRef {
[63]def <init>(): [48]B.type = [63]{
[63][63][63]B.super.<init>();
[48]()
};
[52:61]private[this] val a: [56]Int = [60:61]2;
[56]<stable> <accessor> def a: [56]Int = [56][56]B.this.a
}
}
```
You should notice that the default arg of `Baz` constructor now has a
range position. And that explains why the associated test now returns
the right tree when asking hyperlinking at the location of the default
argument.
|
| |\ \ \
| | | |
| | | | |
new hooks in AnalyzerPlugins to enable macro experimentation
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Interestingly enough, despite of the implementation surface being
quite noticeable, it is enough to hijack just `enterSym` and typechecking
of stats for packages, templates and blocks in order to enable macro annotations.
That and `ensureCompanionObject`, which I couldn't abstract away so far.
An architectural note: given that a hooked method is called `X`,
there are two implementations of this method. `pluginsX` is defined in
AnalyzerPlugins.scala and lets macro plugins customize `X`.
`standardX` is defined next to `X` and provides a default implementation.
Finally `X` is changed to trivially forward to `pluginsX`.
Existing and future callers of `X` now can be completely oblivious of the
introduced hooks, because calls to `X` will continue working and will be
correctly hooked. This makes the infrastructure more robust.
The only downside is that in case when a macro plugin wants to call
into the default implementation, it needs to call `standardX`, because
`X` will lead to a stack overflow. However, in my opinion this not a big
problem, because such failures are load and clear + for every `pluginsX`
we actually provide documentation that says what is its standard impl is.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is the first of two commits that enable hooks necessary to implement
macro annotations in an honest, hackless compiler plugin.
This particular commit turns certain helpers into public methods. Of course,
there is a probability that with the evolution of macro paradise, I will need
more helper methods, and those will have to be called via reflection, but
at least for now it's nice to have a reflection-less plugin :)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Back then, when we needed separate macro expanders for both applications
and unapplications, it made sense to have two different methods that
do macro expansions.
However, after @paulp’s upgrade of the pattern matching engine, we no longer
need a dedicated expander for unapply, so I’m removing it and renaming
`macroExpandApply` to just `macroExpand`.
|
| |\ \ \ \
| | | | |
| | | | | |
Improved testing framework for sets and maps.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Switched to JUnit testing framework for sets and maps. They now test
broadly against each other for consistency. Tests for mutable.AnyRefMap
and mutable.LongMap are folded in here (originals removed). There is still
lots of redundancy with other tests that has not been removed.
This framework is also designed to enable more robust testing of changes to
implementations of sets and maps; although it's still quite possible to get
a broken implementation through, these tests should make it harder to get
the fundamentals wrong.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
awakens default getter synthesis from the untyper nightmare
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Our happy little macro paradise is regularly invaded by resetAllAttrs,
the bane of all macros and typers. It’s so ruthless and devastating that
we’ve been long scheming to hack something really cool and to one day
defeat it.
Today we make the first step towards the happy future. Today we overthrow
the UnTyper, resetAllAttrs’s elder brother that rules in the kingdoms of
GetterLand and CaseClassia, and banish him from the land of getters.
In the name of what’s good and meta, let’s band together and completely
drive him away in a subsequent pull request!
To put it in a nutshell, instead of using untyper on a DefDef to do
default getter synthesis, the commit duplicates the DefDef and does
resetLocalAttrs on it.
As default getter synthesis proceeds with figuring out type and value
parameters for the getter, then its tpt and finally its rhs, the commit
destructures the duplicated DefDef and then assembles the default getter
from the destructured parts instead of doing copyUntyped/copyUntypedInvariant
on the original DefDef.
I would say the test coverage is pretty good, as I had to figure out
3 or 4 test failures before I got to the stage when everything worked.
Iirc it tests pretty exotic stuff like polymorphic default parameters
in both second and third parameter lists, so it looks like we're pretty
good in this department.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-7880 Fix infinite loop in ResizableArray#ensureSize
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This issue was triggered for values greater than Int.MaxValue/2, which
caused the computation of the new array size to overflow and become
negative, leading to an infinite loop.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-8047 change fresh name encoding in quasiquotes to avoid symbol owner corruption
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Previously a following encoding was used to represent fresh
names that should be created at runtime of the quasiquote:
build.withFreshTermName(prefix1) { name$1 =>
...
build.withFreshTermName(prefixN) { name$N =>
tree
}
...
}
It turned out that this encoding causes symbol corruption when
tree defines symbols of its own. After being spliced into anonymous
functions, the owner chain of those symbols will become corrupted.
Now a simpler and probably better performing alternative is
used instead:
{
val name$1 = universe.build.freshTermName(prefix1)
...
val name$N = universe.build.freshTermName(prefixN)
tree
}
Here owner stays the same and doesn’t need any adjustment.
|
| |\ \ \ \ \ \ \
| |_|_|_|_|_|/
|/| | | | | | |
typeCheck => typecheck
|
| | |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This method has always been slightly bothering me, so I was really glad
when Denys asked me to rename it. Let’s see how it pans out.
|
| |\ \ \ \ \ \
| |_|_|_|/ /
|/| | | | | |
crasher with specialized lazy val
|
| | | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This reverts a tiny bit of f7d5f45aa7 where the crasher was
introduced. The enclosed test case compiles and runs under 2.9,
but prints the wrong answer. It crashes in 2.10 and until this
patch. Now it compiles and prints the right answer.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
makes boxity of fast track macros configurable
|
| | | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Previously, all built-in macros were assumed to be whitebox, but that’s
actually not the case. Just quasiquote macros have to be whitebox, while
the rest can be blackbox.
This also fixes SI-8091, because blackbox macros are typechecked differently
and therefore the necessary implicit conversion kicks in. If `f”...”` were
to remain a whitebox macro, then due to the changes introduced in commit
https://github.com/scala/scala/commit/a3b33419b02cafb7e2c6fed6dd96151859fc7d77
we would have to explicitly ascribe its expansion as String to achieve the same effect.
After I made reify blackbox, several tests had to be changed, because
we now explicitly ascribe the expansion with `c.Expr[T]`, which changes `toString`.
Also, a number of less obvious corrections had to be applied, because
things like `reify(<constant>).splice` have stopped being optimized away
due to `reify(<constant>)` no longer having a narrow `c.Expr[<constant>.type]`,
making it ineligible for constant folding.
Moreover, this change forced me to adjust our approach to positioning
blackbox wrappings, because after being changed to blacbox and starting using
wrappings, f”...” interpolators used in the compiler started crashing
-Yrangepos builds. Now wrapping Typed nodes are assigned with transparent
positions.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-7777 SI-8006 assorted fixes for dynamics
|
| | | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Interplay between the insertApply desugaring and the invokeDynamic desugarings
is already quite brittle, but the real fun begins when macros crash the party.
The proposed patch enriches the `isDesugaredApply` check performed in
`mkInvoke`, the invokeDynamic desugarer, and makes sure that everything
is safe and sound in the macroland.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
(master) codifies the state of the art wrt SI-8104
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As it was discovered in SI-8104, whiteboxity doesn’t apply equally to
type parameters and type members of materialized type classes.
During implicit search and subsequent type inference, whitebox type parameters
are consistently erased to wildcards, whereas whitebox type members sometimes
remain as is and get in the way of signature conformance checks.
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As our discussion at https://issues.scala-lang.org/browse/SI-6355 shows,
it looks like it is possible to overload applyDynamic, even though a
straightforward way is closed. This commit codifies the pattern proposed
by @paulp and makes sure that it doesn’t break in the future.
|
| |\ \ \ \
| |/ / /
|/| | | |
SI-8017 Value class awareness for -Ydelamdafy:method
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The delambdafy creates a bridge method which requires adaptation
of the result type to the generic `Object`, which is the erased
return type of FunctionN.
This bridge building reused some code from erasure, now refactored
into TypeAdaptingTransformer.
But, it was running into problems with:
class C(a: Int) extends AnyVal
(x: Any) => new C(0)
It created (forgive the pseudo quasiquote syntax):
class anonfun$ extends Function1[Any, C] {
def apply#1(a: Object): Int = 0
<bridge> def apply#2(a: Object): Object = {
val result: Int = apply#1(a)
${adapt(Ident("result"), ObjectType)}
}
}
This resulted in primitive boxing, rather than value class boxing.
Instead, we need the call to the main apply method to be typed
as `ErasedValueClass(C, Int)`, which `adapt` takes as a trigger
to perform value class boxing.
Finally, we have to run the post-erasure transformer over the adapted
tree to eliminate remnants of `ErasedValueClass` from the types of
trees.
|
| |\ \ \ \
| | | | |
| | | | | |
(2.11.0-M8) whitebox macros are now first typechecked against outerPt
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Even though whitebox macros are supposed to be used to produce expansions
that refine advertised return types of their macro definitions, sometimes
those more precise types aren’t picked up by the typechecker.
It all started with Travis generating structural types with macros
and noticing that typer needs an extra nudge in order to make generated
members accessible to the outside world. I didn’t understand the mechanism
of the phenomenon back then, and after some time I just gave up.
Afterwards, when this issue had been brought up again in a different
StackOverflow question, we discussed it at reflection meeting, figured out
that typedBlock provides some special treatment to anonymous classes,
and it became clear that the first macro typecheck (the one that types
the expansion against the return type of the corresponding macro def)
is at fault here.
The thing is that if we have a block that stands for a desugard anonymous
class instantiation, and we typecheck it with expected type different from
WildcardType, then typer isn’t going to include decls of the anonymous class
in the resulting structural type: https://github.com/scala/scala/blob/master/src/compiler/scala/tools/nsc/typechecker/Typers.scala#L2350.
I tried to figure it out at https://groups.google.com/forum/#!topic/scala-internals/eXQt-BPm4i8,
but couldn’t dispel the mystery, so again I just gave up.
But today I had a profound WAT experience that finally tipped the scales.
It turns out that if we typecheck an if, providing a suitable pt, then
the resulting type of an if is going to be that pt, even though the lub
of the branch types might be more precise. I’m sure that reasons for this
behavior are also beyond my understanding, so I decided to sidestep this problem.
upd. Here’s Jason’s clarification: Doing thing differently would require
us to believe that "'Tis better to have lubbed and lost than never to have
lubbed at all." But the desire for efficiency trumps such sentimentality.
Now expansions of whitebox macros are first typechecked against outerPt,
the expected type that comes from the enclosing context, before being
typechecked against innerPt, the expected type that comes from the return
type of the macro def. This means that now outerPt provides the correct
expected type for the initial, most important typecheck, which makes
types more precise.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The continuations plugin and library will still ship with 2.11 (albeit unsupported).
They now reside at https://github.com/scala/scala-continuations.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-7618 Remove octal number literals
|
| | | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | | |
This also fixes a spurious detection of octal literals in floating
point literals: Literals like 01.23 are neither deprecated nor planned
for removal.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-8059 Override immutable.Queue#{+:,:+} for performance
|
| | | |/ / /
| |/| | |
| | | | |
| | | | | |
Without those overrides, all elements are unnecessarily copied.
|
| |\ \ \ \ \
| |_|_|_|/
|/| | | | |
Merge 2.10.x to master
|
| | |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
build.examples.xml
build.xml
docs/examples/actors/pingpong.scala
docs/examples/fors.scala
docs/examples/iterators.scala
docs/examples/jolib/Ref.scala
docs/examples/jolib/parallelOr.scala
docs/examples/monads/callccInterpreter.scala
docs/examples/monads/directInterpreter.scala
docs/examples/monads/errorInterpreter.scala
docs/examples/monads/simpleInterpreter.scala
docs/examples/monads/stateInterpreter.scala
docs/examples/parsing/ArithmeticParser.scala
docs/examples/patterns.scala
docs/examples/pilib/elasticBuffer.scala
docs/examples/pilib/handover.scala
docs/examples/pilib/piNat.scala
docs/examples/typeinf.scala
src/build/pack.xml
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Otherwise, objects with exception-throwing `toString` lead to a
cascading error far removed from the originally failed match.
|
| | |\| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
bincompat-forward.whitelist.conf
src/interactive/scala/tools/nsc/interactive/Global.scala
test/files/presentation/scope-completion-2.check
test/files/presentation/scope-completion-3.check
test/files/presentation/scope-completion-import.check
Conflicts in the scope completion tests handled with the help
of @skyluc in https://github.com/scala/scala/pull/3264
|
| | | |\ \ \ \
| | | | | | |
| | | | | | | |
SI-8029 Avoid multi-run cyclic error with companions, package object
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The bug report suggests this problem only became visible in the
IDE *after* 2.10.3, but I tested an IDE with exactly 2.10.3 and
saw the same problem.
In fact, my test case fails as far back as 2.10.0. I suspect the
problem showed up after 816cecf9a9, which checks that pairs of
companion symbols are codefined eagerly in Namers.
This commit modifies the check of `rawInfo ne NoType`
in `isCoDefinedWith` to avoid triggering adaptation of types from
the previous run. I'm not sure of the precise intent of that check.
I looked at c9861cd198 (genesis of isCoDefinedWith). Before that we
get back to 3761cb4b3a1 (the dawn of Subversion.)
|
| | | |\ \ \ \ \
| | | | | | | |
| | | | | | | | |
[backport] SI-7439 Avoid NPE in `isMonomorphicType` with stub symbols.
|
| | | | |/ / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
`originalInfo` can return null for stub symbols; deal with that
as we used to before a regression in 016bc3db.
After this change, we can once again delete A_1.class and still compile
code instantiating B_1. (A_1 is only referred to in a method signature
of B_1 which is not called from our code.)
scala> new B_1
warning: Class A_1 not found - continuing with a stub.
res0: B_1 = B_1@5284b8f9
In practice, this situation arises when someone uses a third
party class that was compiled against other libraries not avaialable
on the current compilation classpath.
(cherry picked from commit a95432168204964e4f6c4571e781559c1640f2d8)
|
| | |\| | | | |
| | |_|/ / /
| |/| | | |
| | | | | |
| | | | | | |
Conflicts:
src/compiler/scala/tools/nsc/transform/Erasure.scala
|
| | | |/ / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Calls to `Symbol#info` during scope iteration considered harmful.
Looks like calling `info` during this Scope iteration is triggering
the ExplicitOuter info transformer, which "makes all super accessors
and modules in traits non-private, mangling their names.". This name
change necessitates a rehashing of the owning scope, which I suspect
is enough to corrupt the ScopeEntry-s being traversed in
`checkNoDeclaredDoubleDefs`.
The upshot was that we encountered the same symbol twice, which was
reported as being a double-definition.
This problem only showed up after 086702d8a74, which did nothing
worse then change the order in which `{e, e1}.sym.info` were
forced.
I inspected SymbolPairs/OverridingPairs which *appear* to be immune
as they only test flags during scope iteration; infos are not used
until later, at which point we're iterating a temporary scope that
isn't part of the type of the owner of the symbols.
|
| | | |\ \ \
| | | | | |
| | | | | | |
teaches toolbox about -Yrangepos
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Unlike in master, in 2.10.x enabling -Yrangepos requires instantiating
Global with mixed in RangePositions trait.
Same story for toolboxes. Just setting Yrangepos is not enough - one
needs to mix in RangePositions into ToolboxGlobal. I didn’t know that
back then, so now I’m fixing the oversight.
The commit is marked as [nomaster], because -Yrangepos doesn’t need
special treatment in master.
|
| |\ \ \ \ \ \
| |_|_|_|_|/
|/| | | | | |
Plugins get a class path
|
