summaryrefslogtreecommitdiff
path: root/src/compiler
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #2497 from scalamacros/topic/macro-qqqJason Zaugg2013-05-173-21/+33
|\ | | | | easy way of writing not implemented macros
| * easy way of writing not implemented macrosEugene Burmako2013-05-123-21/+33
| | | | | | | | | | | | Even though it's easy to mark regular method bodies as stubs (using ???), there's no simple way of doing the same for macro methods. This patch fixes the inconvenience.
* | Fix for unreachable code warning.Paul Phillips2013-05-161-2/+1
| | | | | | | | Oops, I miss when unreachable code was an error.
* | Merge pull request #2537 from adriaanm/ticket-5886Paul Phillips2013-05-161-22/+1
|\ \ | | | | | | SI-5886 Remove check for packed type conformance.
| * | SI-5886 Remove check for packed type conformance.Jason Zaugg2013-05-151-22/+1
| |/ | | | | | | | | | | | | Nothing breaks. Why did by-name arguments have this extra check? What's the difference to a () => T? The check was added originally in 8414eba.
* / Actual SI-6555 fix, Scaladoc filter works WITH keyboard shortcuts tooHeather Miller2013-05-121-7/+10
|/ | | | | | | | | | | | | | | | | | | | | | | | | | Commit daefab18b8b0c170c372991022357413ec69b2af attempted to fix a bug related to Scaladoc filtering, meanwhile breaking Scaladoc keyboard shortcuts. Before commit daefab18b8b0c170c372991022357413ec69b2af, Scaladoc's filter wouldn't consider the last character of a search term entered into the (left) Scaladoc filter pane, but toggling with the `tab` key between filter panes did work. After daefab18b8b0c170c372991022357413ec69b2af, Scaladoc's left pane filter correctly searches for the full search term, but pressing the `tab` key causes the "focus" of the input bar to be stuck on the filter panel in the right Scaladoc filter pane, rendering it useless. End result: annoying Scaladoc interface bug present in 2.10.1, but which wasn't present in 2.10.0. This pull request fixes this, enabling both behaviors. The `tab` key toggle needed to be triggered on a `keydown` event (currently it's not), while everything else is fine to be triggered on a `keyup` event. This pull request enables the correct behavior by binding both a `keydown` and a `keyup` event rather than lumping everything all together in a `keyup` event (as was the case before).
* Merge pull request #2494 from scalamacros/ticket/5923Eugene Burmako2013-05-1112-69/+248
|\ | | | | makes sense of implicit macros!
| * [nomaster] removes duplication in inferImplicitValueEugene Burmako2013-05-113-50/+28
| | | | | | | | Shame-driven development at its best.
| * [nomaster] SI-7166 catches DivergentImplicit in c.inferImplicitXXXEugene Burmako2013-05-112-20/+38
| | | | | | | | | | | | | | | | | | Despite inferImplicit usually being nice and buffering errors, apparently it can also throw DivergentImplicit exception. This patch catches it and only reports it if silent is set to false. NOTE: we no longer have the DivergentImplicit exception in master, so this commit only makes sense in 2.10.x.
| * [nomaster] SI-7047 fixes silent for c.inferImplicitXXXEugene Burmako2013-05-112-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | silent = true now throws a TypecheckException even if we don't know why an implicit search has failed (i.e. if context.hasErrors is false). NOTE: this commit is a part of a pull request for 2.10.x, which makes sense of implicit macros. Everything in that pull request is [nomaster] due to one reason or another. This commit would work equally well in both 2.10.x and master, but I'm marking it as [nomaster] as well, because I'm anyway going to resubmit the whole pull request into master soon, so there's no reason to introduce additional confusion.
| * [nomaster] SI-7291: No exception throwing for diverging implicit expansionHubert Plociniczak2013-05-115-13/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we don't throw exceptions for normal errors it was a bit odd that we don't do that for DivergingImplicit. As SI-7291 shows, the logic behind catching/throwing exception was broken for divergence. Instead of patching it, I rewrote the mechanism so that we now another SearchFailure type related to diverging expansion, similar to ambiguous implicit scenario. The logic to prevent diverging expansion from stopping the search had to be slightly adapted but works as usual. The upside is that we don't have to catch diverging implicit for example in the presentation compiler which was again showing that something was utterly broken with the exception approach. NOTE: This is a partial backport of https://github.com/scala/scala/pull/2428, with a fix for SI-7291, but without removal of error kinds (the former is absolutely necessary, while the latter is nice to have, but not a must, therefore I'm not risking porting it to 2.10.x). Also, the fix for SI-7291 is hidden behind a flag named -Xdivergence211 in order not to occasionally break the code, which relies on pre-fix behavior.
| * [nomaster] SI-7167 implicit macros decide what is divergenceEugene Burmako2013-05-115-14/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Imagine a macro writer which wants to synthesize a complex implicit Complex[T] by making recursive calls to Complex[U] for its parts. E.g. if we have `class Foo(val bar: Bar)` and `class Bar(val x: Int)`, then it's quite reasonable for the macro writer to synthesize Complex[Foo] by calling `inferImplicitValue(typeOf[Complex[Bar])`. However if we didn't insert `info.sym.isMacro` check in `typedImplicit`, then under some circumstances (e.g. as described in http://groups.google.com/group/scala-internals/browse_thread/thread/545462b377b0ac0a) `dominates` might decide that `Bar` dominates `Foo` and therefore a recursive implicit search should be prohibited. Now when we yield control of divergent expansions to the macro writer, what happens next? In the worst case, if the macro writer is careless, we'll get a StackOverflowException from repeated macro calls. Otherwise, the macro writer could check `c.openMacros` and `c.openImplicits` and do `c.abort` when expansions are deemed to be divergent. Upon receiving `c.abort` the typechecker will decide that the corresponding implicit search has failed which will fail the entire stack of implicit searches, producing a nice error message provided by the macro writer. NOTE: the original commit from macro paradise also introduced a new class, which encapsulates information about implicits in flight. Unfortunately we cannot do that in 2.10.x, because of binary compatibility concerns, therefore I'm marking this commit as [nomaster] and will be resubmitting its full version in a separate pull request exclusively targetting master.
| * [nomaster] macroExpandAll is now triggered in all invocations of typedEugene Burmako2013-05-112-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | macroExpandAll is the key player in the mechanism of expanding macros after their type arguments have been inferred. (Macro applications that contain yet uninferred type arguments don't get expanded and are delayed until the targs are inferred. Therefore later on we need to trigger those delayed expansions manually, which is done by macroExpandAll). Previously macroExpandAll was only called from a few selected places in the typechecker, but that's quite risky, since typer evolves, and who knows when this scheme breaks. To make things more robust, I'm now calling macroExpandAll in the epilogue of every single call to `typed`. Don't worry - this shouldn't impose noticeable performance penalties, since the call is guarded by a branch upon a plain boolean field. NOTE: This patch is a second take on fixing implicit macros, with the first one being a backport from macro paradise merged into master in January 2013: https://github.com/scala/scala/commit/fe60284769. The original fix had an unfortunate error, as described on scala-internals: https://groups.google.com/forum/#!msg/scala-internals/7pA9CiiD3u8, so I had to refine the approach here. This means that it's not possible to directly merge this commit into master, so I'm marking it as [nomaster] and will submit a separate pull request targetting master later on.
| * [nomaster] SI-5923 instantiates targs in deferred macro applicationsEugene Burmako2013-05-113-11/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Amazingly enough, the fix for the "macro not expanded" problem was super easy. (And I remember spending a day or two trying to find a quick fix somewhen around Scala Days 2012!) The problem was in the implementation of the macro expansion trigger, which was buried in a chain of if-elif-elif in `adapt`. This meant that macro expansion was mutually exclusive with a lot of important adaptations, e.g. with `instantiate`. More precisely, if an expandee contains an undetparam, its expansion should be delayed until all its undetparams are inferred and then retried later. Sometimes such inference can only happen upon a call to instantiate in one of the elif's coming after the macro expansion elif. However this elif would never be called for expandees, because control flow would always enter the macro expansion branch preceding the inference branch. Therefore `macroExpand` now takes the matters in its own hands, calling `instantiate` if the expansion has been delayed and we're not in POLYmode (see a detailed explanation in a comment to `macroExpand`). Consequences of this fix are vast. First of all, we can get rid of the "type parameter must be specified" hack. Secondly and most importantly, we can now remove the `materializeImplicit` method from Implicits and rely on implicit macros to materialize tags for us. (This is a tricky change, and I'll do it later after we merge as much of my pending work as possible). Finally, we learn that the current scheme of interaction between macros, type inference and implicits is, in principle, sound! NOTE: This patch is a second take on fixing implicit macros, with the first one being a backport from macro paradise merged into master in January 2013: https://github.com/scala/scala/commit/fe60284769. The original fix had an unfortunate error, as described on scala-internals: https://groups.google.com/forum/#!msg/scala-internals/7pA9CiiD3u8, so I had to refine the approach here. This means that it's not possible to directly merge this commit into master, so I'm marking it as [nomaster] and will submit a separate pull request targetting master later on.
* | Merge pull request #2505 from scalamacros/topic/macrosPaul Phillips2013-05-112-21/+23
|\ \ | |/ |/| some fixes for macros: one esoteric, and one quite critical
| * pull request feedbackEugene Burmako2013-05-111-5/+7
| |
| * removes the traces of always on debug diagnosticsEugene Burmako2013-05-092-21/+21
| | | | | | | | pun intended
* | Merge pull request #2456 from paulp/pr/jdk8-210xGrzegorz Kossakowski2013-05-113-2/+12
|\ \ | | | | | | SI-7398 Add support for java8 default methods
| * | SI-7398 Add support for java8 default methodsPaul Phillips2013-04-263-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In classfile parser: mark symbols which represent interface methods yet have code attributes with new flag DEFAULTMETHOD. These must be kept distinct from regular method bodies so that an error can be issued when a regular concrete method is overridden without the override keyword, but not when the overridden method is a default. In java source parser: mark Modifiers of interface default methods with DEFAULTMETHOD flag. Writing the test was everything I dreamed, and more! However, % test/partest --debug test/files/run/t7398.scala Skipping java8-specific test under java version 1.7.0_21 testing: [...]/files/run/t7398.scala [ OK ] All of 1 tests were successful (elapsed time: 00:00:04) % test/partest --debug test/files/run/t7398.scala Attempting java8-specific test under java version 1.8.0-ea testing: [...]/files/run/t7398.scala [ OK ] All of 1 tests were successful (elapsed time: 00:00:13)
* | | Merge pull request #2461 from scalamacros/ticket/7325Paul Phillips2013-05-103-58/+81
|\ \ \ | | | | | | | | Some fixes for string interpolation
| * | | literal() now assigns a position to the tree it producesEugene Burmako2013-05-041-31/+32
| | | | | | | | | | | | | | | | | | | | | | | | At all its callsites except for a single one, the results of literal() were wrapped in atPos(in.offset), so the simplification was pretty much warranted. Thanks @paulp
| * | | SI-7325 cleans up corner cases of percent handling in StringContext.fEugene Burmako2013-05-041-29/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See comments in code for the exhaustive list of the cases handled. Also note that treatment of non-formatting percents has been changed. Embedding literal %'s now requires escaping. Moreover, this commit also features exact error positions for string interpolation, something that has been impossible until the fix for SI-7271, also included in this patch.
| * | | SI-7271 fixes positions of string interpolation partsEugene Burmako2013-04-272-2/+4
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | Positions of static parts are now set explicitly during parsing rather than filled in wholesale during subsequent atPos after parsing. I also had to change the offsets that scanner uses for initial static parts of string interpolations so that they no longer point to the opening double quote, but rather to the actual beginning of the part.
* | | Merge pull request #2458 from paulp/issue/7426-210Grzegorz Kossakowski2013-05-101-1/+0
|\ \ \ | | | | | | | | SI-7426 Crash in pickler.
| * | | SI-7426 Crash in pickler.Paul Phillips2013-04-261-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I wonder if the supply of copy-pasted code, and the bugs which always accompany it, will ever run low. Here we have a couple hundred lines of tree traversal which appears roughly identical in structure to a different couple hundred lines of tree traversal, except one calls methods called putXXX and the other calls methods called writeXXX. Except there was one call to writeXXX among all the putXXX calls. Guess where it was crashing. This entire file should be expunged.
* | | | Merge pull request #2473 from paulp/pr/2.10.2/5634Paul Phillips2013-05-101-32/+21
|\ \ \ \ | | | | | | | | | | SI-5634 eliminate overly verbose error message
| * | | | SI-5634 eliminate overly verbose error messagePaul Phillips2013-04-301-32/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In fact I couldn't see where the error message described in the ticket is being produced, and I'm supposing it has already vacated the premises. I went through ClassfileParser and UnPickler, the two enclaves most likely to harbor the spewer, and hardened the output. No printlns, tighter assertion messages, and string interpolation for aesthetics. We're not savages.
* | | | | Merge pull request #2488 from paulp/issue/7441Paul Phillips2013-05-101-6/+15
|\ \ \ \ \ | |_|_|_|/ |/| | | | SI-7441 Don't ramble on about inapplicable implicits.
| * | | | SI-7441 Don't ramble on about inapplicable implicits.Paul Phillips2013-05-021-6/+15
| | | | |
* | | | | Merge pull request #2472 from paulp/pr/2.10.2/7385Paul Phillips2013-05-072-4/+8
|\ \ \ \ \ | | | | | | | | | | | | SI-7385 crash in erroneous code
| * | | | | SI-7385 crash in erroneous codePaul Phillips2013-04-302-4/+8
| | |/ / / | |/| | | | | | | | | | | | | Less crashing, more emitting errors.
* | | | | Merge pull request #2487 from paulp/issue/6091Paul Phillips2013-05-071-2/+6
|\ \ \ \ \ | | | | | | | | | | | | SI-6091 overeager warning for reference equality
| * | | | | SI-6091 overeager warning for reference equalityPaul Phillips2013-05-021-2/+6
| | |/ / / | |/| | | | | | | | | | | | | Don't warn on eq and ne unless they're the real eq or ne.
* | | | | Merge pull request #2440 from retronym/ticket/6771Adriaan Moors2013-05-031-1/+3
|\ \ \ \ \ | |/ / / / |/| | | | SI-6771 Alias awareness for checkableType in match analysis.
| * | | | SI-6771 Alias awareness for checkableType in match analysis.Jason Zaugg2013-04-241-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Failure to dealias the type of the scrutinee led the pattern matcher to incorrectly reason about the type test in: type Id[X] = X; (null: Id[Option[Int]]) match { case Some(_) => } Before, `checkableType` returned `Id[?]`, now it returns `Some[?]`.
* | | | | Merge pull request #2432 from retronym/ticket/delayed-init-refPaul Phillips2013-04-301-0/+11
|\ \ \ \ \ | |_|/ / / |/| | | | Warn on selection of vals from DelayedInit subclasses.
| * | | | Warn on selection of vals from DelayedInit subclasses.Jason Zaugg2013-04-231-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Which are likely to yield null, if the program didn't start. This is a common source of confusion for people new to the language, as was seen during the Coursera course. The test case shows that the usage pattern within Specs2 won't generate these warnings.
* | | | | Merge pull request #2439 from retronym/ticket/7369Adriaan Moors2013-04-271-11/+28
|\ \ \ \ \ | |_|_|/ / |/| | | | SI-7369 Avoid spurious unreachable warnings in patterns
| * | | | SI-7369 Avoid spurious unreachable warnings in patternsJason Zaugg2013-04-241-11/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unreachability analysis draws on the enumerated domain of types (e.g sealed subclasses + null, or true/false), and also looks at all stable identifier patterns tested for equality against the same 'slot' in a pattern. It was drawing the wrong conclusions about stable identifier patterns. Unlike the domain constants, two such values may hold the same value, so we can't assume that matching X precludes matching Y in the same slot in a subsequent case. For example: val X: Boolean = true; val Y: Boolean = true def m1(t1: Tuple1[Boolean]) = t1 match { case Tuple1(true) => case Tuple1(false) => case Tuple1(false) => // correctly unreachable } def m2(t1: Tuple1[Boolean]) = t1 match { case Tuple1(X) => case Tuple1(Y) => // spurious unreachable warning } // // Before // reachability, vars: V2: Boolean ::= true | false// Set(false, Y, X, true) // = x1._1 V1: (Boolean,) ::= null | ... // = x1 equality axioms: V2=true#4 \/ V2=false#5 /\ -V2=false#5 \/ -V2=Y#3 /\ -V2=false#5 \/ -V2=X#2 /\ -V2=false#5 \/ -V2=true#4 /\ -V2=Y#3 \/ -V2=X#2 /\ -V2=Y#3 \/ -V2=true#4 /\ -V2=X#2 \/ -V2=true#4 // // After // reachability, vars: V2: Boolean ::= true | false// Set(false, Y, X, true) // = x1._1 V1: (Boolean,) ::= null | ... // = x1 equality axioms: V2=true#4 \/ V2=false#5 /\ -V2=false#5 \/ -V2=true#4
* | | | | Merge pull request #2392 from vigdorchik/ticket/si-7367Paul Phillips2013-04-262-27/+29
|\ \ \ \ \ | |_|_|_|/ |/| | | | SI-7367 scaladoc crash on constructing the model for annotations.
| * | | | SI-7367 scaladoc crash on constructing the model for annotations.Eugene Vigdorchik2013-04-252-27/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Scaladoc only checks primary constructor when building annotation model. Here we instead find the constructor matching the annotation's symbol. Also change TreeFactory.makeTree to return TreeEntity rather than Option[TreeEntity] and force the caller check for EmptyTree.
* | | | | SI-6943 warn on value class miscomparison.Paul Phillips2013-04-241-9/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's a very dangerous situation running around when you combine universal equality with value classes: // All over your code val x = "abc" if (x == "abc") ... // Hey let's make x a value class val x = new ValueClass("abc") // Uh-oh There was until now no warning when comparing a value class with something else. Now there is.
* | | | | Merge pull request #2420 from retronym/ticket/6675-2Jason Zaugg2013-04-235-10/+17
|\ \ \ \ \ | | | | | | | | | | | | SI-6675 Avoid spurious warning about pattern bind arity.
| * | | | | SI-6675 Avoid spurious warning about pattern bind arity.Jason Zaugg2013-04-215-10/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 692372ce, we added a warning (under -Xlint) when binding a `TupleN` in to a single pattern binder, which wasn't allowed before 2.10.0, and more often than not represents a bug. However, that warning overstretched, and warned even when using a Tuple Pattern to bind to the elements of such a value. This commit checks for this case, and avoids the spurious warnings. A new test case is added for this case to go with the existing test for SI-6675: $ ./tools/partest-ack 6675 % tests-with-matching-paths ... 3 % tests-with-matching-code ... 2 # 3 tests to run. test/partest --show-diff --show-log \ test/files/neg/t6675-old-patmat.scala \ test/files/neg/t6675.scala \ test/files/pos/t6675.scala \ "" Testing individual files testing: [...]/files/pos/t6675.scala [ OK ] Testing individual files testing: [...]/files/neg/t6675-old-patmat.scala [ OK ] testing: [...]/files/neg/t6675.scala [ OK ] All of 3 tests were successful (elapsed time: 00:00:03)
* | | | | | SI-7355 Handle spaces in paths in Windows batch files.Bjorn Regnell2013-04-231-2/+3
| |_|_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Changed "%1%" and %2% to "%~1" and %~2 to allow spaces in paths by surrounding quotes according to advice at: http://stackoverflow.com/questions/473117/pass-path-with-spaces-as-parameter-to-bat-file http://ss64.com/nt/syntax-args.html
* | | | | Merge pull request #2387 from vigdorchik/interactive_scaladocAdriaan Moors2013-04-221-2/+4
|\ \ \ \ \ | |_|_|/ / |/| | | | Interactive scaladoc: demand new typer run when done.
| * | | | Interactive scaladoc: mark new typer run when done.Eugene Vigdorchik2013-04-171-2/+4
| | |/ / | |/| | | | | | | | | | | | | | As of now, when backgroundCompile is in the same typer run as scaladoc-fetching logic, typer is confused with stale symbols.
* | | | Merge pull request #2358 from adriaanm/ticket-7330Jason Zaugg2013-04-213-28/+30
|\ \ \ \ | | | | | | | | | | SI-7330 better error when pattern's not a value
| * | | | SI-7330 better error when pattern isn't a valueAdriaan Moors2013-04-083-28/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Somehow an applied type managed to sneak past the type checker in pattern mode. Patterns must be values, though. `case C[_] =>` was probably meant to be `case _: C[_] =>` Advice is dispensed accordingly. (Generalizing the existing advice machinery.)
* | | | | Merge pull request #2410 from paulp/pr/parameterized-implicitJason Zaugg2013-04-211-4/+5
|\ \ \ \ \ | |_|_|_|/ |/| | | | Quiet down overloaded implicit warning.
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-05 22:50:17 +0000