summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #4017 from lrytz/t6541Lukas Rytz2014-11-054-18/+41
|\ | | | | SI-6541 valid wildcard existentials for case-module-unapply
| * SI-6541 valid wildcard existentials for case-module-unapplyLukas Rytz2014-11-052-6/+20
| | | | | | | | | | | | | | | | Instead of letting the compiler infer the return type of case module unapply methods, provide them explicitly. This is enabled only under -Xsource:2.12, because the change is not source compatible.
| * Fix default value for ScalaVersionSettingLukas Rytz2014-11-042-12/+21
| | | | | | | | | | | | | | | | | | | | | | The default value was NoScalaVersion before, because tryToSet (where the default was supposed to be set) is not called at all if the option is not specified. The initial value of Xmigration is set to NoScalaVersion (which it was before, the AnyScalaVersion argument was ignored). AnyScalaVersion would be wrong, it would give a warning in `Map(1 -> "eis").values` if the option was not specified. See tests.
* | Merge pull request #4054 from soc/SI-8916Lukas Rytz2014-11-0437-62/+17
|\ \ | | | | | | SI-8916 Clean up unused imports, values and variables
| * | SI-8916 Further fixes with -Ywarn-unused includedSimon Ochsenreither2014-10-2410-17/+9
| | |
| * | SI-8916 Fix -Ywarn-unused-import warningsSimon Ochsenreither2014-10-2430-45/+8
| | |
* | | Merge pull request #4046 from gourlaysama/wip/t8711-version-unparseLukas Rytz2014-11-041-1/+1
|\ \ \ | | | | | | | | SI-8711 ScalaVersion.unparse doesn't produce valid versions
| * | | SI-8711 ScalaVersion.unparse doesn't produce valid versionsAntoine Gourlay2014-10-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no dot between `major.minor.rev` and `-build` in a scala version, yet that's what unparse returns for ``` // was "2.11.3.-SNAPSHOT" ScalaVersion("2.11.3-SNAPSHOT").unparse ```
* | | | Merge pull request #4036 from retronym/topic/opt-tail-callsJason Zaugg2014-11-043-20/+43
|\ \ \ \ | | | | | | | | | | SI-8893 Restore linear perf in TailCalls with nested matches
| * | | | Avoid wasteful array creation in backendJason Zaugg2014-10-101-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The iteration is only needed to side effect on `instructionList` and `code.touched`. This commit uses an iterator and `foreach`, rather than creating throwaway Arrays. % time (for f in {1..200}; do echo test/files/pos/t8893.scala; done | qscalac -Xresident) Before: 30s After : 21s
| * | | | SI-8893 Restore linear perf in TailCalls with nested matchesJason Zaugg2014-10-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Compilation perfomance of the enclosed test regressed when the new pattern matcher was introduced, specifically when the tail call elimination phase was made aware of its tree shapes in cd3d34203. The code added in that commit detects an application to a tail label in order to treat recursive calls in the argument as in tail position. If the transform of that argument makes no change, it falls back to `rewriteApply`, which transforms the argument again (although this time on a non-tail-position context.) This commit avoids the second transform by introducing a flag to `rewriteApply` to mark the arguments are pre-transformed. I don't yet see how that fixes the exponential performance, as on the surface it seems like a constant factor improvement. But the numbers don't lie, and we can now compile the test case in seconds, rather than before when it was running for > 10 minutes. This test case was based on a code pattern generated by the Avro serializer macro in: https://github.com/paytronix/utils-open/tree/release/2014/ernststavrosgrouper The exponential performance in that context is visualed here: https://twitter.com/dridus/status/519544110173007872 Thanks for @rmacleod2 for minimizing the problem.
| * | | | Wider use of mapConserve and the like in TailCallsJason Zaugg2014-10-101-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Save the Trees! When a subtransform is an identity, we must strive to return the identical tree to enable the lazy part of LazyTreeCopier. If we get this wrong in a leaf, all parents are wastefully copied.
| * | | | Avoid needlessly deep chains of ClonedTailContextJason Zaugg2014-10-101-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I believe ClonedTailContext was added to avoid the need to mutate the Boolean `ctx.tailPos`. All other calls are forwarded to a delegate context. This commit tries to find a delegate context with the right value of `tailPos` to reuse that, rather than creating a wrapper each time we need to flip that bit.
| * | | | Optimize tail calls to avoid findMember callsJason Zaugg2014-10-102-0/+12
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cache the member symbols for `Boolean.{||, &&}` per-run, rather than look them up repeatedly. Based on profiling the tail calls phase in the program below, which was distilled by @rmacleod2 from the code generated by macros in https://github.com/paytronix/utils-open/tree/release/2014/ernststavrosgrouper Wall clock time went from 12s to 6.5s. ```scala object Test { def a(): Option[String] = Some("a") def main(args: Array[String]) { a() match { case Some(b1) => a() match { case Some(b2) => a() match { case Some(b3) => a() match { case Some(b4) => a() match { case Some(b5) => a() match { case Some(b6) => a() match { case Some(b7) => a() match { case Some(b8) => a() match { case Some(b9) => a() match { case Some(b10) => a() match { case Some(b11) => a() match { case Some(b12) => a() match { case Some(b13) => a() match { case Some(b14) => a() match { case Some(b15) => a() match { case Some(b16) => a() match { case Some(b17) => a() match { case Some(b18) => a() match { case Some(b19) => a() match { case Some(b20) => println("yay") case None => None } case None => None } case None => None } case None => None } case None => None } case None => None } case None => None } case None => None } case None => None } case None => None } case None => None } case None => None } case None => None } case None => None } case None => None } case None => None } case None => None } case None => None } case None => None } case None => None } } } ```
* | | | Merge pull request #4052 from Lymia/issue/8910Jason Zaugg2014-11-041-4/+4
|\ \ \ \ | | | | | | | | | | SI-8910 BitSet sometimes uses exponential memory.
| * | | | SI-8910 BitSet sometimes uses exponential memory.Alissa Rao2014-10-151-4/+4
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because of an off-by-one error in scala.collection.mutable.BitSet, where a function (ensureCapacity) is passed a list length instead of an index, when ^=, &=, |=, or &~= are passed BitSets with the same internal capacity as the set the method is being invoked on, the size of the first BitSet is needlessly doubled. This patch simply changes the ensureCapacity calls to pass the last index of the list, instead of the raw length. In addition, add documentation to ensureCapacity to try and stop something similar from happening in the future.
* | | | Merge pull request #4087 from lrytz/intellijJason Zaugg2014-11-0421-0/+561
|\ \ \ \ | | | | | | | | | | IntelliJ IDEA files for version 14
| * | | | IntelliJ IDEA files for version 14Lukas Rytz2014-11-0321-0/+561
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The latest version of the Scala plugin for IntelliJ IDEA introduces a new project structure http://blog.jetbrains.com/scala/2014/10/30/scala-plugin-update-for-intellij-idea-14-rc-is-out/ Due to a bug (https://youtrack.jetbrains.com/issue/SCL-7753), you currently need to install the latest nightly build from here: http://confluence.jetbrains.com/display/SCA/Scala+Plugin+Nightly+Builds+for+Cassiopeia The new format doesn't allow scala compiler options per-module, so the `-sourcepath src/libarary` is used for all modules.
* | | | Merge pull request #4045 from gourlaysama/wip/t8875-show-codeJason Zaugg2014-11-041-1/+1
|\ \ \ \ | | | | | | | | | | SI-8875 showCode should print all class constructor modifiers.
| * | | | SI-8875 showCode should print all class constructor modifiers.Antoine Gourlay2014-10-241-1/+1
| | |/ / | |/| | | | | | | | | | | | | | showCode used to print nothing when the only modifier was a change in visibility scope (i.e. no flags but privateWithin is set).
* | | | Merge pull request #4064 from xuwei-k/typo-representationJason Zaugg2014-11-041-1/+1
|\ \ \ \ | |_|/ / |/| | | fix typo. s/represenation/representation
| * | | fix typo. s/represenation/representationxuwei-k2014-10-201-1/+1
| |/ /
* | | Merge pull request #4081 from retronym/ticket/8943Jason Zaugg2014-11-022-0/+4
|\ \ \ | | | | | | | | SI-8943 Handle non-public case fields in pres. compiler
| * | | SI-8943 Handle non-public case fields in pres. compilerJason Zaugg2014-10-292-0/+4
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a case class is type checked, synthetic methods are added, such as the `hashCode`/`equals`, implementations of the `Product` interface. At the same time, a case accessor method is added for each non-public constructor parameter. This the accessor for a parameter named `x` is named `x$n`, where `n` is a fresh suffix. This is all done to retain universal pattern-matchability of case classes, irrespective of access. What is the point of allowing non-public parameters if pattern matching can subvert access? I believe it is to enables private setters: ``` case class C(private var x: String) scala> val x = new C("") x: C = C() scala> val c = new C("") c: C = C() scala> val C(x) = c x: String = "" scala> c.x <console>:11: error: variable x in class C cannot be accessed in C c.x ^ scala> c.x = "" <console>:13: error: variable x in class C cannot be accessed in C val $ires2 = c.x ^ <console>:10: error: variable x in class C cannot be accessed in C c.x = "" ^ ``` Perhaps I'm missing additional motivations. If you think scheme sounds like a binary compatiblity nightmare, you're right: https://issues.scala-lang.org/browse/SI-8944 `caseFieldAccessors` uses the naming convention to find the right accessor; this in turn is used in pattern match translation. The accessors are also needed in the synthetic `unapply` method in the companion object. Here, we must tread lightly to avoid triggering a typechecking cycles before; the synthesis of that method is not allowed to force the info of the case class. Instead, it uses a back channel, `renamedCaseAccessors` to see which parameters have corresonding accessors. This is pretty flaky: if the companion object is typechecked before the case class, it uses the private param accessor directly, which it happends to have access to, and which duly gets an expanded name to allow JVM level access. If the companion appears afterwards, it uses the case accessor method. In the presentation compiler, it is possible to typecheck a source file more than once, in which case we can redefine a case class. This uses the same `Symbol` with a new type completer. Synthetics must be re-added to its type. The reported bug occurs when, during the second typecheck, an entry in `renamedCaseAccessors` directs the unapply method to use `x$1` before it has been added to the type of the case class symbol. This commit clears corresponding entries from that map when we detect that we are redefining a class symbol. Case accessors are in need of a larger scale refactoring. But I'm leaving that for SI-8944.
* | | Merge pull request #4079 from retronym/ticket/8941Jason Zaugg2014-11-023-9/+21
|\ \ \ | | | | | | | | SI-8941 Idempotent presentation compilation of implicit classes
| * | | SI-8941 Deterministic tests for pres. compiler idempotencyJason Zaugg2014-10-281-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A retrospective test case which covers typechecking idempotency which was introduced in 0b78a0196 / 148736c3df. It also tests the implicit class handling, which was fixed in the previous commit. It is difficult to test this using existing presentation compiler testing infrastructure, as one can't control at which point during the first typechecking the subesquent work item will be noticed. Instead, I've created a test with a custom subclass of `interactive.Global` that allows precise, deterministic control of when this happens. It overrides `signalDone`, which is called after each tree is typechecked, and watches for a defintion with a well known name. At that point, it triggers a targetted typecheck of the tree marked with a special comment. It is likely that this approach can be generalized to a reusable base class down the track. In particular, I expect that some of the nasty interactive ScalaDoc bugs could use this single-threaded approach to testing the presentation compiler.
| * | | SI-8941 Idempotent presentation compilation of implicit classesJason Zaugg2014-10-283-7/+17
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we name an implicit class, `enterImplicitWrapper` is called, which enters the symbol for the factory method into the owning scope. The tree defining this factory method is stowed into `unit.synthetics`, from whence it will be retrieved and incorporated into the enclosing tree during typechecking (`addDerivedTrees`). The entry in `unit.synthetics` is removed at that point. However, in the presentation compiler, we can typecheck a unit more than once in a single run. For example, if, as happens in the enclosed test, a call to ask for a type at a given position interrupts type checking of the entire unit, we can get into a situation whereby the first type checking invocation has consumed the entry from `unit.synthetics`, and the second will crash when it can't find an entry. Similar problems have been solved in the past in `enterExistingSym` in the presentation compiler. This method is called when the namer encounters a tree that already has a symbol attached. See 0b78a0196 / 148736c3df. This commit takes a two pronged approach. First, `enterExistingSym` is extended to handle implicit classes. Any previous factory method in the owning scope is removed, and `enterImplicitWrapper` is called to place a new tree for the factory into `unit.synthetics` and to enter its symbol into the owning scope. Second, the assertions that could be tripped in `addDerivedTrees` and in `ImplicitClassWrapper#derivedSym` have been converted to positioned errors. The first change is sufficient to fix this bug, but the second is also enough to make the enclosed test pass, and has been retained as an extra layer of defence.
* | | Merge pull request #4043 from retronym/ticket/3439-2Jason Zaugg2014-11-023-4/+12
|\ \ \ | | | | | | | | SI-3439 Fix use of implicit constructor params in super call
| * | | SI-3439 Fix use of implicit constructor params in super callJason Zaugg2014-10-103-4/+12
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When typechecking the primary constructor body, the symbols of constructor parameters of a class are owned by the class's owner. This is done make scoping work; you shouldn't be able to refer to class members in that position. However, other parts of the compiler weren't so happy about this arrangement. The enclosed test case shows that our checks for invalid, top-level implicits was spuriously triggered, and implicit search itself would fail. Furthermore, we had to hack `Run#compiles` to special case top-level early-initialized symbols. See SI-7264 / 86e6e9290. This commit: - introduces an intermediate local dummy term symbol which will act as the owner for constructor parameters and early initialized members - adds this to the `Run#symSource` map if it is top level - simplifies `Run#compiles` accordingly - tests this all in a top-level class, and one nested in another class.
* | | Merge pull request #4076 from retronym/ticket/8934Jason Zaugg2014-11-021-5/+4
|\ \ \ | | | | | | | | SI-8934 Fix whitebox extractor macros in the pres. compiler
| * | | SI-8934 Fix whitebox extractor macros in the pres. compilerJason Zaugg2014-10-271-5/+4
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code that "aligns" patterns and extractors assumes that it can look at the type of the unapply method to figure the arity of the extractor. However, the result type of a whitebox macro does not tell the whole story, only after expanding an application of that macro do we know the result type. During regular compilation, this isn't a problem, as the macro application is expanded to a call to a synthetic unapply: { class anon$1 { def unapply(tree: Any): Option[(Tree, List[Treed])] } new anon$1 }.unapply(<unapply selector>) In the presentation compiler, however, we now use `-Ymacro-expand:discard`, which expands macros only to compute the type of the application (and to allow the macro to issue warnings/errors). The original application is retained in the typechecked tree, modified only by attributing the potentially-sharper type taken from the expanded macro. This was done to improve hyperlinking support in the IDE. This commit passes `sel.tpe` (which is the type computed by the macro expansion) to `unapplyMethodTypes`, rather than using the `finalResultType` of the unapply method. This is tested with a presentation compiler test (which closely mimics the reported bug), and with a pos test that also exercises `-Ymacro-expand:discard`. Prior to this patch, they used to fail with: too many patterns for trait api: expected 1, found 2
* | | Merge pull request #4040 from retronym/ticket/8871Jason Zaugg2014-11-023-28/+15
|\ \ \ | |/ / |/| | FSC / REPL Bug Bonanza
| * | SI-6613 Make Java enums work in FSC / REPLJason Zaugg2014-10-091-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We needed to hop from the enum's owner to its companion module in an early phase of the compiler. The enclosed test used to fail when this lookup returned NoSymbol on the second run of the resident compiler when triggered from `MixinTransformer`: the lookup didn't work after the flatten info transform. This is related to the fact that module classes are flattened into the enclosing package, but module accessors remain in the enclosing class.
| * | SI-5583 Remove the workaround for specialization bugJason Zaugg2014-10-091-13/+6
| | | | | | | | | | | | | | | | | | 08505bd added a workaround for an undiagnosed interaction between resident compilation and specialzation. This is no longer needed after the previous commit.
| * | SI-8871 Fix specialization under REPL / FSCJason Zaugg2014-10-092-13/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The transformation of applications to specialized methods relies on the owner of said method having had the specialization info transform run which stashes a bunch of related data into per-run caches such as `SpecializeTypes#{typeEnv}`. Recently, we found that per-run caches didn't quite live up to there name, and in fact weren't being cleaned up before a new run. This was remedied in 00e11ff. However, no good deed goes unpunished, and this led to a regression in specialization in the REPL and FSC. This commit makes two changes: - change the specialization info tranformer to no longer directly enter specialized methods into the `info` of whatever the current phase happens to be. This stops them showing up `enteringTyper` of the following run. - change `adaptInfos` to simply discard all but the oldest entry in the type history when bringing a symbol from one run into the next. This generalizes the approach taken to fix SI-7801. The specialization info transformer will now execute in each run, and repopulate `typeEnv` and friends. I see that we have a seemingly related bandaid for this sort of problem since 08505bd4ec. In a followup, I'll try to revert that.
* | | Merge pull request #4049 from lrytz/t8900Grzegorz Kossakowski2014-10-201-4/+4
|\ \ \ | | | | | | | | SI-8900 Don't assert !isDelambdafyFunction, it may not be accurate
| * | | SI-8900 Don't assert !isDelambdafyFunction, it may not be accurateLukas Rytz2014-10-151-4/+4
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The implementations of isAnonymousClass, isAnonymousFunction, isDelambdafyFunction and isDefaultGetter check if a specific substring (eg "$lambda") exists in the symbol's name. SI-8900 shows an example where a class ends up with "$lambda" in its name even though it's not a delambdafy lambda class. In this case the conflict seems to be introduced by a macro. It is possible that the compiler itself never introduces such names, but in any case, the above methods should be implemented more robustly. This commit is band-aid, it fixes one specific known issue, but there are many calls to the mentioned methods across the compiler which are potentially wrong. Thanks to Jason for the test case!
* | | Merge pull request #4067 from lrytz/t8926Grzegorz Kossakowski2014-10-201-4/+11
|\ \ \ | | | | | | | | SI-8926 default visbility RUNTIME for java annotations
| * | | SI-8926 default visbility RUNTIME for java annotationsLukas Rytz2014-10-201-4/+11
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When parsed from source, java annotation class symbol are lacking the `@Retention` annotation. In mixed compilation, java annotations are therefore emitted with visibility CLASS. This patch conservatively uses the RUNTIME visibility in case there is no @Retention annotation. The real solution is to fix the Java parser, logged in SI-8928.
* | | Merge pull request #4048 from lrytz/t8899Grzegorz Kossakowski2014-10-202-14/+12
|\ \ \ | | | | | | | | [nomerge] SI-8899 Revert "SI-8627 make Stream.filterNot non-eager"
| * | | [nomerge] SI-8899 Revert "SI-8627 make Stream.filterNot non-eager"Lukas Rytz2014-10-122-14/+12
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 9276a1205f74fdec74206209712831913e93f359. The change is not binary compatible, See discussion on SI-8899. Making filterImpl non-private changes its call-sites (within TraversableLike) from INVOKESTATIC to INVOKEINTERFACE. Subclasses of TraversableLike compiled before this change don't have a mixin for filterImpl.
* / / SI-8907 Don't force symbol info in isModuleNotMethodLukas Rytz2014-10-152-24/+27
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | Test case by Jason. RefChecks adds the lateMETHOD flag lazily in its info transformer. This means that forcing the `sym.info` may change the value of `sym.isMethod`. 0ccdb151f introduced a check to force the info in isModuleNotMethod, but it turns out this leads to errors on stub symbols (SI-8907). The responsibility to force info is transferred to callers, which is the case for other operations on symbols, too.
* | Merge pull request #4038 from adriaanm/t8894v2.11.3Grzegorz Kossakowski2014-10-092-2/+2
|\ \ | | | | | | SI-8894 dealias when looking at tuple components
| * | SI-8894 dealias when looking at tuple componentsAdriaan Moors2014-10-082-2/+2
| | | | | | | | | | | | | | | | | | | | | Classic bait-and-switch: `isTupleType` dealiases, but `typeArgs` does not. When deciding with `isTupleType`, process using `tupleComponents`. Similar for other combos. We should really enforce this using extractors, and only decouple when performance is actually impacted.
* | | Merge pull request #3993 from puffnfresh/feature/color-replGrzegorz Kossakowski2014-10-095-5/+49
|\ \ \ | | | | | | | | Color REPL under -Dscala.color
| * | | Use color REPL after writing a defBrian McKenna2014-10-071-10/+19
| | | |
| * | | Add color to severity in REPL reporterBrian McKenna2014-09-242-1/+19
| | | | | | | | | | | | | | | | | | | | * Errors are red * Warnings are yellow
| * | | Color REPL under -Dscala.colorBrian McKenna2014-09-213-2/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We already use -Dscala.color when using -Ytyper-debug This tries to reuse the colors chosen from the debug flag: * Bold blue for vals (e.g. "res0") * Bold green for types (e.g. "Int") * Magenta for the shell prompt (e.g. "scala>")
* | | | SI-8890 handle reference to overload with errorAdriaan Moors2014-10-091-16/+25
| |/ / |/| | | | | | | | | | | | | | | | | When buffering, we must report the ambiguity error to avoid a stack overflow. When the error refers to erroneous types/symbols, we don't report it directly to the user, because there will be an underlying error that's the root cause.
* | | Merge pull request #4032 from dturner-tw/dturner/scaldoc-exit-codeGrzegorz Kossakowski2014-10-071-9/+11
|\ \ \ | | | | | | | | Make Scaladoc actually exit with non-zero exit code in case of errors, as its docs say it does
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-31 14:55:29 +0000