| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I noticed that the pos/5954d was tripping a println "assertion".
This stemmed from an inconsistency between
`TypeRef#{parents, baseTypeSeq}` for a package objects compiled
from source that also has a class file from a previous compilation
run.
I've elevated the println to a devWarning, and changed
`updatePosFlags`, the home of this evil symbol overwriting,
to invalidate the caches in the symbols info. Yuck.
I believe that this symptom is peculiar to package objects because
of the way that the completer for packages calls `parents` during
the Namer phase for package objects, before we switch the symbol
to represent the package-object-from-source. But it seems prudent
to defensively invalidate the caches for any symbol that finds its
way into `updatePosFlags`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tests cases enclosed exhibited two failures modes under
separate compilation.
1. When a synthetic companion object for a case- or implicit-class
defined in a package object is called for,
`Namer#ensureCompanionObject` is used to check for an explicitly
defined companion before decided to create a synthetic one.
This lookup of an existing companion symbol by `companionObjectOf`
would locate a symbol backed by a class file which was in the
scope of the enclosing package class. Furthermore, because the
owner of that symbol is the package object class that has now
been noted as corresponding to a source file in the current
run, the class-file backed module symbol is *also* deemed to
be from the current run. (This logic is in `Run#compiles`.)
Thinking the companion module already existed, no synthetic
module was created, which would lead to a crash in extension
methods, which needs to add methods to it.
2. In cases when the code explicitly contains the companion pair,
we still ran into problems in the backend whereby the class-file
based and source-file based symbols for the module ended up in
the same scope (of the package class). This tripped an assertion
in `Symbol#companionModule`.
We get into these problems because of the eager manner in which
class-file based package object are opened in `openPackageModule`.
The members of the module are copied into the scope of the enclosing
package:
scala> ScalaPackage.info.member(nme.List)
res0: $r#59116.intp#45094.global#28436.Symbol#29451 = value List#2462
scala> ScalaPackage.info.member(nme.PACKAGE).info.member(nme.List)
res1: $r#59116.intp#45094.global#28436.Symbol#29451 = value List#2462
This seems to require a two-pronged defense:
1. When we attach a pre-existing symbol for a package object symbol
to the tree of its new source, unlink the "forwarder" symbols
(its decls from the enclosing
package class.
2. In `Flatten`, in the spirit of `replaceSymbolInCurrentScope`,
remove static member modules from the scope of the enclosing
package object (aka `exitingFlatten(nestedModule.owner)`).
This commit also removes the warnings about defining companions
in package objects and converts those neg tests to pos (with
-Xfatal-warnings to prove they are warning free.)
Defining nested classes/objects in package objects still has
a drawback: you can't shift a class from the package to the
package object, or vice versa, in a binary compatible manner,
because of the `package$` prefix on the flattened name of
nested classes. For this reason, the `-Xlint` warning about
this remains. This issue is tracked as SI-4344.
However, if one heeds this warning and incrementatlly recompiles,
we no longer need to run into a DoubleDefinition error (which
was dressed up with a more specific diagnostic in SI-5760.)
The neg test case for that bug has been converted to a pos.
|
| |\
| |
| | |
Presentation compiler friendliness for macros
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The presentation compiler is primarily interested in trees that
represent the code that one sees in the IDE, not the expansion of
macros.
This commit continues to expand macros, but adds a hook in which
the presentation compiler discards the expansion, retaining instead
the expandee. The expandee is attributed with the type of the
expansion, which allows white box macros to work. In addition,
any domain specific errors and warnings issued by the macro will
still be reported, as a side-effect of the expansion.
The failing test from the last commit now correctly resolves
hyperlinks in macro arguments.
Related IDE ticket:
https://www.assembla.com/spaces/scala-ide/tickets/1001449#
This facility is configured as follows:
// expand macros as per normal
-Ymacro-expand:normal
// don't expand the macro, takes the place of -Ymacro-no-expand
-Ymacro-expand:none
// expand macros to compute type and emit warnings,
// but retain expandee. Set automatically be the presentation
// compiler
-Ymacro-expand:discard
This leaves to door ajar for a new option:
// Don't expand blackbox macros; expand whitebox
// but retain expandee
-Ymacro-expand:discard-whitebox-only
The existing test for SI-6812 has been duplicated. One copy exercises
the now-deprecated -Ymacro-no-expand, and the other uses the new
option.
|
| | |
| |
| |
| |
| | |
- Replace NoPosition with the focus of the macro application
- Focus all range positions, for example, those of spliced arguments
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Currently, the presentation compiler sees the expansion of macros;
this no longer contains the trees corresponding to the macro arguments,
and hyperlink requests result incorrect results.
https://www.assembla.com/spaces/scala-ide/tickets/1001449#
|
| |\ \
| | |
| | | |
ExistentialTypeTree.whereClauses are now MemberDefs
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Today’s flight back to Lausanne wasn’t as productive as the recent flight
to Minsk (https://github.com/scala/scala/pull/3305), but I noticed
one minor thingie: ExistentialTypeTree had an imprecise type specified
for its whereClauses. This is now fixed.
I didn’t increment PickleFormat.*Version numbers, because this change
introduces only a miniscule incompatibility with what would have been
a meaningless and most likely crash-inducing pickle anyway.
|
| |\ \ \
| | | |
| | | | |
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.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As demonstrated by the attached test, hyperlinking on constructor's
default arg doesn't work (the returned tree is the parameter tree,
i.e., `f`, which is of course wrong).
Printing the tree reveals the issue:
``
[[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:31]<paramaccessor> private[this] val f: [14]Int = _;
[14]<stable> <accessor> <paramaccessor> def f: [14]Int = [14][14]Baz.this.f;
[39]def <init>([14]f: [17]<type: [17]scala.Int> = [30]B.a): [9]Baz = [39]{
[39][39][39]Baz.super.<init>();
[9]()
}
};
[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
}
}
``
In short, the default argument in `<init>` (the constructor) has an
offset position, while we would expect it to have a range position.
Therefore, when locating a tree for any position between (start=) 10
and (end=) 31, the paramaccessor tree `f` is returned.
The next commit will correct the problem.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This test was inspired by `test/files/run/t5603`, whose output (.check file)
will need to be updated in the upcoming commit that fixes SI-4287, because
the positions associated to the tree have slightly changed.
The additional test should demonstrate that the change in positions isn't
relevant, and it doesn't affect functionality. In fact, hyperlinking to a
constructor's argument work as expected before and after fixing SI-4287.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Added test to the presentation compiler regression suite to exercise
hyperlinking on context bounds.
|
| |\ \ \ \
| | | | |
| | | | | |
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 :)
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Macro defs are linked to macro impls by the virtue of MacroImplBinding
structures that are persisted between compilation runs serialized within
instances of macroImpl annotations.
Along with the evolution of our macro engine, we sometimes have to evolve
the format of MacroImplBinding, which means that it has to be versioned.
Version mismatches are checked upon every macro expansion, ensuring that
macros that we expand were compiled with exactly the same version of the
macro engine that we’re running.
That’s all really cool apart from the fact that version mismatches result
in aborting the entire compilation with an obscure message without giving
a hint about the culprits.
This commit improves the situation by providing pretty per-expansion
compilation errors that tell the programmer what macro expansions are
at fault and what macro engines were used to compile them.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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`.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-8120 Avoid tree sharing when typechecking patmat anon functions
|
| | | |_|_|/
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When typechecking an empty selector `Match` corresponding to:
{ case ... => ... }: (A => B)
We wrap it in a `Function` and typecheck:
(x$1 => x$1 match { case ... => ... })
Local symbols in this expression (representing values bound by
the pattern, or just definitions in the body or guard) are then
owned by the anonymous function's symbol.
However, if we ever discard this `Function` and start anew with
the empty selector match, as happens during the fallback to
use a view on the receiver in `tryTypedApply`, we found that we
had mutated the cases of the original tree, and allowed orphaned
local symbols to escape into the compiler pipeline.
This commit uses duplicated trees for the the cases in the synthetic
`Match` to avoid this problem.
`duplicateAndKeepPositions` is used to preserve range positions;
without this scala-refactoring PrettyPrinterTest fails.
`Tree#duplicate` uses offset positions in the copied tree, which
is appropriate when both the original and the copy are going to end up
in the final tree.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Fix (postfix abs for -0.0)
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
SI-8102 points out that -0.0.abs returns -0.0 (in error). The same issue
exists for -0.0f. This commit fixes the issue for both by delegating to
math.abs.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
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.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Resolves SI-7837, failure in quickSort.
|
| | | |_|_|_|/
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
because the code uses '==' instead of 'equiv'
== instead of equiv (from Ordering) was used by mistake. Fixed.
Also created a test to make sure that == is not used by throwing an exception if it is (as suggested by Jason).
|
| |\ \ \ \ \ \
| |_|_|/ / /
|/| | | | | |
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-8052 Disallow `macro` as an identifier
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Note that the change could look a lot cleaner, at the cost of returning
more generic error messages. I decided that at least for 2.11 I'll keep
scalac remembering that macro was a standard identifier name once, so
that we can point out more precisely what's wrong with users' code.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
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.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
makes well-known packages and package classes consistent with each other
|
| | | |/ / / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
As discovered in https://groups.google.com/forum/#!topic/scala-user/RckXE90LoXo,
RootClass.sourceModule and EmptyPackageClass.sourceModule used to incorrectly
return NoSymbol instead of RootModule and EmptyPackage. This is now fixed.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-7777 SI-8006 assorted fixes for dynamics
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Since mkInvoke, the applyDynamic/selectDynamic/etc desugarer, is disconnected
from typedNamedApply, the applyDynamicNamed argument rewriter, the latter
doesn’t know whether it needs to apply the rewriting because the application
has just been desugared or it needs to hold on because it’s already performed
a desugaring on this tree.
This commit introduces the attachment that links these translation facilities,
preventing infinite applyDynamicNamed desugarings.
|
| | |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
