| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Rename `conforms` to `$conforms` and put in a minimal backstop: pos/t7788.scala
TODO: predicate the backwards compatibility shim for `Predef_conforms`
on `-Xsource:2.10`
|
|
|
|
|
|
|
|
|
|
| |
To support the established pattern for disabling it for
an compilation unit.
Update scaladoc's knowledge of our "typeclasses".
Leave a `private[scala]` version of `StringAdd` (public in bytecode)
to ensure binary compatibility with 2.11.0-M8 for partest.
|
|\
| |
| | |
SI-6566, unsoundness with alias variance: document fix
|
| |
| |
| |
| |
| |
| | |
Commit a419799f872d5aae99728d711b1ced89e06804a8 changed the behavior of
relativeVariance, but without updating the corresponding comment. Fix
that.
|
|\ \
| | |
| | | |
README.md: Add link to CONTRIBUTING.md
|
| | | |
|
|\ \ \
| | | |
| | | | |
SI-7932 Exclude PolyTypes from Java generic signatures
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In the enclosed test case, we were emitting just the result type of
`[a, b]Float` in the Java generic signature.
This resulted in a `GenericSignatureFormatError`.
This commit changes `argSig` to project such type functions to `*`
instead.
The test case shows that we still emit the class when we use
its type constructor directly as the type argument.
|
|\ \ \ \
| | | | |
| | | | | |
SI-8301 fix regression with refinement subtyping, wildcard type.
|
| | | | |
| | | | |
| | | | |
| | | | | |
As we did for `Select`-s in SI-6815 / fada1ef6.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In the enclosed test case, the list of candidate implicit is
checked for eligibility with the view by:
pt = Test.sym.type => ?{def asFreeType: ?}
tp = (sym: Test.u.Symbol)Test.u.CompatibleSymbol
matchesPt(tp, pt)
This ends up in `TypeComparers#specializesSym`, which compares:
symLo = asFreeType: => Universe.this.TypeSymbol
symHi = asFreeType: ?
Before the regression in fada1ef6, that method called `isStable`
on both of these to make sure that `symLo` was as least as stable
as `symHi`. Both returned `false`, and, they matched.
After that refactoring, two calls were made. `isStable` *only*
checked for stability, and gave the same results as before.
But, the new check for volatility believes that the low symbol
was more volatile than the high, because `WildCardType` is treated
as non-volatile.
Really, it should have the same volatility as whatever it is
being compared to, so that these sort of comparisons yield true.
This commit ammends `specializesSym` to special case `symHi: ?`,
and ignore the volatilty gap in that case.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Optimization: remove assertion from SubstMap constructor
|
| | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
A profile [1] reported 3% of a compile run was spent here.
This commit demotes the eager check to -Xdev.
This assertion was added in e557acb9a7.
[1] https://dl.dropboxusercontent.com/u/106552/perf/rudder-nailgun-2014-02-18-1.snapshot
|
|\ \ \ \ \
| | | | | |
| | | | | | |
SI-8072 rationalize public implicits in scala parallel collections
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Pretty much everything seems like it's intended for internal use, so I moved it to a package-private object.
Split toParArray out and put it in an implicit class. Added ability to .toParArray from Array and String also.
Added test to verify implicits are gone.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
SI-5165 separate compilation test Java annotations bug
|
| |/ / / /
| | | | |
| | | | |
| | | | | |
Progressed at the genesis of GenASM, dc6a49337f.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
SI-5134 Test case for fixed DelayedInit / structural type bug
|
| |/ / / /
| | | | |
| | | | |
| | | | | |
As with SI-5655, this started working in b4fbb7be0e by @magarciaEPFL
|
|\ \ \ \ \
| |/ / / /
|/| | | | |
Test case for fixed delayed init bug
|
|/ / / /
| | | |
| | | |
| | | | |
Fixed in b4fbb7be0e by @magarciaEPFL
|
|\ \ \ \
| |/ / /
|/| | | |
Toning down the noise of -Xlint and allow `-optimise -Yinline:false`
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In the last commit, we added the ability to explicitly disable
boolean settings form the command line.
This commit changes group settings (like -optimize), to leave
them alone if set explicitly.
Examples:
`scalac -Xlint -Ywarn-unused:false -optimize -Yinline:false`
The mechanism for such settings has also been refactored to
`MutableSettings`, to let use reuse this for `-Xlint`.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Enables `-Yboolean-setting:{true,false}`. This will be exploited
in the next commit to enable one to turn off a single component
of a group setting, such as `-Xlint` or `-optimize`.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Experience building open source projects like Specs that use
`-Xlint` suggests that this warning is too noisy to lump in
with the others.
We are lacking in more fine-grained control of these things, so
simply turning of `-Xlint` in favour of its underlying `-Y` options
ends up *losing* some other important warnings that are predicated
directly on `-Xlint`.
Furthermore, bug reports against M8, SI-7707 SI-7712, show that
unused private/local warnings, while far less noisy, are still
in need of polish.
This commit moves these warnings to a pair of new -Y options,
neither of which is part of `-Xlint`..
Let's ask people to opt in for 2.11, and as it stabilizes, we can
consider adding it to Xlint (or the desirable evolution of that)
in the next release.
|
|\ \ \
| | | |
| | | | |
Avoid storing source file contents twice
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
BatchSourceFile instances contain two almost identical character arrays,
content0 and content. What's worse, content0 is even public. Instead,
content0 should just be a constructor parameter. This seems the residual
of an incomplete refactoring.
I observed this waste of memory during debugging; after applying this
patch, I've verified by hand that the second field indeed disappears.
I don't expect a measurable difference, but this patch is not premature
optimization because it makes code more logical.
|
|\ \ \
| |_|/
|/| | |
Revert "SI-5920 enables default and named args in macros"
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit a02e053a5dec134f7c7dc53a2c1091039218237d.
That commit lead to an error compiling Specs2:
[info] [warn] /localhome/jenkinsdbuild/workspace/Community-2.11.x-retronym/dbuild-0.7.1-M1/target-0.7.1-M1/project-builds/specs2-aaa8091b47a34817ca90134ace8b09a9e0f854e9/core/src/test/scala/org/specs2/text/EditDistanceSpec.scala:6: Unused import
[info] [warn] import DiffShortener._
[info] [warn] ^
[info] [error] /localhome/jenkinsdbuild/workspace/Community-2.11.x-retronym/dbuild-0.7.1-M1/target-0.7.1-M1/project-builds/specs2-aaa8091b47a34817ca90134ace8b09a9e0f854e9/core/src/test/scala/org/specs2/text/LinesContentDifferenceSpec.scala:7: exception during macro expansion:
[info] [error] java.lang.UnsupportedOperationException: Position.point on NoPosition
[info] [error] at scala.reflect.internal.util.Position.fail(Position.scala:53)
[info] [error] at scala.reflect.internal.util.UndefinedPosition.point(Position.scala:131)
[info] [error] at scala.reflect.internal.util.UndefinedPosition.point(Position.scala:126)
[info] [error] at org.specs2.reflect.Macros$.sourceOf(Macros.scala:25)
[info] [error] at org.specs2.reflect.Macros$.stringExpr(Macros.scala:19)
|
|\ \
| | |
| | | |
SI-5920 enables default and named args in macros
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When producing an initial spec for macros two years ago, we sort of glossed
over named/default arguments in macro applications, leaving them for future work.
Once the aforementioned future has come, I’ve made several attempts at
making things operational (e.g. last summer), but it’s always been unclear
how to marry the quite complex desugaring that tryNamesDefaults performs
with the expectations of macro programmers to see unsugared trees
in macro impl parameters.
Here’s the list of problems that arise when trying to encode named/default
arguments of macro applications:
1) When inside macro impls we don’t really care about synthetic vals
that are typically introduced to preserve evaluation order in non-positional
method applications. When we inline those synthetics, we lose information
about evaluation order, which is something that we wouldn’t like to lose
in the general case.
2) More importantly, it’s also not very exciting to see invocations of
default getters that stand for unspecified default arguments. Ideally,
we would like to provide macro programmers with right-hand sides of those
default getters, but that is: a) impossible in the current implementation
of default parameters, b) would anyway bring scoping problems that we’re
not ready to deal with just yet.
Being constantly unhappy with potential solutions to the aforementioned
problems, I’ve been unable to nail this down until the last weekend,
when I realized that: 1) even though we can’t express potential twists in
evaluation order within linearly ordered macro impl params, we can use
c.macroApplication to store all the named arguments we want, 2) even though
we can’t get exactly what we want for default arguments, we can represent
them with EmptyTree’s, which is not ideal, but pretty workable. That’s
what has been put into life in this commit.
As a pleasant side-effect, now the macro engine doesn’t have to reinvent
the wheel wrt reporting errors about insufficient arg or arglist count.
Since this logic is intertwined with the tryNamesDefaults desugaring,
we previously couldn’t make use of it and had to roll our own logic
that checked that the number of arguments and parameters of macro applications
correspond to each other. Now it’s all deduplicated and consistent.
|
| | |
| | |
| | |
| | |
| | |
| | | |
This facility, along with -Yshow-syms, has proven to be very useful
when debugging problems caused by corrupt owner chains when hacking on
named/default argument transformation.
|
| | |
| | |
| | |
| | |
| | | |
Since now it uses idString to print out the id part of the name when
-uniqid is turned on, instead of duplicating the code from idString.
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
Make handling of tuples more consistent in quasi-quotes
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
On one hand we know that q"($expr)" is the same as q"$expr". On the
other if we wrap it into a list and splice as q"(..$expr)" we get a
Tuple1 constructor call which is inconsistent.
This pull request fixes this inconsistency by making q"(..$expr)" being
equivalent q"(${expr.head})" for single-element list.
We also add support for matching of expressions as single-element tuples
(similarly to blocks) and remove liftables and unliftables for Tuple1
(which aren't clearly defined any longer due to q"(foo)" == q"foo"
invariant).
|
|\ \ \ \
| | | | |
| | | | | |
SI-8270 unconfuses bundles and vanilla macros
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This fixes a mistake in macro impl ref typechecking that used to have
an heuristic to figure out whether it looks at a bundle method ref or at
a vanilla object method ref. Under some circumstances the heuristic could
fail, and then the macro engine would reject perfectly good macro impls.
Now every macro impl ref is typechecked twice - once as a bundle method ref
and once as a vanilla object method ref. Results are then analyzed,
checked against ambiguities (which are now correctly reported instead
of incorrectly prioritizing towards bundles) and delivered to the macro
engine.
The only heuristic left in place is the one that's used to report errors.
If both bundle and vanilla typechecks fail, then if a bundle candidate
looks sufficiently similar to a bundle, a bundle typecheck error is reported
providing some common bundle definition hints.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
typecheck(q"class C") no longer crashes
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
MemberDefs alone can't be typechecked as is, because namer only names
contents of PackageDefs, Templates and Blocks. And, if not named, a tree
can't be typed.
This commit solves this problem by wrapping typecheckees in a trivial block
and then unwrapping the result when it returns back from the typechecker.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Fix SI-8202 and improve support for splicing patterns into vals
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This commits adds construction-only support for splicing patterns into
vals (a.k.a. PatDef). Due to non-locality of the desugaring it would
have been quite expensive to support deconstruction as the only way to
do it with current trees is to perform implodePatDefs transformation on
every single tree.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Also use sym.isErrorneous instead of manual name check.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Previously construction logic used to be in Parsers and deconstruction in
Placeholders making it easy to forget one if you change the other.
|
| | |_|/ / /
| |/| | | | |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-3452 Correct Java generic signatures for mixins, static forwarders
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Shares the code with the GenASM version of the fix.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
For a non copypasta for of reuse in GenBCode.
|