| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
SI-9086 Fix regression in implicit search
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Implicit search declines to force the info of candidate implicits
that either a) are defined beyond the position of the implicit search
site, or b) enclose the implicit search site.
The second criterion used to prevent consideration of `O` in
the super constructor call:
implicit object O extends C( { implicitly[X] })
However, after https://github.com/scala/scala/pull/4043, the
block containing the implicit search is typechecked in a context
owned by a local dummy symbol rather than by `O`. (The dummy and
`O` share an owner.)
This led to `O` being considered as a candidate for this implicit
search. This search is undertaken during completion of the info of
`O`, which leads to it being excluded on account of the LOCKED flag.
Unfortunately, this also excludes it from use in implicit search
sites subsequent to `O`, as `ImplicitInfo` caches
`isCyclicOrErroneous`.
This commit adjusts the position of the local dummy to be identical
to that of the object. This serves to exclude `O` as a candidate
during the super call on account of criterion a).
|
| |\ \
| | |
| | | |
SI-9093 Fix value discarding / multiple param list crasher
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The type error stemming from missing argument list was being
swallowed when the expected type was `Unit` and there were
undetermined type parameters in the expression.
This commit modifies `adapt` to avoid using
`instantiateExpectingUnit` when the tree is typed with `MethodType`.
|
| | |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
An -Xlint:stars-align warning for the case of patterns
with at least one "fixed" component and a varargs component.
Warn if the fixed patterns don't exactly align with the fixed
value components, such that a sequence wildcard aligns exactly
with the varargs component (either a T* parameter in a case class
or a Seq[T] in an extractor result).
This addresses the case of the xml.Elem extractor, which does
not correspond to the Elem class constructor. One can be fooled
into supplying an extra field for extraction.
Vanilla extractors of type `Option[Seq[_]]` are unaffected by
this flag. It's OK to ask for `case X(a, b, c)` in the expectation
that three results are forthcoming. There is no semantic confusion
over where the varargs begin.
|
| |\ \
| |/
|/| |
SI-5154 Parse leading literal brace in XML pattern
|
| | |
| |
| |
| |
| |
| |
| | |
Don't consume literal brace as Scala pattern.
Previously, leading space would let the text parser `xText`
handle it correctly instead.
|
| | |
| |
| |
| |
| |
| | |
- Rename CodeRepository to ByteCodeRepository
- Scaladoc on OptimizerReporting
- Scaladoc on ByteCodeRepository
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This infrastructure is required for the inliner: when inlining code
from a classfile, the corresponding ClassBType is needed for various
things (eg access checks, InnerClass attribute).
The test creates two ClassBTypes for the same class: once using the
(unpickled) Symbol, once using the parsed ASM ClassNode, and verifies
that the two are the same.
There's a cleanup to the InnerClass attribute:
object T { class Member; def foo = { class Local } }
class T
For Java compatibility the InnerClass entry for Member says the class
is nested in T (not in the module class T$). We now make sure to add
that entry only to T, not to T$ (unless Member is actually referenced
in the classfile T$, in that case it will be added, as required).
|
| | |
| |
| |
| |
| | |
Introduces methods for textifying classes, methods, InsnLists and
individual AbstractInsnNodes.
|
| | |
| |
| |
| |
| | |
There's already the map classBTypeFromInternalNameMap in BTypes which
stores all ClassBTypes.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Each ClassBType is identified by its internalName, the fully qualified
JVM class name. Before this change, the name was stored in the `chrs`
array of the compiler name table (hash consed), with the idea to avoid
materializing the string.
However, we materialize the string anyway, because each ClassBType is
stored in the classBTypeFromInternalNameMap, indexed by the string.
If string equality turns out to be too slow we can use interning.
For the inliner, we read classes from bytecode and create ClassBTypes
for them. The names of these classes would not yet exist in the name
table, so the backend would need to be able to create new names. Using
Strings removes this dependency.
|
| |\ \
| | |
| | | |
SI-9089 Another REPL/FSC + specialization bug fix
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The enclosed test case stopped working in 2.11.5 on the back of
https://github.com/scala/scala/pull/4040.
The key change was that we ran all post-typer info transformers
on each run of the compiler, rather than trying to reuse the results
of the previous run.
In that patch, I noticed one place [1] in specialization that
aggressively entered specialized members into the owning scope,
rather than relying on `transformInfo` to place the new members
in the scope of the newly created element of the info history.
I made that change after noticing that this code could actually
mutated scopes of specializaed types at the parser phase, which
led to fairly obscure failures.
This bug is another one of these obscure failures, and has the
same root cause. We effectively "double specialiaze" Function0,
which trips an assertion when `method apply$mcI$sp` is found
twice in a scope.
I have found another spot that was directly manipulating the scope,
and removed the offending code.
[1] https://github.com/scala/scala/pull/4040#commitcomment-8531516
|
| |\ \ \
| |/ /
|/| | |
Fix many typos in docs and comments
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit corrects many typos found in scaladocs, comments and
documentation. It should reduce a bit number of PRs which fix one
typo.
There are no changes in the 'real' code except one corrected name of
a JUnit test method and some error messages in exceptions. In the case
of typos in other method or field names etc., I just skipped them.
Obviously this commit doesn't fix all existing typos. I just generated
in IntelliJ the list of potential typos and looked through it quickly.
|
| | | |
|
| |\ \
| | |
| | | |
SI-7965 Support calls to MethodHandle.{invoke,invokeExact}
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
These methods are "signature polymorphic", which means that compiler
should not:
1. adapt the arguments to `Object`
2. wrap the repeated parameters in an array
3. adapt the result type to `Object`, but instead treat it as it
it already conforms to the expected type.
Dispiritingly, my initial attempt to implement this touched the type
checker, uncurry, erasure, and the backend.
However, I realized we could centralize handling of this in the typer
if at each application we substituted the signature polymorphic
symbol with a clone that carried its implied signature, which is
derived from the types of the arguments (typechecked without an
expected type) and position within and enclosing cast or block.
The test case requires Java 7+ to compile so is currently embedded
in a conditionally compiled block of code in a run test.
We ought to create a partest category for modern JVMs so we can
write such tests in a more natural style.
Here's how this looks in bytecode. Note the `bipush` / `istore`
before/after the invocation of `invokeExact`, and the descriptor
`(LO$;I)I`.
```
% cat sandbox/poly-sig.scala && qscala Test && echo ':javap Test$#main' | qscala
import java.lang.invoke._
object O {
def bar(x: Int): Int = -x
}
object Test {
def main(args: Array[String]): Unit = {
def lookup(name: String, params: Array[Class[_]], ret: Class[_]) = {
val lookup = java.lang.invoke.MethodHandles.lookup
val mt = MethodType.methodType(ret, params)
lookup.findVirtual(O.getClass, name, mt)
}
def lookupBar = lookup("bar", Array(classOf[Int]), classOf[Int])
val barResult: Int = lookupBar.invokeExact(O, 42)
()
}
}
scala> :javap Test$#main
public void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: ACC_PUBLIC
Code:
stack=3, locals=3, args_size=2
0: aload_0
1: invokespecial #18 // Method lookupBar$1:()Ljava/lang/invoke/MethodHandle;
4: getstatic #23 // Field O$.MODULE$:LO$;
7: bipush 42
9: invokevirtual #29 // Method java/lang/invoke/MethodHandle.invokeExact:(LO$;I)I
12: istore_2
13: return
LocalVariableTable:
Start Length Slot Name Signature
0 14 0 this LTest$;
0 14 1 args [Ljava/lang/String;
13 0 2 barResult I
LineNumberTable:
line 16: 0
}
```
I've run this test across our active JVMs:
```
% for v in 1.6 1.7 1.8; do java_use $v; pt --terse test/files/run/t7965.scala || break; done
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)
Selected 1 tests drawn from specified tests
.
1/1 passed (elapsed time: 00:00:02)
Test Run PASSED
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
Selected 1 tests drawn from specified tests
.
1/1 passed (elapsed time: 00:00:07)
Test Run PASSED
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
Selected 1 tests drawn from specified tests
.
1/1 passed (elapsed time: 00:00:05)
Test Run PASSED
```
|
| |\ \ \
| | | |
| | | | |
SI-9044 Fix order of interfaces in classfiles
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It was reversed since ced3ca8ae1. The reason is that the backend used
`mixinClasses` to obtain the parents of a class, which returns them in
linearization order.
`mixinClasses` als returns all ancestors (not only direct parents),
which means more work for `minimizeInterfaces`. This was introduced
in cd62f52 for unclear reasons. So we switch back to using `parents`.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-8999 Reduce memory usage in exhaustivity check
|
| | | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The OOM could occur when all models are forcibly expanded in the DPLL solver.
The simplest solution would be to limit the number of returned models but then
we are back in non-determinism land (since the subset we get back depends on
which models were found first).
A better alternative is to create only the models that have corresponding
counter examples.
If this does not ring a bell, here's a longer explanation:
TThe models we get from the DPLL solver need to be mapped back to counter
examples. However there's no precalculated mapping model -> counter example.
Even worse, not every valid model corresponds to a valid counter example.
The reason is that restricting the valid models further would for example
require a quadratic number of additional clauses. So to keep the optimistic case
fast (i.e., all cases are covered in a pattern match), the infeasible counter
examples are filtered later.
The DPLL procedure keeps the literals that do not contribute to the solution
unassigned, e.g., for `(a \/ b)` only {a = true} or {b = true} is required and
the other variable can have any value. This function does a smart expansion of
the model and avoids models that have conflicting mappings.
For example for in case of the given set of symbols (taken from `t7020.scala`):
"V2=2#16"
"V2=6#19"
"V2=5#18"
"V2=4#17"
"V2=7#20"
One possibility would be to group the symbols by domain but
this would only work for equality tests and would not be compatible
with type tests.
Another observation leads to a much simpler algorithm:
Only one of these symbols can be set to true,
since `V2` can at most be equal to one of {2,6,5,4,7}.
TODO: How does this fare with mixed TypeConst/ValueConst assignments?
When the assignments are e.g., V2=Int | V2=2 | V2=4, only the assignments
to value constants are mutually exclusive.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-7459 Handle pattern binders used as prefixes in TypeTrees.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Match translation was incorrect for:
case t => new t.C
case D(t) => new d.C
We would end up with Types in TypeTrees referring to the wrong
symbols, e.g:
// t7459a.scala
((x0$1: this.LM) => {
case <synthetic> val x1: this.LM = x0$1;
case4(){
matchEnd3(new tttt.Node[Any]())
};
matchEnd3(x: Any){
x
}
Or:
// t7459b.scala
((x0$1: CC) => {
case <synthetic> val x1: CC = x0$1;
case4(){
if (x1.ne(null))
matchEnd3(new tttt.Node[Any]())
else
case5()
};
This commit:
- Changes `bindSubPats` to traverse types, as well as terms,
in search of references to bound symbols
- Changes `Substitution` to reuse `Tree#substituteSymbols` rather
than the home-brew substitution from `Tree`s to `Tree`s, if the
`to` trees are all `Ident`s
- extends `substIdentsForTrees` to substitute selections like
`x1.caseField` into types.
I had to dance around the awkward handling of "swatches" (exception
handlers that can be implemented with JVM native type switches) by
duplicating trees to avoid seeing the results of `substituteSymbols`
in `caseDefs` after we abandon that approach if we detect the
patterns are too complex late in the game.
I also had to add an escape hatch for the "type selection from
volatile type" check in the type checker. Without this, the
translation of `pos/t7459c.scala`:
case <synthetic> val x1: _$1 = (null: Test.Mirror[_]).universe;
case5(){
if (x1.isInstanceOf[Test.JavaUniverse])
{
<synthetic> val x2: _$1 with Test.JavaUniverse = (x1.asInstanceOf[_$1 with Test.JavaUniverse]: _$1 with Test.JavaUniverse);
matchEnd4({
val ju1: Test.JavaUniverse = x2;
val f: () => x2.Type = (() => (null: x2.TypeTag[Nothing]).tpe);
.. triggers that error at `x2.TypeTag`.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Suppress match analysis under -Xno-patmat-analysis
|
| | | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
NoSuppression doesn't suppress. FullSuppression does.
Now using the latter when running under `-Xno-patmat-analysis`.
I should really have tested. /me hides under a rock
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Run dead code elimination by default in GenBCode
|
| | | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | | |
This was disabled by mistake. Settings are still a challenge.
This fixes the bcode-delambdafy-method build
(https://scala-webapps.epfl.ch/jenkins/view/2.11.x/job/scala-nightly-genbcode-2.11.x/)
|
| |\ \ \ \ \
| |_|/ / /
|/| | | | |
[nomerge] SI-9030 don't call private BoxesRunTime.equalsNumChar
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When comparing a Number and a Character, the would emit a call to the
private method. For binary compatibility, this method remains private
in 2.11, so we just use equalsNumObject instead.
|
| |\ \ \ \ \
| |_|/ / /
|/| | | | |
Avoid the `CNF budget exceeded` exception via smarter translation into CNF.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The exhaustivity checks in the pattern matcher build a propositional
formula that must be converted into conjunctive normal form (CNF) in
order to be amenable to the following DPLL decision procedure.
However, the simple conversion into CNF via negation normal form and
Shannon expansion that was used has exponential worst-case complexity
and thus even simple problems could become untractable.
A better approach is to use a transformation into an _equisatisfiable_
CNF-formula (by generating auxiliary variables) that runs with linear
complexity. The commonly known Tseitin transformation uses bi-
implication. I have choosen for an enhancement: the Plaisted
transformation which uses implication only, thus the resulting CNF
formula has (on average) only half of the clauses of a Tseitin
transformation.
The Plaisted transformation uses the polarities of sub-expressions to
figure out which part of the bi-implication can be omitted. However,
if all sub-expressions have positive polarity (e.g., after
transformation into negation normal form) then the conversion is
rather simple and the pseudo-normalization via NNF increases chances
only one side of the bi-implication is needed.
I implemented only optimizations that had a substantial
effect on formula size:
- formula simplification, extraction of multi argument operands
- if a formula is already in CNF then the Tseitin/Plaisted
transformation is omitted
- Plaisted via NNF
- omitted: (sharing of sub-formulas is also not implemented)
- omitted: (clause subsumption)
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: Gerard Basler <gerard.basler@gmail.com>
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Remove redundant UniqueSym class.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-9015 Reject 0x and minor parser cleanup
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Only print error results. Show deprecated forms.
Test for rejected literals and clean up parser
There was no negative test for what constitutes a legal literal.
The ultimate goal is for the test to report all errors in
one compilation.
This commit follows up the removal of "1." syntax to simplify
number parsing. It removes previous paulp code to contain the
erstwhile complexity.
Leading zero is not immediately put to the buffer. Instead,
the empty buffer is handled on evaluation. In particular, an
empty buffer due to `0x` is a syntax error.
The message for obsolete octal syntax is nuanced and deferred
until evaluation by the parser, which is slightly simpler to
reason about.
Improve comment on usage of base
The slice-and-dicey usage of base deserves a better
comment. The difference is that `intVal` sees an empty
char buffer for input `"0"`.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-9008 Fix regression with higher kinded existentials
|
| | |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Allow a naked type constructor in an existential type if
we are directly within a type application.
Recently, 84d4671 changed nested context creation to avoid passing
down the `TypeConstructorAllowed`, which led to missing kind errors
in code like `type T[({type M = List})#M]`.
However, when typechecking `T forSome { quantifiers }`, we create
a nested context to represent the nested scope introduced for the
quantifiers. But we need to propagate the `TypeConstructorAllowed`
bit to the nested context to allow for higher kinded existentials.
The enclosed tests show:
- pos/t9008 well kinded application of an hk existential
- neg/t9008 hk existential forbidden outside of type application
- neg/t9008b kind error reported for hk existential
Regressed in 84d4671.
|
| |\ \ \ \ \ \
| |_|_|/ / /
|/| | | | | |
Fix typo
|
| | | | | | | |
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | | |
The alternative, flat representation of classpath elements
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This commit addresses code review comments.
The flat classpath is no longer the default classpath representation.
It was the default one just for the test purposes. For now it's not
desirable to make it permanently the default representation.
ZipAndJarFileLookupFactory is marked as sealed - it should help to
limit the ways of creating flat classpath instances for zips and jars.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The goal of these changes is to add possibility to:
- compare an efficiency and a content of both cp implementations
(ClassPathImplComparator)
- examine the memory consumption by creating a lot of globals using
a specified classpath (ClassPathMemoryConsumptionTester) - it can be
considered as e.g. some approximation of ScalaPresentationCompilers
in Scala IDE when working with many projects
ClassPathMemoryConsumptionTester is placed in main (I mean not test)
sources so thanks to that it has properly, out of the box configured
boot classpath etc. and it's easy to use it, e.g.:
scala scala.tools.nsc.ClassPathMemoryConsumptionTester
-YclasspathImpl:<implementation_to_test> -cp <some_cp>
-sourcepath <some_sp> -requiredInstances 50 SomeFileToCompile.scala
At the end it waits for the "exit" command so there can be used some
profiler like JProfiler to look how the given implementation behaves.
Also flat classpath implementation is set as a default one to test it
on Jenkins. This particular change must be reverted when all tests
will pass because for now it's not desirable to make it permanently
the default representation.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This commit contains some minor changes made by the way when
implementing flat classpath.
Sample JUnit test that shows that all pieces of JUnit infrastructure
work correctly now uses assert method form JUnit as it should do from
the beginning.
I removed commented out lines which were obvious to me. In the case
of less obvious commented out lines I added TODOs as someone should
look at such places some day and clean them up.
I removed also some unnecessary semicolons and unused imports.
Many string concatenations using + have been changed to string
interpolation.
There's removed unused, private walkIterator method from ZipArchive.
It seems that it was unused since this commit:
https://github.com/scala/scala/commit/9d4994b96c77d914687433586eb6d1f9e49c520f
However, I had to add an exception for the compatibility checker
because it was complaining about this change.
I made some trivial corrections/optimisations like use 'findClassFile'
method instead of 'findClass' in combination with 'binary' to find
the class file.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
There's added -YdisableFlatCpCaching option to ScalaSettings which
allows user to disable caching of flat representation of classpath
elements.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This commit integrates with the compiler the whole flat classpath
representation build next to the recursive one as an alternative.
From now flat classpath really works and can be turned on. There's
added flag -YclasspathImpl with two options: recursive (the default
one) and flat.
It was needed to make the dynamic dispatch to the particular
classpath representation according to the chosen type of a classpath
representation.
There's added PathResolverFactory which is used instead of a concrete
implementation of a path resolver. It turned out that only a small
subset of path resolvers methods is used outside this class in Scala
sources. Therefore, PathResolverFactory returns an instance of a base
interface PathResolverResult providing only these used methods.
PathResolverFactory in combination with matches in some other places
ensures that in all places using classpath we create/get the proper
representation.
Also the classPath method in Global is modified to use the dynamic
dispatch. This is very important change as a return type changed to
the base ClassFileLookup providing subset of old ClassPath public
methods. It can be problematic if someone was using in his project
the explicit ClassPath type or public methods which are not provided
via ClassFileLookup. I tested flat classpath with sbt and Scala IDE
and there were no problems. Also was looking at sources of some other
projects like e.g. Scala plugin for IntelliJ and there shouldn't be
problems, I think, but it would be better to check these changes
using the community build.
Scalap's Main.scala is changed to be able to use both implementations
and also to use flags related to the classpath implementation.
The classpath invalidation is modified to work properly with the old
(recursive) classpath representation after changes made in a Global.
In the case of the attempt to use the invalidation for the flat cp it
just throws exception with a message that the flat one currently
doesn't support the invalidation. And also that's why the partest's
test for the invalidation has been changed to use (always) the old
implementation. There's added an adequate comment with TODO to this
file.
There's added partest test generating various dependencies
(directories, zips and jars with sources and class files) and testing
whether the compilation and further running an application works
correctly, when there are these various types of entries specified as
-classpath and -sourcepath. It should be a good approximation of real
use cases.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This commit adds dedicated FlatClassPathResolver loading classpath
entries as FlatClassPath.
Most of the common logic from PathResolver for the old classpath has
been moved to the base, separate class which isn't dependent on
a particular classpath representation. Thanks to that it was possible
to reuse it when creating an adequate path resolver for the flat
classpath representation.
This change doesn't modify the way the compiler works. It also
doesn't change nothing from the perspective of someone who already
uses PathResolver in some project or even extends it - at least as
long as he/she doesn't need to use flat classpath.
There are also added JUnit tests inter alia comparing entries created
using the old and the new classpath representations (whether the flat
one created using the new path resolver returns the same entries as
the recursive one).
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The part of the functionality of a ClassPathContext has been moved
to the base trait ClassPathFactory so it can be reused by the newly
created FlatClassPathFactory. This new implementation works in
similar manner as the ClassPathContext with this difference that it
just creates instances of flat classpath.
This change doesn't modify the behaviour of the compiler as the
interface and the way ClassPathContext works didn't change. Moreover
FlatClassPathFactory is currently unused.
|
