summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Update quasiquote debug output minimization passDenys Shabalin2014-03-091-1/+1
|
* SI-8385 make sure $quasiquote$tuple gets reified properlyDenys Shabalin2014-03-091-0/+4
| | | | | | Previously due to greediness of SyntacticApplied there was a chance that quasiquote tuple placeholder got reified as its representation rather than its meaning.
* Merge pull request #3610 from xeno-by/ticket/8369Jason Zaugg2014-03-081-1/+2
|\ | | | | SI-8369 resetAttrs now correctly accounts for skolems
| * SI-8369 resetAttrs now correctly accounts for skolemsEugene Burmako2014-03-071-1/+2
| | | | | | | | | | resetAttrs (née resetLocalAttrs) has been oblivious to existence of skolems. Not anymore, which prevents us from reverting to the untyper nightmare.
* | SI-8372: unspliceable type printed in error messageGrzegorz Kossakowski2014-03-071-2/+17
|/ | | | | | | | | | | | | | | | | | | | The b8a76f688c6ce2a4c305da064303bb46b53be875 introduced ArrayOps.{unzip, unzip3} methods. Both of those methods have ClassTags as context bounds on their type parameters so they can create (and return) instances of Arrays. The type inference for those methods is supposed to be guided by implicit evidence that T <: (T1, T2) (or T <: (T1, T2, T3) in unzip3 case). However, context bounds are desugared into implicit parameters that prepended in front of implicit parameters declared in source code. That means the implicit evidence won't have a chance to guide type inference because it comes as last implicit parameter. This commit desugars context bounds and puts them at the end of implicit parameter list. This way type inference is guided properly and we get expected compiler errors for missing class tags. The change to parameters order breaks binary compatibility with respect to 2.11.0-RC1. I added filters to our binary compatibility configuration files. We can get rid of them as soon as 2.11.0 is out.
* No longer generate deprecated dists/maven/latest/build.xmlAdriaan Moors2014-03-031-281/+0
| | | | | The distpack-maven-* targets no longer create said dir/build. Use the publish tasks directly instead.
* Fix typo in log message.Daniel Darabos2014-03-031-1/+1
|
* Merge pull request #3592 from densh/si/8281Eugene Burmako2014-03-031-1/+2
|\ | | | | SI-8281 check for unbound placeholder parameters in quasiquote parser
| * SI-8281 check for unbound placeholder parameters in quasiquote parserDenys Shabalin2014-02-281-1/+2
| |
* | SI-8332 implicit class param unquoting in quasiquotesDenys Shabalin2014-03-023-18/+23
| | | | | | | | | | | | A new api that simplifies handling of implicit parameters has been mistakingly supporting just methods parameters. This commit adds support for class parameters too.
* | Merge pull request #3596 from densh/si/8333Eugene Burmako2014-03-012-4/+6
|\ \ | | | | | | SI-8333 can't use modifiers if class is in a block
| * | SI-8333 can't use modifiers if class is in a blockDenys Shabalin2014-02-282-4/+6
| |/ | | | | | | | | | | Was caused by the ordering of parser cases. Need to check for definition first due to the fact that modifiers unquote looks like identifier from parser point of view.
* | Merge pull request #3593 from densh/si/8285Eugene Burmako2014-03-012-9/+7
|\ \ | | | | | | SI-8285 use correct kind of map for quasiquote positions
| * | SI-8285 use correct kind of map for quasiquote positionsDenys Shabalin2014-02-282-9/+7
| |/ | | | | | | | | | | | | Previously mutable.ListMap was used with assumption that it preserved order of inserted elements (but it doesn't). Surprisingly logic that assumed ordered elements worked mosly fine on unordered ones. I guess two bugs can cancel each other out.
* | Fix block construction/deconstruction asymmetryDenys Shabalin2014-02-283-15/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Deconstruction of blocks in case clauses uncovered asymmetry between construction and deconstruction of blocks: tree match { case cq"$pat => ..$cases" => cq"$pat => ..$cases" } Such an identity-like transformation used to produce an incorrect tree due to the fact that zero-element block was mistakingly associated with empty tree. Such association was used as a solution to block flatenning: val ab = q"a; b" q"..$ab; c" // ==> q"a; b; c" val a = q"a" q"..$a; c" // ==> q"a; c" val empty = q"" q"..$empty; c" // ==> q"c" This commit changes meaning of zero-element block to a be a synthetic unit instead. This is consistent with parsing of `{}`, cases, ifs and non-abstract empty-bodied methods. A local tweak to block flattenning is used to flatten empty tree as empty list instead.
* | SI-8275 allow to directly extract block contents of the case defDenys Shabalin2014-02-282-0/+3
|/ | | | | Due to the fact that blocks in cases are implicit one might expect to be able to extract its contents with `..$`.
* Merge pull request #3588 from adriaanm/rebase-3587Adriaan Moors2014-02-2624-82/+160
|\ | | | | Revert "SI-7624 Fix -feature warnings in scala/tools/scalap"
| * Revert "SI-7624 Fix -feature warnings in scala/tools/scalap"Grzegorz Kossakowski2014-02-2624-82/+160
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit f2de2c4ec43180351ef1f306bcc5f24643ba5477 because it broke both lift-json and json4s libraries that depend on scalap's APIs. Arguably, those libraries shouldn't depend on unofficial APIs but they do because they had no better alternative at the time (no Scala reflection). The cost of breaking them is not worth minor change of the package. The f2de2c4ec43180351ef1f306bcc5f24643ba5477 mixed two things: 1. Fixing feature warnings 2. Changing package name When reverting (and resolving conflicts) I tried to keep 1. and revert just 2. However, there were also some questionable changes related to 1. that got reverted. In particular, a package object with implicit members that enable language features is an anti-pattern because members of package object are visible both _within_ and _outside_ of the package. Therefore, user could use wildcard import for importing everything from scalap package and enabled postfixOps language feature unknowingly. I went for just adding imports in just those few files where they were needed. Amended by Adriaan: To allow faster turn around, I re-enabled resolving partest from sonatype, as its version needs to be bumped and I don't want to wait for maven central synch. Conflicts: src/partest/scala/tools/partest/nest/Runner.scala src/scalap/scala/tools/scalap/scalax/rules/Memoisable.scala src/scalap/scala/tools/scalap/scalax/rules/Rule.scala src/scalap/scala/tools/scalap/scalax/rules/Rules.scala src/scalap/scala/tools/scalap/scalax/rules/scalasig/ClassFileParser.scala src/scalap/scala/tools/scalap/scalax/rules/scalasig/ScalaSig.scala
* | Selectively revert "SI-8315 Better debugging facility for ICode"Adriaan Moors2014-02-261-2/+4
|/ | | | | | This reverts commit 0561dd084b5f3c2678eb032a40b85cb25bb6d589, because appending the phase name to the icode filename breaks the windows build. Only doing it under -Ydebug.
* Merge pull request #3583 from adriaanm/t8197Adriaan Moors2014-02-252-15/+48
|\ | | | | SI-8197 clarify overloading resolution with default args
| * SI-8197 clarify overloading resolution with default argsAdriaan Moors2014-02-252-15/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit was co-authored with Lukas. His analysis is below. If there are multiple applicable alternatives, drop those that use default arguments. This is done indirectly by checking applicability based on arity. TODO: this `namesMatch` business is not spec'ed, and is the wrong fix for SI-4592. We should instead clarify what the spec means by "typing each argument with an undefined expected type". What does typing a named argument entail when we don't know what the valid parameter names are? (Since we're doing overload resolution, there are multiple alternatives that can define different names.) Luckily, the next step checks applicability to the individual alternatives, so it knows whether an assignment is: - a valid named argument - a well-typed assignment (which doesn't necessarily have type `Unit`!) - an error (e.g., rhs does not refer to a variable) I propose the following solution (as a TODO): check whether a named argument (when typing it in `doTypedApply`) could be interpreted as an assign; `infer.checkNames` should use the type of the well-typed assignment instead of `Unit`. Lukas's analysis: 990fa04 misunderstood the spec of overloading resolution with defaults. it should not discard applicable alternatives that define defaults, but only those that use defaults in the given invocation. bugs were shadowed because the refactoring used `alt.hasDefault` to check whether the alternative has some parameters with defaults, but this never worked. d5bb19f fixed that part by checking the flags of parameters, which fixed some but but un-shadowed others: ``` object t { def f(x: String = "") = 1; def f(x: Object) = 2 } scala> t.f("") // should return 1, but returns 2 after d5bb19f ``` The commit message of d5bb19f also mentions that its test "should fail to compile according to SI-4728", which is another misunderstanding. ``` class A; class B extends A object t { def f(x: A = null) = 1; def f(x: B*) = 2 } t.f() ``` This should return `2`: both alternatives are applicable, so the one that uses a default is eliminated, and we're left with the vararg one. SI-4728 is different in that it uses explicit parameters, `t.f(new B)` is ambiguous.
* | Merge pull request #3581 from Ichoran/issue/3235-minimalAdriaan Moors2014-02-253-3/+21
|\ \ | | | | | | SI-3235 math.round() returns wrong results for Int and Long
| * | SI-3235 math.round() returns wrong results for Int and LongRex Kerr2014-02-253-3/+21
| | | | | | | | | | | | | | | | | | | | | | | | Minimal fix for SI-3235. This minimal fix includes deprecation messages to aid detection of probable errors. Test verifies behavior: the correct values are returned, and deprecation messages are emitted.
* | | Merge pull request #3498 from Ichoran/issue/8240Grzegorz Kossakowski2014-02-251-9/+92
|\ \ \ | | | | | | | | SI-8240 Consider rolling back optimizations for List
| * | | SI-8240 Consider rolling back optimizations for ListRex Kerr2014-02-251-9/+92
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some compiler-specific optimizations turn out to be very helpful for Lists in general. * List map can be a lot faster (up to 5x!) * List collect can be considerably faster (up to 3x) * List flatMap can be a bit faster (2x) * List take can be slightly faster (1.1x) and have better structural sharing These appear to be unqualified wins (tested), even in a scenario with mixed collections. This is expected: detecting the builder is faster than the otherwise mandatory object creation, and multiple dispatch is mostly a wash since it was already multiple dispatch in getting to the builder. With -optimize, map is not always such a big win, but is never slower. Also added @noinline to map to work around an optimizer bug (SI-8334) and added a test to check that the pattern that triggers the optimizer bug does not affect any of the map-like methods.
* | | Merge pull request #3579 from densh/topic/quasiquotes-scaladocEugene Burmako2014-02-252-7/+58
|\ \ \ | | | | | | | | Add ScalaDoc to Quasiquotes and Liftables parts of api
| * | | Address pull request feedbackDenys Shabalin2014-02-242-3/+3
| | | |
| * | | Add ScalaDoc to Quasiquotes and Liftables parts of apiDenys Shabalin2014-02-242-7/+58
| | | |
* | | | Merge pull request #3582 from adriaanm/t8251Grzegorz Kossakowski2014-02-253-16/+7
|\ \ \ \ | |_|/ / |/| | | SI-8251 deprecate `ListBuffer::readOnly`
| * | | SI-8251 deprecate `ListBuffer::readOnly`Pavel Pavlov2014-02-243-16/+7
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the first step towards fixing the unexpected behavior of `ListBuffer`. Many of `ListBuffer`'s operations are forwarded to the underlying `List`, essentially leaking that abstraction to clients that call e.g., `toIterable`. When the buffer changes, the `Iterable` obtained through `toIterable` will reflect that change. To avoid this exposure, call `toList` to obtain an immutable copy. See also: https://groups.google.com/d/msg/scala-internals/g_-gIWgB8Os/kWazrALbLKEJ https://gist.github.com/paulp/9081797
* | | Merge pull request #3566 from adriaanm/t6455Grzegorz Kossakowski2014-02-252-1/+30
|\ \ \ | |/ / |/| | SI-6455 no longer rewrite .withFilter to .filter
| * | SI-6455 util.Try supports withFilterAdriaan Moors2014-02-241-0/+29
| | |
| * | SI-6455 under -Xfuture, don't rewrite .withFilter to .filterAdriaan Moors2014-02-241-1/+1
| | | | | | | | | | | | | | | This has been deprecated for two major releases now, but `filter`'s still preferred over `withFilter` in the wild.
* | | SI-8330: Mismatch in stack heightsGrzegorz Kossakowski2014-02-241-1/+2
| |/ |/| | | | | | | | | | | | | | | | | | | | | The SI-8233 / 9506d52 missed one case when we need to DROP a null from a stack: when unboxed Unit is an expected type. If we forgot to do that in a context where two branches were involved we could end up with unbalanced stack sizes. Let's fix that omission and a test covering that specific case to the original test for SI-8233. Fixes SI-8330.
* | Merge pull request #3559 from adriaanm/t1503Grzegorz Kossakowski2014-02-233-4/+55
|\ \ | | | | | | SI-1503 don't assume unsound type for ident/literal patterns
| * | SI-1503 don't assume unsound type for ident/literal patternsAdriaan Moors2014-02-193-4/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The fix only kicks in under -Xfuture. We also warn under -Xlint. What type should a variable bound to the value matched by a pattern have? To avoid CCEs, it should be a type that's implied by the matching semantics of the pattern. Usually, the type implied by a pattern matching a certain value is the pattern's type, because pattern matching implies instance-of checks. However, Stable Identifier and Literal patterns are matched using `==`, which does not imply a type for the binder that binds the matched value. The change in type checking due to this fix is that programs that used to crash with a CCE (because we blindly cast to the type of the pattern, which a `==` check does not imply) now get a weaker type instead (and no cast). They may still type check, or they may not. To compensate for this fix, change `case x@Foo => x` to `case x: Foo.type => x`, if it's important that `x` have type `Foo.type`. See also: - SI-4577: matching of singleton type patterns uses `eq`, not `==` (so that the types are not a lie). - SI-5024: patmat strips unused bindings, but affects semantics
* | | Merge pull request #3571 from xeno-by/ticket/8321Adriaan Moors2014-02-234-20/+14
|\ \ \ | | | | | | | | SI-8321 bundles can't be whitebox
| * | | more clean up in the macro engineEugene Burmako2014-02-211-14/+3
| | | | | | | | | | | | | | | | | | | | Now when SI-7507 is fixed in starr, we can actually remove a workaround and make a 10 line reduction in the size of Resolvers.scala.
| * | | more helpful bundle error messagesEugene Burmako2014-02-211-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment, bundle selection mechanism is pretty picky. If a candidate bundle's parameter isn't either blackbox.Context, whitebox.Context or PrefixType refinement thereof, then it's not a bundle and the user will get a generic error. However we can be a bit more helpful and admit classes that are almost like bundles (looksLikeMacroBundleType), have them fail isMacroBundleType, and then emit a much prettier error message to the user that would tell them that bundles must be monomorphic and their sole parameter should not just be any subtype of blackbox.Context or whitebox.Context.
| * | | prohibits polymorphic bundlesEugene Burmako2014-02-212-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | It's not like they were inducing bugs, but I can't see how polymorphism can be useful for macro bundles, hence imho it's better to reduce the number of degrees of freedom of the system.
| * | | bundles now reject invalid context typesEugene Burmako2014-02-211-9/+5
| | | | | | | | | | | | | | | | | | | | Vanilla macros only allow blackbox.Context, whitebox.Context and PrefixType refinements thereof. Bundles should behave in the same way.
| * | | SI-8321 whitebox bundles are now recognized as suchEugene Burmako2014-02-211-2/+6
| | | | | | | | | | | | | | | | | | | | whitebox.Context <: blackbox.Context, so in order to check for blackboxity it's not enough to check whether the context used is <: blackbox.Context.
| * | | minor code cleanup in the macro engineEugene Burmako2014-02-212-3/+3
| | | |
* | | | Merge pull request #3574 from greenrd/SI-7962Adriaan Moors2014-02-231-3/+2
|\ \ \ \ | | | | | | | | | | SI-7962 Scalac runner does not work within Emacs's terminal
| * | | | SI-7962 Scalac runner does not work within Emacs's terminalRobin Green2014-02-221-3/+2
| |/ / / | | | | | | | | | | | | | | | | | | | | - Always set the env.emacs system property - scalac only cares about whether the system property has a non-empty value, not whether it is set or not. Fixes 7962
* | | | Merge pull request #3573 from retronym/ticket/8324Grzegorz Kossakowski2014-02-226-13/+14
|\ \ \ \ | | | | | | | | | | SI-8324 Fix regression in override checks for sealed classes
| * | | | SI-8324 Fix regression in override checks for sealed classesJason Zaugg2014-02-226-13/+14
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | adeffda25 changed `Symbol#isEffectivelyFinal` to help the optimizer by inferring finality within sealed class hierarchies. However, this change wasn't neccesarily welcome for other clients of that method. In the enclosed test case, we see that overriding checks in `RefChecks` regressed. This commit moves the enhanced version into a new method and selectively uses it in the optimizer (and the tail call optimizer).
* | | | Merge pull request #3572 from retronym/ticket/8197Adriaan Moors2014-02-221-1/+2
|\ \ \ \ | | | | | | | | | | SI-8197 Only consider immediate params for defaults, overloading
| * | | | SI-8197 Only consider immediate params for defaults, overloadingJason Zaugg2014-02-221-1/+2
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A recent commit fixed the behaviour of overloading with regards to discarding candiates that include default arguments. The old check was checking the wrong flag. But, the new code is actually checking all parameter lists for defaults, which led to a regression in scala-io, which is distilled in the enclosed test case. Applications are typechecked one parameter list at a time, so a holistic check for defaults doesn't seem to make sense; only defaults in the first parameter list ought to count.
* | | | Merge pull request #3563 from adriaanm/t5479Grzegorz Kossakowski2014-02-222-0/+6
|\ \ \ \ | | | | | | | | | | SI-5479 deprecate DelayedInit outside of App
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-01 01:11:32 +0000