| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
Fixes and features for javap (fixing SI-6894)
|
| | |
| |
| |
| | |
Knock on wood.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Output filtering is refactored for javap6.
That means javap6 also supports -raw.
Handling of # is: Foo#foo filter on foo,
Foo# filter on apply, -fun Foo#foo for anonfuns of foo,
-fun Foo# anonfuns filtering on apply.
One is loath to add command options, so it's not possible
to ask for "only apply methods in anonfuns pertaining to
a method." Hypothetical syntax to say "show me the
apply only": -fun Foo#foo(), for future reference.
|
| |\ \
| | |
| | | |
SI-6955 switch emission no longer foiled by type alias
|
| | |/
| |
| |
| |
| |
| |
| | |
dealiasWiden the type of the scrutinee before checking it's switchable
now with tests! (using IcodeTest since javap is not available everywhere)
rebase of #1879
|
| |\ \
| | |
| | | |
SI-6964 Remove build managers, both simple and refined.
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| | |
Deprecated in 2.10.0, out to pasture in 2.11.0.
Users are advised to migrate to:
https://github.com/typesafehub/zinc
http://www.scala-sbt.org/
|
| |\ \
| | |
| | | |
SI-6375, warn on lost annotation.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Annotations on abstract vals which are not meta-annotated
were silently discarded. Still discarded, only less silently.
I warned on as many "lost annotation" situations as I was
reasonably able to cover without false positives.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
There were some missing and some others not added to the
set of meta-annotations. I added the missing ones and
defined the set in such a way as to include them all, even
those which have not yet been born.
|
| |\ \ \
| | | |
| | | | |
SI-5189 detect unsoundness when inferring type of match
|
| | | | | |
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
GADT skolems encode type slack that results from pattern matching on variant type constructors
I thought they would not longer be relevant after cases have been typed,
and since they caused weird issues with the old pattern matcher, I deskolemized in typedCase
however, when we don't have an expected type for the match, we need to keep the skolems around
until the skolemized type makes it out of the match and it becomes the result of type inference for that match
when you do have an expected type, it will propagate to the case-level and the confrontation will thus
already take place when typing individual cases
|
| |\ \ \
| |/ /
|/| | |
SI-6966 Fix regression in implicit resolution
|
| | | |
| | |
| | |
| | |
| | | |
Reverts this line: 9c09c17#L50L671. That value was
apparantly discarded intentionally.
|
| |\ \ \
| | | |
| | | | |
Fix dependant => dependent
|
| | | | | |
|
| |\ \ \ \
| |_|/ /
|/| | | |
Remove EqualsPatternClass.
|
| |/ / /
| | |
| | |
| | |
| | | |
Detritus from the classic pattern matcher, which was recently
removed 6084d2d9.
|
| |\ \ \
| | | |
| | | | |
Resolving new merge conflicts between #1844 and master.
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* commit 'refs/pull/1844/head':
macroExpandAll is now triggered by typed
SI-5923 adapt macros when they are deferred
generalizes macroExpand
typedPrimaryConstrBody now returns supercall
more precise errors for macros
parentTypes => typedParentTypes
changes isTermMacro checks to something more universal
fixes printing of AppliedTypeTree
adds Trees.replace(Tree, Tree)
makes macro override error more consistent
refactors handling of macros in repl
SI-5903 extractor macros do work
adds c.macroRole
Conflicts:
src/compiler/scala/tools/nsc/typechecker/Macros.scala
src/compiler/scala/tools/nsc/typechecker/Typers.scala
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Previously delayed macro expansions (the sole purpose of macroExpandAll)
were triggered by `typedArgs`. Probably I wanted to save CPU cycles on
not checking whether we have pending macro expansions on every iteration
of typecheck.
However this optimization is uncalled for, because the check just entails
reading a var, therefore benefits of the current approach are negliible,
whereas the robustness hit is tangible.
After delayed macro expansion mechanism became more robust, it exposed
a bug, well-hidden before. If one first delays a macro and then finds out
that the expandee is erroneous, subsequent `macroExpandAll` will crash,
because it expects a macro runtime attachment to be present. Previously
the erroneous code path never got triggered, because the macro expansion
never commenced. Luckily the fix was easy.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Amazingly enough, the fix for the "macro not expanded" problem was super
easy. (And I remember spending a day or two trying to find a quick fix
somewhen around Scala Days 2012!)
The problem was in the implementation of the macro expansion trigger,
which was buried in a chain of if-elif-elif. This meant that macro
expansion was mutually exclusive with a lot of important adaptations, e.g.
with `instantiate`.
More precisely, if an expandee contains an undetparam, its expansion
should be delayed until all its undetparams are inferred and then retried
later. Sometimes such inference can only happen upon a call to instantiate
in one of the elif's coming after the macro expansion elif. However this
elif would never be called for expandees, because control flow would always
enter the macro expansion branch preceding the inference branch.
Consequences of this fix are vast. First of all, we can get rid of the
"type parameter must be specified" hack. Secondly and most importantly,
we can now remove the `materializeImplicit` method from Implicits and
rely on implicit macros to materialize tags for us. (This is a tricky
change, and I'll do it later after we merge as much of my pending work
as possible). Finally, we learn that the current scheme of interaction
between macros, type inference and implicits is, in principle, sound!
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Changes macroExpand to accommodate expansion schemes different from the
currently supported one.
As a bonus, which follows clarification of the macro expansion logic,
this refactoring fixes suppression of macro expansions, which
previously didn't work with delayed expansion.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Previously this method returned the entire block with supercall being
potentially wrapped in early defs.
However when implementing type macros, I found it more convenient to have
typedPrimaryConstrBody to only return the supercall itself. This doesn't
make any difference for our current codebase, since the only time anyone
cares about the return value, it's only to inspect its tpe.
Therefore I'm submitting this patch in a preparatory pull request to
reduce the surface of changes in the upcoming type macros pull request.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I felt really uncomfortable having to stare at `parentTypes`, when
everyone else in Typers.scala is named typedSomething.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Previously I wanted to be as precise as possible, but as the experience
with type macros shows, a lot of isTermMacro checks should also extend
to include type macros.
Therefore I'm changing the checks to isMacro. This doesn't make any
difference for existing code, but will reduce the amount of changes
in the upcoming type macro pull request.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Currently dead code. Has proven to be useful to implement type macros,
therefore I'm moving it to scala.reflect.internal.Trees.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Macros now have a dedicated member handler, so that the logic of their
processing doesn't get mixed up with vanilla DefHandler.
I've also factored out an abstract MacroHandler to provides a basis
to build the upcoming type macro handler upon.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Apparently it is already possible to use macros to customize pattern
matching as described in the comments to the aforementioned JIRA issue.
What's even better - with the incoming addition of c.introduceTopLevel
it becomes possible to generate arbitrarily complex unappliers, even
with heterogeneous types of arguments varying from expansion to expansion
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Currently there's only one flavor of macros - def macros, and the plan
was to gradually introduce additional flavors, such as type macros and
macro annotations.
However as shown by the experience with type macros, it makes sense
to distinguish subflavors of macros that tell us in which context the
macro gets expanded. For def macros we have the only role - expansion
of an application. But for type macros there are multiple.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
sbt-git-plugin has moved.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We need to eliminate these sort of shifting sands to make
the SBT build a viable option.
|
| |\ \ \ \ \ \
| |_|/ / / /
|/| | | | | |
SI-6641 Cull scala.swing.SwingWorker
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It appears to do nothing much at all, refers to the now-deprecated
scala.actor package, and has a name clash with an important class
from java.swing.
Note that the POM for scala-swing does not declare the dependency.
The final nail in the coffin is it aides and abets the crash in
the crash in SI-6440.
Attempts to remove or even deprecate this in 2.10.0 were
missed the boat.
This commit removes them for 2.11.0, in contravention of
the deprecation policy. Given that they rely on the
scala-actors module which _is_ deprecated in 2.10.0,
and will likely be removed in 2.11.0, I contend that
this is a reasonable exception.
Actor.scala
|
| |\ \ \ \ \
| |_|_|_|/
|/| | | | |
Made "mode" into a value class.
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is an obvious place to apply value class goodness and
collect some safety/sanity in typing modes. It does show off
a challenge in introducing value classes without disruption:
there's no way to deprecate the old signature of 'typed',
'adapt', etc. because they erase the same.
class Bippy(val x: Int) extends AnyVal
class A {
@deprecated("Use a bippy") def f(x: Int): Int = 5
def f(x: Bippy): Int = x.x
}
./a.scala:5: error: double definition:
method f:(x: Bippy)Int and
method f:(x: Int)Int at line 4
have same type after erasure: (x: Int)Int
An Int => Mode implicit handles most uses, but nothing can
be done to avoid breaking anything which e.g. extends Typer
and overrides typed.
|
| |\ \ \ \
| | | | |
| | | | | |
Moved repl javap tests into pending.
|
| |/ / / /
| | | |
| | | |
| | | | |
For not passing on java6.
|
| |\ \ \ \
| | | | |
| | | | | |
a painstaking examination of Variance
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As the comment says:
Not enough to look for abstract types; have to recursively check
the bounds of each abstract type for more abstract types. Almost
certainly there are other exploitable type soundness bugs which
can be seen by bounding a type parameter by an abstract type which
itself is bounded by an abstract type.
SPECIAL: BUY ONE UNSOUNDNESS, GET ONE FREE
In refinement types, only the first parameter list of methods
was being analyzed for unsound uses of abstract types. Second
parameter list and beyond had free unsoundness reign. That bug
as well is fixed here.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This wasn't as bad as it could have been. All these changes
plug soundness holes in trunk. Mostly we're looking at type
aliases which were merely protected when they had to be
protected[this] not to allow unsound variance crossover.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
It had repeated all the TypeMap logic. I made it a TypeMap.
|
