summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | | | | SI-9044 Fix order of interfaces in classfilesLukas Rytz2014-12-185-49/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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`.
* | | | | | | Merge pull request #4205 from retronym/ticket/9011Adriaan Moors2014-12-231-1/+5
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | SI-9011 Speculative fix for CCE in Scala IDE
| * | | | | | | SI-9011 Speculative fix for CCE in Scala IDEJason Zaugg2014-12-151-1/+5
| | |_|/ / / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on the reported stack trace and what I know of Scala IDE, I've changed `InteractiveNamer#enterExistingSymbol` to be `DocDef` aware. I haven't provided a test as this was not minimized from Scala IDE.
* | | | | | | Merge pull request #4207 from gourlaysama/bump-parser-combinatorsAdriaan Moors2014-12-231-1/+1
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | update to scala-parser-combinators 1.0.3
| * | | | | | | update to scala-parser-combinators 1.0.3Antoine Gourlay2014-12-151-1/+1
| | | | | | | |
* | | | | | | | Merge pull request #4199 from adriaanm/rebase-4193Adriaan Moors2014-12-185-62/+394
|\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | SI-8999 Reduce memory usage in exhaustivity check
| * | | | | | | | SI-8999 Reduce memory usage in exhaustivity checkGerard Basler2014-12-125-62/+394
| | |/ / / / / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | | | | | Merge pull request #4122 from retronym/ticket/7459-2Adriaan Moors2014-12-1817-13/+219
|\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | SI-7459 Handle pattern binders used as prefixes in TypeTrees.
| * | | | | | | | SI-7459 Handle pattern binders used as prefixes in TypeTrees.Jason Zaugg2014-11-1417-13/+219
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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`.
* | | | | | | | | Merge pull request #4085 from adriaanm/patmat-suppressLukas Rytz2014-12-185-6/+167
|\ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | Suppress match analysis under -Xno-patmat-analysis
| * | | | | | | | | Suppress match analysis under -Xno-patmat-analysisAdriaan Moors2014-12-125-6/+167
| | |/ / / / / / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | | | | | | | Merge pull request #4191 from som-snytt/issue/8538Lukas Rytz2014-12-182-3/+100
|\ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | SI-8538 Test or example for Source.report
| * | | | | | | | | SI-8538 Document extensionSom Snytt2014-12-152-3/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Scaladoc for report extension point.
| * | | | | | | | | SI-8538 Test or example for Source.reportSom Snytt2014-12-121-0/+56
| |/ / / / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's possible to supply an arbitrary `Positioner` to a custom `Source` that wants to override `report`. This obviates the need to expose the deprecated `Position` class. The default report method consumes the underlying iterator, which is not desirable and produces unexpected results. The expected outcome is that no one uses or extends the legacy position handling code. In 2.12, use a Reporter instead, perhaps. The current API is used by scala-xml's MarkupParser.
* | | | | | | | | Merge pull request #4211 from lrytz/bcode-buildGrzegorz Kossakowski2014-12-182-1/+2
|\ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | Run dead code elimination by default in GenBCode
| * | | | | | | | | Run dead code elimination by default in GenBCodeLukas Rytz2014-12-162-1/+2
| | |_|_|/ / / / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/)
* | | | | | | | | Merge pull request #4196 from lrytz/t9030-2.11Lukas Rytz2014-12-173-2/+21
|\ \ \ \ \ \ \ \ \ | |_|_|_|_|_|_|/ / |/| | | | | | | | [nomerge] SI-9030 don't call private BoxesRunTime.equalsNumChar
| * | | | | | | | [nomerge] SI-9030 don't call private BoxesRunTime.equalsNumCharLukas Rytz2014-12-113-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | | | | | | Merge pull request #4202 from kanielc/SI-9043Grzegorz Kossakowski2014-12-152-6/+43
|\ \ \ \ \ \ \ \ \ | |_|_|_|_|/ / / / |/| | | | | | | | SI-9043 ArrayBuffer.insert and insertAll are very slow
| * | | | | | | | SI-9043 ArrayBuffer.insert and insertAll are very slowDenton Cockburn2014-12-142-6/+43
| | |_|/ / / / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | insert and insertAll were slower than their java equivalents by factors of 5 and 10 respectively. Benchmark code was provided here: https://gist.github.com/rklaehn/3e9290118fcf63d1feae We are using a toList to the source Traversable Then doing a length and a copy on that collection. By using an array, we can make use of faster methods. Managed to get the ratios down to 1.5 and 1.5 respectively. In addition to this, I think we should consider breaking insert into 2 separate methods, one for a single item and one for a collection. The varags version is very expensive when a single item is being inserted. @phaller @axel22
* | | | | | | | Merge pull request #4203 from xuwei-k/ByteCodecs-scaladocLukas Rytz2014-12-151-2/+2
|\ \ \ \ \ \ \ \ | |/ / / / / / / |/| | | | | | | fix ByteCodecs scaladoc
| * | | | | | | fix ByteCodecs scaladocxuwei-k2014-12-141-2/+2
|/ / / / / / /
* | | | | | | Merge pull request #4078 from gbasler/topic/fix-analysis-budgetAdriaan Moors2014-12-1212-277/+673
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | Avoid the `CNF budget exceeded` exception via smarter translation into CNF.
| * | | | | | | Avoid the `CNF budget exceeded` exception via smarter translation into CNF.Gerard Basler2014-10-2711-268/+646
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
| * | | | | | | Debug printing for Any, not AnyRef, to include primitivesAdriaan Moors2014-10-261-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Gerard Basler <gerard.basler@gmail.com>
| * | | | | | | And, Or take sets of PropsGerard Basler2014-10-263-39/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove redundant UniqueSym class.
* | | | | | | | Merge pull request #4192 from Ichoran/issue/8950Lukas Rytz2014-12-112-2/+2
|\ \ \ \ \ \ \ \ | |_|_|/ / / / / |/| | | | | | | SI-8950 SeqView and StreamView allow indexing out of a slice
| * | | | | | | SI-8950 SeqView and StreamView allow indexing out of a sliceRex Kerr2014-12-062-2/+2
| | |_|_|_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added `idx >= 0` tests for `SeqViewLike#Sliced` `apply` and `mutable.IndexedSeqViewLike#Sliced` `unapply`. Now you get `IndexOutOfBoundsException`s as you should. No tests; this was found by collections-laws and will be tested by them. (Exact variants in bug report were tested in the REPL.)
* | | | | | | Merge pull request #4154 from smarter/patch-1Adriaan Moors2014-12-101-0/+2
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | spec: Add a link to the sources from the main page
| * | | | | | | spec: Add a link to the sources from the main pageGuillaume Martres2014-11-241-0/+2
| | | | | | | |
* | | | | | | | Merge pull request #4194 from lrytz/intellij-replAdriaan Moors2014-12-101-0/+1
|\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | intellij module repl depends on asm
| * | | | | | | | intellij module repl depends on asmLukas Rytz2014-12-091-0/+1
| | |/ / / / / / | |/| | | | | |
* | | | | | | | Merge pull request #4182 from som-snytt/issue/multizeroAdriaan Moors2014-12-096-202/+175
|\ \ \ \ \ \ \ \ | |/ / / / / / / |/| | | | | | | SI-9015 Reject 0x and minor parser cleanup
| * | | | | | | SI-9015 Reject 0x and minor parser cleanupSom Snytt2014-12-056-202/+175
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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"`.
* | | | | | | | Merge pull request #4169 from retronym/ticket/9008Adriaan Moors2014-12-057-2/+26
|\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | SI-9008 Fix regression with higher kinded existentials
| * | | | | | | | SI-9008 Fix regression with higher kinded existentialsJason Zaugg2014-12-037-2/+26
| |/ / / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | | | | | Merge pull request #4165 from dickwall/ticket/9006Adriaan Moors2014-12-053-1/+35
|\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | SI-9006 Scaladoc: explicit companion and package links
| * | | | | | | | SI-9006 Scaladoc: explicit companion and package linksDick Wall2014-11-263-1/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing navigation mechanisms have proved hard to discover for newcomers to Scaladoc. This commit adds textual links in the navigation bar to the docs of the companion (if defined) and to those of the enclosing package.
* | | | | | | | | Merge pull request #4187 from jedesah/patch-1Adriaan Moors2014-12-051-1/+1
|\ \ \ \ \ \ \ \ \ | |_|_|_|_|/ / / / |/| | | | | | | | Fix typo
| * | | | | | | | Fix typoJean-Remi Desjardins2014-12-041-1/+1
| | | | | | | | |
* | | | | | | | | Merge pull request #4176 from mpociecha/flat-classpath2Grzegorz Kossakowski2014-12-0552-315/+2217
|\ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | The alternative, flat representation of classpath elements
| * | | | | | | | | Turn off flat classpath by default, mark one of its classes as sealedmpociecha2014-12-052-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | | | | | Add benchmarks to compare recursive and flat cp representationsmpociecha2014-12-053-1/+221
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | | | | | Cleanup and refactoring - semicolons, unused or commented out codempociecha2014-12-0522-61/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | | | | | Create possibility to skip flat classpath cachingmpociecha2014-12-053-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's added -YdisableFlatCpCaching option to ScalaSettings which allows user to disable caching of flat representation of classpath elements.
| * | | | | | | | | Integrate flat classpath with the compilermpociecha2014-12-0517-68/+440
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | | | | | Refactor scalap's mainmpociecha2014-12-012-87/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The structure of scalap's Main has been refactored. EmptyClasspath is deleted. It looks that it was unused since this commit: https://github.com/scala/scala/commit/e594fe58ef8116a4bd2560ad0a856ad58ae9db33 Also classpath logging is changed and now uses asClassPathString method. It was needed to modify one test because of that but it won't depend on a particular representation. There aren't changes in the way scalap works.
| * | | | | | | | | Create dedicated path resolver for the flat classpath representationmpociecha2014-11-302-11/+195
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
| * | | | | | | | | Create base classpath factory and an implementation for the flat cpmpociecha2014-11-304-26/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | | | | | Add flat classpath implementation using ManifestResourcesmpociecha2014-11-301-4/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's added the flat classpath type using ManifestResources, closely related to the support for JSR-223 (Scripting for the Java Platform). It uses classes listed in the manifest file placed in the JAR. It's related to jar files so it's created using ZipAndJarFlatClassPathFactory and is cached. In general currently it's not possible to use it in Scala out of the box (without using additional tools such as jarlister) as this support is postponed. The old classpath has been properly prepared in the PR created by @rjolly https://github.com/scala/scala/pull/2238 so the new one also got this feature. ManifestResources is a ZipArchive without a real underlying file placed on a disk and in addition implementing some methods declared in AbstractFile as unsupported operations. Therefore the implementation has to use the iterator. I wanted to have the similar behaviour as in the case of directories and zip/jar files - be able to get a directory entry for a package without iterating all entries. This is achieved by iterating all entries only once and caching packages. This flat classpath type was the last needed one.