summaryrefslogtreecommitdiff
path: root/src/compiler/scala/tools/nsc/typechecker/Implicits.scala
Commit message (Collapse)AuthorAgeFilesLines
...
* Refactor handling of failures in implicit searchJason Zaugg2014-03-311-18/+24
| | | | | | | | | | Better encapsulation for `DivergentImplicitRecovery` by replacing the vars `countDown` and `implicitSym` with a single var holding `Option[DivergentImplicitTypeError]`. Also adds a pending test for SI-8460 that will be addressed in the next commit. This commit is just groundwork and should not change any results of implicit search.
* SI-8341 Refine handoff of undet. params from implicit searchJason Zaugg2014-03-181-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In SI-7944 / 251c2b93, we discovered that typechecking of an implicit candidate could leave orphaned undetermined type parameters in the implicit search context. This resulted in naked type parameters leaking into implicit expansions. The fix seemed easy: just copy any symbols from `implicitSearchContext.undetparams` to the enclosing context (other than ones in `SearchResult#subst`). However, the test case in this ticket reveals a subtle flaw in that fix: `implicitSerachContext.undetparams` only contains the type params from the most recently typechecked candidate! Why? Implicit search uses the same context to typecheck all plausibly compatible candidates. The typechecking itself is driven by `typedImplicit1`. Side note, that explains the heisenbug behaviour noted in the ticket: Not *all* plausibly implicit candidates are typechecked. If the current 'best' eligible candidate is more specific than the next candidate, we can skip that altogether.Implicit search actually exploits this for performance by ordering the candidates according to usage statistics. This reordering, means that commenting out lines elsewhere in the file changed the behaviour! This commit simply stores the undet. tparams in the `SearchResult`, where it is safe from the vaguries of typechecking other candidates. That makes `Test1` and `Test2` with in the enclosed test case fail uniformly, both with each other, and with an explicit call to the view. This is ostensibly a regression from 2.10.3. To get there, we need an implicit search that has to infer `Nothing` in a covariant position. In 2.10.3, we would just let the `G` out into the wild, which did the right thing for the wrong reasons.
* Merge pull request #3555 from adriaanm/rebase-3553Jason Zaugg2014-02-211-1/+1
|\ | | | | Small Predef cleanup
| * SI-7788 Avoid accidental shadowing of Predef.conformsAdriaan Moors2014-02-181-1/+1
| | | | | | | | | | | | | | Rename `conforms` to `$conforms` and put in a minimal backstop: pos/t7788.scala TODO: predicate the backwards compatibility shim for `Predef_conforms` on `-Xsource:2.10`
* | establishes scala.reflect.api#internalEugene Burmako2014-02-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reflection API exhibits a tension inherent to experimental things: on the one hand we want it to grow into a beautiful and robust API, but on the other hand we have to deal with immaturity of underlying mechanisms by providing not very pretty solutions to enable important use cases. In Scala 2.10, which was our first stab at reflection API, we didn't have a systematic approach to dealing with this tension, sometimes exposing too much of internals (e.g. Symbol.deSkolemize) and sometimes exposing too little (e.g. there's still no facility to change owners, to do typing transformations, etc). This resulted in certain confusion with some internal APIs living among public ones, scaring the newcomers, and some internal APIs only available via casting, which requires intimate knowledge of the compiler and breaks compatibility guarantees. This led to creation of the `internal` API module for the reflection API, which provides advanced APIs necessary for macros that push boundaries of the state of the art, clearly demarcating them from the more or less straightforward rest and providing compatibility guarantees on par with the rest of the reflection API. This commit does break source compatibility with reflection API in 2.10, but the next commit is going to introduce a strategy of dealing with that.
* | SI-6732 deprecates internal#Symbol.isPackageEugene Burmako2014-02-141-2/+2
| | | | | | | | | | | | | | | | This is the first step in disentangling api#Symbol.isPackage, which is supposed to return false for package classes, and internal#Symbol.isPackage, which has traditionally being used as a synonym for hasPackageFlag and hence returned true for package classes (unlike isModule which is false for module classes).
* | Merge remote-tracking branch 'origin/master' into topic/palladium0Eugene Burmako2014-02-141-1/+4
|\|
| * SI-8280 regression in implicit selection.Paul Phillips2014-02-131-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 2fa2db7840 I fixed a bug where applicable implicit conversions would not be found for numeric types if one introduced any aliasing or singleton types, for the usual reasons involving the absence of uniform type normalization. See pos/t7228 for examples - that test case has 20 errors in 2.10.3 but compiles in master. An unintended side effect was making implicit search less oblivious. It turns out that in so doing I had created ambiguity where there was none before. Not because it was any more ambiguous, but because the compiler now had the wits to notice the ambiguity at an earlier time. The fix for this is not intuitive. The way the internal logic is, we need to keep the wool over implicit search's eyes, which leads to those unrecognized types being passed to adapt, where they are recognized and weak subtyping suffices to be more specific. It is sufficient for SI-7228 that weak subtyping be done correctly - the other change, which is reverted here, was exposing the type arguments of Function1 when a view exists as a subtype of Function1. It is also possible this could be remedied by calling weak_<:< somewhere which is presently <:<, but I don't know where and it has a far greater chance of affecting something else than does this, which is a straight reversion of a post-2.10.3 change.
* | proceeds with the quest of removing `local` from namesEugene Burmako2014-02-121-40/+44
|/ | | | | Continuing in the direction set by the parent commit, this commit rephrases some more usages of `local` in names and comments in typer.
* Implicits: Move shadowing checks after plausibility checksJason Zaugg2014-02-011-2/+2
| | | | | Shadowing is rarer than implausbility; this seems to be the most efficient way to order these filters.
* Merge pull request #3416 from retronym/topic/any-val-implicitAdriaan Moors2014-01-301-9/+12
|\ | | | | Prohibit views targeting AnyVal
| * Prohibit views targeting AnyValJason Zaugg2014-01-271-9/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Library changes in Scala 2.10 mean that we are left with the unfortunate situation of admitting: scala> "": AnyVal res0: AnyVal = We already have explicit checks in place to prevent views targeting `AnyRef`. This commit balances this out by prohibiting `AnyVal`, as well. The enclosed test shows that this case is now prevented. If multiple implicits views are applicable, the ambiguity error is still raised; these check comes right at the end. Maybe that ought to be changed, but I don't think it matters too much. I've also disabled this prohibition under -Xsource:2.10.
* | Merge pull request #3368 from retronym/ticket/8151Grzegorz Kossakowski2014-01-211-2/+2
|\ \ | |/ |/| SI-8151 Remove -Yself-in-annots and associated implementation
| * SI-8151 Remove -Yself-in-annots and associated implementationJason Zaugg2014-01-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This experimental option typechecked arguments of annotations with an injected value in scope named `self`: @Foo(self.foo < 1) This has been slated for removal [1] for some time. This commit removes it in one fell swoop, without any attempt at source compatibility with code that constructs or pattern matches on AnnotatedType. [1] https://groups.google.com/d/msg/scala-internals/VdZ5UJwQFGI/C6tZ493Yxx4J
* | SI-8126 Puts SI-6899 fix under a source level flagFrançois Garillot2014-01-161-1/+1
| |
* | *boxContext => *box.Context , *boxMacro => *box.MacroEugene Burmako2014-01-121-1/+1
|/ | | | | | | | | | Performs the following renamings: * scala.reflect.macros.BlackboxContext to scala.reflect.macros.blackbox.Context * scala.reflect.macros.BlackboxMacro to scala.reflect.macros.blackbox.Macro * scala.reflect.macros.WhiteboxContext to scala.reflect.macros.whitebox.Context * scala.reflect.macros.WhiteboxMacro to scala.reflect.macros.whitebox.Macro https://groups.google.com/forum/#!topic/scala-internals/MX40-dM28rk
* Merge pull request #3137 from xeno-by/topic/implicit-macros-invalidate-on-errorAdriaan Moors2013-11-221-0/+2
|\ | | | | correctly fails implicit search for invalid implicit macros
| * correctly fails implicit search for invalid implicit macrosEugene Burmako2013-11-141-0/+2
| | | | | | | | | | | | | | There was a rare corner case when implicit search wouldn’t discard an invalid implicit macro (e.g. the one with mismatching macro impl or the one with macro impl defined in the same compilation run) during typechecking the corresponding candidate in typedImplicit1. This is now fixed.
* | Account for a variation of package types in Implicit Divergence.Jason Zaugg2013-11-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | While debugging pos/t7983.scala, I noticed that: complexity(scala.type): 1 complexity(Int): 2 The intent of the code is that top level classes should have a complexity of one. This commit restores that for cases when we see the prefix type as a ThisType, rather than a SingleType. I can't construct a test case in which this small difference is observable in the divergence checks.
* | Code reformatting in ImplicitsJason Zaugg2013-11-191-16/+10
| | | | | | | | | | | | And use List#sum, rather than a fold. No functional change.
* | SI-7983 Fix regression in implicit divergence checkingJason Zaugg2013-11-191-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As seen in Slick. Regressed in 039b1cb1a5b8. In that commit, a call to `normalize` was replaced with `dealiasWiden` as part of a broad sweeping change. However, while the latter does less than the former with regards to eta expansion ofhigher kinded type refs (the motivation of that commit), it also does more when it comes to singleton types: they are widened to the underlying type. This was widening away `SingleType(<<package a.b>>, <<package c>>)` before the special case assiging that type component a complexity of zero could kick in. In the test case, extracted from Slick, this meant that the divergence check would consider that the second type below to outrank the first in the complexity measure, and abort the implicit search. Shape[?, ? (Coffees, Coffees), ?] Shape[DivergenceTest.this.Flat, ?, Coffees, ?] After this change, the number of packages enclosing `DivergenceTest` no longer has a bearing on the complexity score of the type. Here's how the race was run before hand: complexity(<noprefix>): 0 complexity(<root>): 1 complexity(foo.type): 2 complexity(foo.bar.type): 3 complexity(foo.bar.baz.type): 4 complexity(DivergenceTest.this.type): 5 complexity(<noprefix>): 0 complexity(<root>): 1 complexity(foo.type): 2 complexity(foo.bar.type): 3 complexity(foo.bar.baz.type): 4 complexity(DivergenceTest.this.type): 5 complexity(DivergenceTest.this.Flat): 6 complexity(<noprefix>): 0 complexity(<root>): 1 complexity(scala.type): 2 complexity(Int): 3 complexity(?): 1 complexity(DivergenceTest.this.Shape2[DivergenceTest.this.Flat,Int,?]): 16 complexity(<noprefix>): 0 complexity(<root>): 1 complexity(foo.type): 2 complexity(foo.bar.type): 3 complexity(foo.bar.baz.type): 4 complexity(DivergenceTest.this.type): 5 complexity(?): 1 complexity(<noprefix>): 0 complexity(<root>): 1 complexity(scala.type): 2 complexity(<noprefix>): 0 complexity(Coffees): 1 complexity(<noprefix>): 0 complexity(<root>): 1 complexity(scala.type): 2 complexity(Int): 3 complexity((Coffees, Int)): 7 complexity(?): 1 complexity(DivergenceTest.this.Shape2[?,(Coffees, Int),?]): 15 dominates(DivergenceTest.this.Shape2[_ <: DivergenceTest.this.Flat, Int, U2], DivergenceTest.this.Shape2[_ <: Level, (Coffees, Int), U1]): true And afterwards: complexity(DivergenceTest.this.type): 1 complexity(DivergenceTest.this.type): 1 complexity(DivergenceTest.this.Flat): 2 complexity(scala.type): 1 complexity(Int): 2 complexity(?): 1 complexity(DivergenceTest.this.Shape2[DivergenceTest.this.Flat,Int,?]): 7 complexity(DivergenceTest.this.type): 1 complexity(?): 1 complexity(scala.type): 1 complexity(<noprefix>): 0 complexity(Coffees): 1 complexity(scala.type): 1 complexity(Int): 2 complexity((Coffees, Int)): 5 complexity(?): 1 complexity(DivergenceTest.this.Shape2[?,(Coffees, Int),?]): 9 dominates(DivergenceTest.this.Shape2[_ <: DivergenceTest.this.Flat, Int, U2], DivergenceTest.this.Shape2[_ <: Level, (Coffees, Int), U1]): false Notice that even in the after shot, `scala.Int` has a complexity of 2. It should be 1; this will be fixed in a separate commit.
* blackbox restriction #3: can't affect implicit searchEugene Burmako2013-11-121-20/+21
| | | | | | | | | When an application of a blackbox macro is used as an implicit candidate, no expansion is performed until the macro is selected as the result of the implicit search. This makes it impossible to dynamically calculate availability of implicit macros.
* blackbox and whitebox macrosEugene Burmako2013-11-121-1/+1
| | | | | | | | | | | | | | | | | | This is the first commit in the series. This commit only: 1) Splits Context into BlackboxContext and WhiteboxContext 2) Splits Macro into BlackboxMacro and WhiteboxMacro 3) Introduces the isBundle property in the macro impl binding Here we just teach the compiler that macros can now be blackbox and whitebox, without actually imposing any restrictions on blackbox macros. These restrictions will come in subsequent commits. For description and documentation of the blackbox/whitebox separation see the official macro guide at the scaladoc website: http://docs.scala-lang.org/overviews/macros/blackbox-whitebox.html Some infrastructure work to make evolving macros easier: compile partest-extras with quick so they can use latest library/reflect/...
* SI-7678 Don't cache member symbols of TypeTags in Definitions.Jason Zaugg2013-11-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | It we can only safely use vals in Definitions for top-level symbols. Otherwise, when the IDE switches to loading the symbol from source, we can hold on to a stale symbol, which in turn impedes implicit materialization of TypeTags. This commit moves (most) of the accessors for member symbols into RunDefinitions, and changes calling code accordingly. This is a win for presentation compiler correctness, and might even shave of a few cycles. In a few cases, I have had to leave a `def` to a member symbol in Definitions so we can get to it from the SymbolTable cake, which doesn't see RunDefinitions. The macro FastTrack facility now correctly recreates the mapping from Symbol to macro implementation each run, using a new facility in perRunCaches to create a run-indexed cache. The enclosed test recreates the situation reported in the ticket, in which TypeTags.scala is loaded from source.
* Add a per-run cache for member symbolsJason Zaugg2013-11-081-10/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We are all used to calls to `definitions.PredefModule`, or `defintions.Predef_???` to grab the symbol of some well known entity. But you'll notice that some of these are lazy vals, and others are defs. Why is this so? In the presentation compiler, a member like `Predef.???` will be assigned a new symbol after the user browses into `Predef.scala`. Mistakenly using vals in definitions leads to subtle IDE bugs like SI-7678. We are able to trigger these situations in tests, as noted in the comments of that issue. Changing the vals to defs, on the other hand, has a performance penalty. Some schemes to workaround this have shown up: cache them per-implicit search, or compare method names and owners rather than symbols on hot paths in the type checker. This commit introduces a facility to cache these sort of symbols per-run, and uses it to check for `Predef.conforms` and and for the class/type tag materializers. A followup pull request (WIP: https://github.com/retronym/scala/compare/ticket/7678-2) will expand the use of to address the widespread and unsafe caching of member symbols that I found while investigating SI-7678.
* Cache ImplicitInfo#isCyclicOrErroneousJason Zaugg2013-11-081-2/+8
| | | | | | | | An optimization in implicit search. ImplicitInfo-s themselves are cached (per-run) in Contexts (for in-scope implicits) and in Implicits (for companion object implicits.)
* Fast path for ByNameClass in isImpossibleSubtypeJason Zaugg2013-11-081-1/+1
| | | | | | These show up often due to the way that searches for implicit views operate: firstly `A=>B` is sought, and failing that `(=>A) => B`.
* SI-7944 FOUND: stray undetermined type params in vicinity of implicitsJason Zaugg2013-10-311-1/+5
| | | | | | | | | | | | | | | | | | | | | Implicit search created a nested Context into which the results of its typechecking, namely, errors and undetermined type parameters (roughly: those inferred as Nothing) are stashed. The code the drives the process was checking for errors, but discarded those undetermined type parameters. This commit copies them from the child context to the parent, which lets `Typer#adapt` to get to: else if (hasUndetsInMonoMode) { // (9) assert(!context.inTypeConstructorAllowed, context) //@M instantiatePossiblyExpectingUnit(tree, mode, pt) } Our lost TypeVar has found its way home! The reward for which is being instantiated, based on another type inference session adapting the expression's type to the expected type.
* Microptimization in implicit searchJason Zaugg2013-10-281-1/+2
| | | | Avoid creating a throwaway list of parameter types.
* SI-3346 implicit parameters can now guide implicit view inferenceEugene Burmako2013-10-111-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This simple patch makes it possible for implicit views to benefit from fundep-guided type inference, eliminating a nasty special case in implicit inference. Here are the changes that I had to apply to the tests (they exposed quite a number of interesting questions that I was happy to answer): 1) neg/t5845.scala now works, so I moved it to pos. That easily makes sense, because the test was just a canary to track previous state of things. 2) neg/divergent_implicit.scala, neg/t5578.scala and neg/t7519.scala changed their messages to less informative ones, because inapplicable implicit views now get disqualified early and therefore don't display their error messages to the user. This is an unfortunate but necessary byproduct of this change, and one can argue that the behavior is now completely consistent with implicit vals (that also don't explain why this or that implicit val got disqualified, but rather display a generic implicit value not found message). 3) scaladoc/implicits-chaining.scala and scaladoc/implicits-base.scala. Immediate culling of apriori inapplicable implicit views messes things up for Scaladoc, because it's interested in potentially applicable views, having infrastructure to track various constraints (type bounds, requirements for implicit parameters, etc) that guide applicability of views and then present it to the user. Therefore, when scaladoc is detected, implicit search reverts to the old behavior. 4) We still cannot have Jason's workaround to type constructor inference mentioned in comments to SI-3346, because it's not really about implicit parameters of implicit views, but about type inference flowing from the implicit parameter list to a preceding parameter list in order to affect inference of an implicit view. This is something that's still too ambitious.
* SI-7848 Xlint no warn on $sym with paramsSom Snytt2013-09-231-11/+12
| | | | | | | | | | | | This idea brought to you by retronym. Also improve implicitNotFound detection at typer; and avoid checking the standard interpolation expression for cases like s"some $$x". Some minor refactorings of implicitNotFound strings. The intersobralator allows extra spaces, i.e., trims.
* Avoid needless Type stringification when logging is disabled.Jason Zaugg2013-09-091-1/+1
| | | | | | | Since 4d6be05c28, we've been a tad wasteful in implicit searches. This adds a by-name parameter to the local logging method to avoid that.
* Value class Depth.Paul Phillips2013-08-251-2/+1
| | | | | | | | | | | | | | | | | | | | It's the obvious translation from a raw Int into a value class. It wasn't that long ago one could find a signature like this: def merge(tps: List[Type], variance: Int, depth: Int): Type Do you feel lucky, method caller? Well, do ya? Anyway, now it is: def merge(tps: List[Type], variance: Variance, depth: Depth): Type Forget for a moment the fact that you'd probably rather not pass variance for depth and depth for variance and look at the type signatures: (List[Type], Variance, Depth) => Type (List[Type], Int, Int) => Type
* SI-7624 Fix a few remaining -Xlint warnings ...Simon Ochsenreither2013-08-151-1/+1
| | | | | in various places. This includes actors, compiler (mostly some new macro parts) continuations, partest, scaladoc, scalap.
* SI-7690 ghost error message fails compilePaul Phillips2013-08-111-2/+10
| | | | | | I won't even try to explain the error reporting code, because it would have no basis in reality. However this change appears to fix the symptom reported.
* Make -Ytyper-debug output readable.Paul Phillips2013-07-171-86/+41
|
* SI-6899, prohibit dangerous, useless implicit conversions.Paul Phillips2013-06-041-5/+23
| | | | | | | | | | | | | | | | | | | | Increase eligibility requirements for implicit conversions, such that T => U is ineligible if T <: Null <or> AnyRef <: U This has the salutary effect of allowing us to ditch 16 ridiculous implicits from Predef, since they existed solely to work around the absence of this restriction. There was one tiny impact on actual source code (one line in one file) shown here, necessitated because the literal null is not eligible to be implicitly converted to A via <:<. def f[A](implicit ev: Null <:< A): A = null // before def f[A](implicit ev: Null <:< A): A = ev(null) // after As impositions go it's on the tame side.
* Merge branch 'pr/merge-2.10.2' into masterPaul Phillips2013-06-041-14/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * pr/merge-2.10.2: SI-7375 ClassTag for value class aliases SI-7507 Fix lookup of private[this] member in presence of self type. SI-7532 Fix regression in Java inner classfile reader SI-7517 Fix higher kinded type inference regression SI-7516 Revert "SI-7234 Make named args play nice w. depmet types" A test case for a recent LUB progression. SI-7421 remove unneeded extra-attachement in maven deploy SI-7486 Regressions in implicit search. SI-7509 Avoid crasher as erronous args flow through NamesDefaults SI-6138 Centralize and refine detection of `getClass` calls SI-7497 Fix scala.util.Properties.isMac SI-7473 Bad for expr crashes postfix Increase build.number to 2.10.3 SI-7391 Always use ForkJoin in Scala actors on ... ... Java 6 and above (except when the porperty actors.enableForkJoin says otherwise) Reimplementing much of the DefaultPromise methods Optimizations: 1) Avoiding to call 'synchronized' in tryComplete and in tryAwait 2) Implementing blocking by using an optimized latch so no blocking ops for non-blockers 3) Reducing method size of isCompleted to be cheaper to inline 4) 'result' to use Try.get instead of patmat c.typeCheck(silent = true) now suppresses ambiguous errors Conflicts: bincompat-backward.whitelist.conf bincompat-forward.whitelist.conf src/compiler/scala/reflect/macros/contexts/Typers.scala src/compiler/scala/reflect/reify/package.scala src/compiler/scala/tools/nsc/symtab/classfile/ClassfileParser.scala src/compiler/scala/tools/nsc/typechecker/NamesDefaults.scala src/compiler/scala/tools/nsc/typechecker/Typers.scala src/compiler/scala/tools/reflect/ToolBoxFactory.scala src/library/scala/concurrent/impl/Promise.scala src/reflect/scala/reflect/internal/Types.scala
| * SI-7486 Regressions in implicit search.Paul Phillips2013-05-231-14/+3
| | | | | | | | Revert e86832d7e8 and dd33e280e2.
* | Print raw types correctly.Paul Phillips2013-05-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The "For convenience, these are usable as stub implementations" bit has generated surprisingly few angry letters, but I noticed today it blows it on raw types. Or, used to blow it. /** As seen from class Sub, the missing signatures are as follows. * For convenience, these are usable as stub implementations. * (First one before this commitw as 'def raw(x$1: M_1)' */ def raw(x$1: M_1[_ <: String]): Unit = ??? def raw(x$1: Any): Unit = ???
* | Concision contribution.Paul Phillips2013-05-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have lots of core classes for which we need not go through the symbol to get the type: ObjectClass.tpe -> ObjectTpe AnyClass.tpe -> AnyTpe I updated everything to use the concise/direct version, and eliminated a bunch of noise where places were calling typeConstructor, erasedTypeRef, and other different-seeming methods only to always wind up with the same type they would have received from sym.tpe. There's only one Object type, before or after erasure, with or without type arguments. Calls to typeConstructor were especially damaging because (see previous commit) it had a tendency to cache a different type than the type one would find via other means. The two types would compare =:=, but possibly not == and definitely not eq. (I still don't understand what == is expected to do with types.)
* | Merge 2.10.x into masterAdriaan Moors2013-05-171-3/+7
|\| | | | | | | | | | | Conflicts: src/compiler/scala/tools/nsc/typechecker/Implicits.scala src/reflect/scala/reflect/runtime/JavaMirrors.scala
| * SI-7486 regression in implicit resolution.Paul Phillips2013-05-171-3/+7
| | | | | | | | What a touchy beast the compiler is.
* | Merge v2.10.1-326-g4f8c306' into merge/v2.10.1-326-g4f8c306-to-masterJason Zaugg2013-05-171-181/+104
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ================================================================ Merge commit 'v2.10.1-326-g4f8c306' into merge/v2.10.1-326-g4f8c306-to-master Conflicts: src/compiler/scala/tools/nsc/typechecker/SuperAccessors.scala src/reflect/scala/reflect/runtime/JavaMirrors.scala ================================================================ Merge -s ours 4e64a27 ([nomaster commit range]) ================================================================ Merge commit '0ae7e55' into merge/v2.10.1-326-g4f8c306-to-master Conflicts: src/compiler/scala/tools/nsc/typechecker/Macros.scala
| * removes duplication in inferImplicitValueEugene Burmako2013-05-121-0/+15
| | | | | | | | This is a port of https://github.com/scala/scala/commit/4e64a2731d from 2.10.x.
| * SI-7167 implicit macros decide what is divergenceEugene Burmako2013-05-121-2/+18
| | | | | | | | | | | | This is a port of https://github.com/scala/scala/commit/8168f118c9 from 2.10.x, with an additional change to the `enclosingImplicits` and `openImplicits` APIs, which encapsulates tuples of `pt` and `tree` into `ImplicitCandidate`.
| * Merge pull request #2493 from paulp/pr/null-hardeningPaul Phillips2013-05-071-1/+4
| |\ | | | | | | Hardening against nulls for deserialization.
| | * Hardening against nulls for deserialization.Paul Phillips2013-05-031-1/+4
| | | | | | | | | | | | | | | | | | When one attempts to populate data structures via deserialization, nulls tend to show up in unlikely or "impossible" places. Now there are a few fewer.
| * | Absolutized paths involving the scala package.Paul Phillips2013-05-031-5/+6
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Confusing, now-it-happens now-it-doesn't mysteries lurk in the darkness. When scala packages are declared like this: package scala.collection.mutable Then paths relative to scala can easily be broken via the unlucky presence of an empty (or nonempty) directory. Example: // a.scala package scala.foo class Bar { new util.Random } % scalac ./a.scala % mkdir util % scalac ./a.scala ./a.scala:4: error: type Random is not a member of package util new util.Random ^ one error found There are two ways to play defense against this: - don't use relative paths; okay sometimes, less so others - don't "opt out" of the scala package This commit mostly pursues the latter, with occasional doses of the former. I created a scratch directory containing these empty directories: actors annotation ant api asm beans cmd collection compat concurrent control convert docutil dtd duration event factory forkjoin generic hashing immutable impl include internal io logging macros man1 matching math meta model mutable nsc parallel parsing partest persistent process pull ref reflect reify remote runtime scalap scheduler script swing sys text threadpool tools transform unchecked util xml I stopped when I could compile the main src directories even with all those empties on my classpath.
| * SI-7291: Remove error kinds.Hubert Plociniczak2013-04-261-5/+10
| | | | | | | | | | | | | | | | What seemed like a good idea initially (since potentially there were many different kinds of errors that could be treated specially), started to complicate the error logic. So let's just match on the specific instance of an error to manipulate the buffer.
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-29 15:40:31 +0000