summaryrefslogtreecommitdiff
path: root/test/files/neg
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #3355 from xeno-by/topic/saturday-nightJason Zaugg2014-01-1469-260/+224
|\ | | | | reshuffles names for blackbox/whitebox contexts, changes bundle notation
| * prohibits constructor overloading for macro bundlesEugene Burmako2014-01-123-1/+17
| | | | | | | | | | | | As per Jason’s feedback, this commit handles overloaded constructors in macro bundles. The backend now checks that we have a constructor of a correct type. The frontend now prohibits multiple constructors altogether.
| * changes bundles to be classes, not traits extending MacroEugene Burmako2014-01-1215-68/+17
| | | | | | | | | | | | Adjusts bundle notation to read `class Bundle(val c: Context)` instead of `class Bundle extends Macro`. This avoids calling compileLate in the macro compiler and associated tooling problems.
| * *boxContext => *box.Context , *boxMacro => *box.MacroEugene Burmako2014-01-1264-213/+212
| | | | | | | | | | | | | | | | | | | | 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 #3275 from paulp/pr/patmatAdriaan Moors2014-01-1312-41/+151
|\ \ | | | | | | Improves name-based patmat.
| * | SI-7850 CCE in patmat with invalid isEmpty.Paul Phillips2013-12-154-9/+32
| | | | | | | | | | | | | | | | | | | | | | | | Name-based pattern matcher needed some hardening against unapply methods with the right name but wrong types. Only isEmpty methods which return Boolean are acceptable. Catching it directly rather than indirectly also allowed for better error messages.
| * | SI-7897, SI-6675 improves name-based patmatPaul Phillips2013-12-159-32/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This emerges from a recent attempt to eliminate pattern matcher related duplication and to bake the scalac-independent logic out of it. I had in mind something a lot cleaner, but it was a whole lot of work to get it here and I can take it no further. Key file to admire is PatternExpander.scala, which should provide a basis for some separation of concerns. The bugs addressed are a CCE involving Tuple1 and an imprecise warning regarding multiple pattern crushing. Editorial: auto-tupling unapply results was a terrible idea which should never have escaped from the crib. It is tantamount to purposely throwing type safety down the toilet in the very place where people need type safety the most. See SI-6111 and SI-6675 for some other comments.
* | | Merge pull request #3184 from retronym/ticket/2066Adriaan Moors2014-01-134-0/+112
|\ \ \ | |_|/ |/| | SI-2066 Plug a soundness hole higher order type params, overriding
| * | SI-2066 Plug a soundness hole higher order type params, overridingJason Zaugg2013-11-274-0/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PolyType-s parameterized by higher order type parameters (HOTPs) should only be relatable with <:< or =:= if the variances of their type parameters line up. This is only enforced for HOTPs defined in method type arguments. Invariant type parameters subsume variant ones. Concretely, as described by @S11001001: > A method taking [F[_]] can implement a method taking [F[+_]]. > Likewise, a method taking [F[_[+_]]] can implement a method > taking [F[_[_]]], as with [F[_[_[_]]]] implementing [F[_[_[+_]]]], > and so on, the variance subsumption flipping at each step. > > This is just the opposite of the variance for passing type > parameters to either instantiate types or call methods; a F[+_] > is a suitable F[_]-argument, a F[_[_]] a suitable F[_[+_]]-argument, > and so on. > > All of the above rules can be duplicated for contravariant positions > by substituting - for +. Also, something similar happens for > weakening/strengthening bounds, I believe. These cases are tested in the `// okay` lines in `neg/t2066.scala`.
* | | Merge pull request #3235 from xeno-by/topic/macro-plugin-interfaceEugene Burmako2014-01-087-1/+59
|\ \ \ | | | | | | | | new hooks in AnalyzerPlugins to enable macro experimentation
| * | | hooks for naming and synthesis in Namers.scala and Typers.scalaEugene Burmako2013-12-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Interestingly enough, despite of the implementation surface being quite noticeable, it is enough to hijack just `enterSym` and typechecking of stats for packages, templates and blocks in order to enable macro annotations. That and `ensureCompanionObject`, which I couldn't abstract away so far. An architectural note: given that a hooked method is called `X`, there are two implementations of this method. `pluginsX` is defined in AnalyzerPlugins.scala and lets macro plugins customize `X`. `standardX` is defined next to `X` and provides a default implementation. Finally `X` is changed to trivially forward to `pluginsX`. Existing and future callers of `X` now can be completely oblivious of the introduced hooks, because calls to `X` will continue working and will be correctly hooked. This makes the infrastructure more robust. The only downside is that in case when a macro plugin wants to call into the default implementation, it needs to call `standardX`, because `X` will lead to a stack overflow. However, in my opinion this not a big problem, because such failures are load and clear + for every `pluginsX` we actually provide documentation that says what is its standard impl is.
| * | | humane reporting of macro impl binding version errorsEugene Burmako2013-12-306-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Macro defs are linked to macro impls by the virtue of MacroImplBinding structures that are persisted between compilation runs serialized within instances of macroImpl annotations. Along with the evolution of our macro engine, we sometimes have to evolve the format of MacroImplBinding, which means that it has to be versioned. Version mismatches are checked upon every macro expansion, ensuring that macros that we expand were compiled with exactly the same version of the macro engine that we’re running. That’s all really cool apart from the fact that version mismatches result in aborting the entire compilation with an obscure message without giving a hint about the culprits. This commit improves the situation by providing pretty per-expansion compilation errors that tell the programmer what macro expansions are at fault and what macro engines were used to compile them.
| * | | macroExpandApply => macroExpandEugene Burmako2013-12-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Back then, when we needed separate macro expanders for both applications and unapplications, it made sense to have two different methods that do macro expansions. However, after @paulp’s upgrade of the pattern matching engine, we no longer need a dedicated expander for unapply, so I’m removing it and renaming `macroExpandApply` to just `macroExpand`.
* | | | Merge pull request #3239 from soc/SI-8052Jason Zaugg2014-01-031-20/+33
|\ \ \ \ | |/ / / |/| | | SI-8052 Disallow `macro` as an identifier
| * | | SI-8052 Disallow `macro` as an identifierSimon Ochsenreither2013-12-091-20/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Note that the change could look a lot cleaner, at the cost of returning more generic error messages. I decided that at least for 2.11 I'll keep scalac remembering that macro was a standard identifier name once, so that we can point out more precisely what's wrong with users' code.
* | | | Merge pull request #3288 from xeno-by/topic/f-interpolatorJason Zaugg2013-12-306-2/+36
|\ \ \ \ | | | | | | | | | | makes boxity of fast track macros configurable
| * | | | makes boxity of fast track macros configurableEugene Burmako2013-12-196-2/+36
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, all built-in macros were assumed to be whitebox, but that’s actually not the case. Just quasiquote macros have to be whitebox, while the rest can be blackbox. This also fixes SI-8091, because blackbox macros are typechecked differently and therefore the necessary implicit conversion kicks in. If `f”...”` were to remain a whitebox macro, then due to the changes introduced in commit https://github.com/scala/scala/commit/a3b33419b02cafb7e2c6fed6dd96151859fc7d77 we would have to explicitly ascribe its expansion as String to achieve the same effect. After I made reify blackbox, several tests had to be changed, because we now explicitly ascribe the expansion with `c.Expr[T]`, which changes `toString`. Also, a number of less obvious corrections had to be applied, because things like `reify(<constant>).splice` have stopped being optimized away due to `reify(<constant>)` no longer having a narrow `c.Expr[<constant>.type]`, making it ineligible for constant folding. Moreover, this change forced me to adjust our approach to positioning blackbox wrappings, because after being changed to blacbox and starting using wrappings, f”...” interpolators used in the compiler started crashing -Yrangepos builds. Now wrapping Typed nodes are assigned with transparent positions.
* | | | Merge pull request #3309 from xeno-by/topic/expand-dynamicJason Zaugg2013-12-304-0/+30
|\ \ \ \ | | | | | | | | | | SI-7777 SI-8006 assorted fixes for dynamics
| * | | | SI-8006 prevents infinite applyDynamicNamed desugaringsEugene Burmako2013-12-284-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since mkInvoke, the applyDynamic/selectDynamic/etc desugarer, is disconnected from typedNamedApply, the applyDynamicNamed argument rewriter, the latter doesn’t know whether it needs to apply the rewriting because the application has just been desugared or it needs to hold on because it’s already performed a desugaring on this tree. This commit introduces the attachment that links these translation facilities, preventing infinite applyDynamicNamed desugarings.
* | | | | Merge pull request #3311 from xeno-by/topic/fine-points-of-whiteboxity-masterEugene Burmako2013-12-283-0/+36
|\ \ \ \ \ | | | | | | | | | | | | (master) codifies the state of the art wrt SI-8104
| * | | | | codifies the state of the art wrt SI-8104Eugene Burmako2013-12-283-0/+36
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As it was discovered in SI-8104, whiteboxity doesn’t apply equally to type parameters and type members of materialized type classes. During implicit search and subsequent type inference, whitebox type parameters are consistently erased to wildcards, whereas whitebox type members sometimes remain as is and get in the way of signature conformance checks.
* / / / / SI-6355 SI-7059 it is possible to overload applyDynamicEugene Burmako2013-12-285-7/+35
|/ / / / | | | | | | | | | | | | | | | | | | | | | | | | As our discussion at https://issues.scala-lang.org/browse/SI-6355 shows, it looks like it is possible to overload applyDynamic, even though a straightforward way is closed. This commit codifies the pattern proposed by @paulp and makes sure that it doesn’t break in the future.
* | | | Merge pull request #3276 from som-snytt/issue/6120-spurious-checkAdriaan Moors2013-12-194-31/+4
|\ \ \ \ | | | | | | | | | | SI-6120 Suppress extra warnings
| * | | | SI-6120 Suppress extra warningsSom Snytt2013-12-164-31/+4
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a mere polish for the fix to allow multiple warnings. Sensibility checks in refchecks were shown to be redundant. This commit includes a mild refactor to reduce tabbage, and uses a local var to flag that a warning has already been emitted. It would be better to have the checks return true if warned, to facilitate `nonSensically || unrelatedly`, etc., but that's a lot of `else false`. The check files that were updated with the redundant warnings are reverted.
* / / / SI-5508 Fix crasher with private[this] in nested traitsJason Zaugg2013-12-193-22/+0
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, accessors for private local trait fields are added very late in the game when the `Mixin` tree transformer treats the trait. By contrast, fields with weaker access have accessors created eagerly in `Namers`. // Mixin#addLateInterfaceMembers val getter = member.getter(clazz) if (getter == NoSymbol) addMember(clazz, newGetter(member)) `addMember` mutates the type of the interface to add the getter. (This seems like a pretty poor design: usually if a phase changes types, it should do in an `InfoTransformer`.) However, if an inner class or anonymous function of the trait has been flattened to a spot where it precedes the trait in the enclosing packages info, this code hasn't had a chance to run, and the lookup of the getter crashes as mixins `postTransform` runs over a selection of the not-yet-materialized getter. // Mixin#postTransform case Select(qual, name) if sym.owner.isImplClass && !isStaticOnly(sym) => val iface = toInterface(sym.owner.tpe).typeSymbol val ifaceGetter = sym getter iface This commit ensures that `Flatten` lifts inner classes to a position *after* the enclosing class in the stats of the enclosing package. Bonus fix: SI-7012 (the followup ticket to SI-6231 / SI-2897)
* | | Merge pull request #3258 from ↵Adriaan Moors2013-12-132-2/+2
|\ \ \ | | | | | | | | | | | | | | | | jrudolph/w/fix-typo-that-that-occurs-twice-in-error-messages fix typo in error messages
| * | | fix typo in error messagesJohannes Rudolph2013-12-102-2/+2
| | | |
* | | | Merge pull request #3204 from retronym/topic/patmat-classtag-compoundAdriaan Moors2013-12-133-0/+24
|\ \ \ \ | | | | | | | | | | Test case for recently improved unchecked warning
| * | | | Test case for recently improved unchecked warningJason Zaugg2013-12-123-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to https://github.com/scala/scala/pull/2848, the enclosed test compiled without warning and printed: true false Features interacting: - implicit class tags to enable type patterns on abstract types - type tests on compound types. I think the unchecked warning is acceptable for now.
* | | | | Merge pull request #3214 from retronym/ticket/8024Adriaan Moors2013-12-134-0/+43
|\ \ \ \ \ | | | | | | | | | | | | SI-8024 Fix inaccurate message on overloaded ambiguous ident
| * | | | | SI-8024 Improve user-level toString of package objectsJason Zaugg2013-12-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We were outputing a the unattractive `package package`; now we opt for `package object pack`. Under `-Ydebug`, we still go to the "accurate" mode of the old `toString` implementation, which differentiates package objects vs package object classes.
| * | | | | SI-8024 Fix inaccurate message on overloaded ambiguous identJason Zaugg2013-12-124-0/+43
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `Symbol#owner` of an overloaded symbol doesn't necessarily correspond to the owner of any of the alternatives, and as such it shouldn't be used in error message. neg/t8024.scala actually represents a progression since 2.10.3; the ambiguity was not reported. I bisected the change to https://github.com/scala/scala/pull/1554.
* | | | | Merge pull request #3263 from retronym/ticket/6780Adriaan Moors2013-12-131-0/+1
|\ \ \ \ \ | | | | | | | | | | | | SI-6780 Better handling of cycles in in-scope implicit search
| * | | | | SI-6780 Better handling of cycles in in-scope implicit searchJason Zaugg2013-12-111-0/+1
| | |/ / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implicit searches in the body of implicit members with inferred types were leading to cycles. Before we used to resolve that by saying there were no implicits in scope at all; now we just skip the current context and still include the enclosing implicits. Care is taken not to cache results under these circumstances. This entails reworking `Context#implicitss` so that: - the implicit info cache only contains implicits from the current level. The List[List[_]] is now contructed on demand; - we can detect cycles by setting `implicitsCacheRunId` to -1 during the computation. The outer implicits when we encounter that. - we avoid caching when we hit a cycle or when the owner is uninitialized.
* | | | | Merge pull request #3169 from som-snytt/issue/4841-plugin-cpJason Zaugg2013-12-121-1/+1
|\ \ \ \ \ | |_|/ / / |/| | | | Plugins get a class path
| * | | | SI-4841 Plugins get a class pathSom Snytt2013-12-061-1/+1
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let -Xplugin specify a class path (or multiple of them). Each entry can be a jar or dir, and the first entry to supply a plugin descriptor defines the plugin to load. If no plugin is found on the path, then issue a warning if `-Xdev`. This honors the legacy silent treatment (which scala-ide tests for). In the proposed scheme, each plugin gets a class loader so that plugins are isolated from each other. Presumably, if compiler plugins were a rich ecosystem, in which shared dependencies were required in incompatible versions, this would have become a requirement by now. (Updated with a `DirectTest` that uses two plugins, but keeping the following as documentation.) Partest can't do multiple plugins yet, but this is what it looks like: ``` skalac -Xplugin:sample.jar:useful.jar:util,needful.jar:another.jar:util,needful.jar:util:exploded -Xplugin-require:sample,another,other foo.scala skalac -Xplugin:sample.jar:useful.jar:util,needful.jar:another.jar:util,needful.jar:util:exploded -Xplugin-require:sample,other -Xplugin-disable:another foo.scala skalac -Xplugin:sample.jar:useful.jar:util,sample.jar:useful.jar:util -Xplugin-require:sample foo.scala ``` The manual test shows three plugins with various permutations of jars and dirs. The manual test demonstrates that plugins only see classes on their class path: ``` Initializing test.plugins.SamplePlugin needful.Needful? Failure(java.lang.ClassNotFoundException: needful.Needful) useful.Useful? Success(class useful.Useful) Initializing more.plugins.AnotherPlugin needful.Needful? Success(class needful.Needful) useful.Useful? Failure(java.lang.ClassNotFoundException: useful.Useful) Initializing other.plugins.OtherPlugin ``` Disabling a plugin results in a message instead of silent suppression: ``` Disabling plugin another ``` The duplicate plugin class test must still be honored: ``` Ignoring duplicate plugin sample (test.plugins.SamplePlugin) Initializing test.plugins.SamplePlugin needful.Needful? Failure(java.lang.ClassNotFoundException: needful.Needful) useful.Useful? Success(class useful.Useful) ``` If the path is bad, then missing classes will report which plugin induced the error: ``` Error: class not found: util/Probe required by test.plugins.SamplePlugin Error: class not found: util/Probe required by more.plugins.AnotherPlugin Initializing other.plugins.OtherPlugin needful.Needful? Success(class needful.Needful) useful.Useful? Failure(java.lang.ClassNotFoundException: useful.Useful) error: Missing required plugin: sample error: Missing required plugin: another two errors found ```
* | | | Test unliftable not found scenarioDen Shabalin2013-12-102-0/+9
| | | |
* | | | Refactor Holes and Reifiers slices of Quasiquotes cakeDen Shabalin2013-12-102-0/+12
| |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit performs a number of preliminary refactoring needed to implement unliftable: 1. Replace previous inheritance-heavy implementation of Holes with similar but much simpler one. Holes are now split into two different categories: ApplyHole and UnapplyHole which correspondingly represent information about holes in construction and deconstruction quasiquotes. 2. Make Placeholders extract holes rather than their field values. This is required to be able to get additional mode-specific information from holes (e.g. only ApplyHoles have types). 3. Bring ApplyReifier & UnapplyReifier even closer to the future where there is just a single base Reifier with mode parameter. Along the way a few bugs were fixed: 1. SI-7980 SI-7996 fail with nice error on bottom types splices 2. Use asSeenFrom instead of typeArguments in parseCardinality. This fixes a crash if T <:< Iterable[Tree] but does not itself have any type arguments. 3. Fix spurious error message on splicing of Lists through Liftable[List[T]]
* | | Merge pull request #3246 from xeno-by/topic/compile-time-onlyJason Zaugg2013-12-102-20/+69
|\ \ \ | | | | | | | | streamlines refchecking undesired symbol properties
| * | | streamlines refchecking undesired symbol propertiesEugene Burmako2013-12-092-20/+69
| |/ / | | | | | | | | | | | | | | | Unifies `checkDeprecated`, `checkMigration` and `checkCompileTimeOnly` into a single centralized point of reference that is now consistently called from `checkTypeRef`, `transformIdent` and `transformSelect`.
* / / deprecates macro def return type inferenceEugene Burmako2013-12-1030-61/+98
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the new focus on quasiquotes in macro implementations, we now have to change the way how inference of macro def return types works. Previously, if the return type of a macro def wasn’t specified, we looked into the signature of its macro impl, took its return type (which could only be c.Expr[T]) and then assigned T to be the return type of the macro def. We also had a convenient special case which inferred Any in case when the body of the macro impl wasn’t an expr. That avoided reporting spurious errors if the macro impl had its body typed incorrectly (because in that case we would report a def/impl signature mismatch anyway) and also provided a convenience by letting macro impls end with `???`. However now we also allow macro impls to return c.Tree, which means that we are no longer able to do any meaningful type inference, because c.Tree could correspond to tree of any type. Unfortunately, when coupled with the type inference special case described above, this means that the users who migrate from exprs to quasiquotes are going to face an unpleasant surprise. If they haven’t provided explicit return types for their macro defs, those types are going to be silently inferred as `Any`! This commit plugs this loophole by prohibiting type inference from non-expr return types of macro impls (not counting Nothing). Moreover, it also deprecates c.Expr[T] => T inference in order to avoid confusion when switching between exprs and quasiquotes.
* | Merge pull request #3216 from xeno-by/topic/macro-error-messagesAdriaan Moors2013-12-0313-66/+58
|\ \ | | | | | | better error messages for various macro definition errors
| * | better error messages for various macro definition errorsEugene Burmako2013-12-0313-66/+58
| |/
* / Better error messages for common Function/Tuple mistakesJason Zaugg2013-12-014-0/+63
|/ | | | | | | | | | | | | | | | | | | | | | | | | Firstly, for `((a, b) => c): (Tuple2[A, B] => C)`, we currently just offer "missing parameter type." Is something of a rite of passage to know that you need `{ case (...)}` This commit stops short DWIM, but does offer a diagnostic to guide the user towards the supported way of destructuring a `Tuple` in the sole argument of a `Function1`. Secondly, another (less common?) way one might try to write a function to destructure a single tuple argument is: (((a, b)) => c) The parser now matches offers a specific error message for this, and points out the alternatives. In both cases, we avoid offering syntactically invalid alternatives, by detecting names that aren't valid as variable-patterns, and falling back to generic "paramN" in the error message. A handly utility function to sequence a list of options is liberated from the pattern matcher for broader use.
* Merge pull request #3197 from retronym/merge/2.10.x-positions-to-masterJason Zaugg2013-11-261-4/+4
|\ | | | | Merge 2.10.x, and PR #3196, to master
| * Merge remote-tracking branch 'origin/pr/3196' into ↵Jason Zaugg2013-11-261-4/+4
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | merge/2.10.x-positions-to-master Conflicts: src/compiler/scala/tools/nsc/typechecker/Typers.scala test/files/neg/applydynamic_sip.check - Changes two calls from `.endOrPoint` to `.point`. The latter is safe in master for both `Range`- and `OffsetPosition`s - Updates checkfiles with unrelated position changes (constructors)
| | * SI-7463,SI-8003 Correct wrong position for {select,apply}Dynamic callsSimon Schaefer2013-11-261-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new positions are range positions that directly refer to the beginning and the end of the method calls in the sources instead of simply point to the beginning of the expression. This allows the scala-ide to semantically highlight select- and applyDynamic method calls, because it has only to traverse the tree and apply the color ranges to the given position ranges. This also fixes the position marker of an error messages related to a wrong Dynamic method signature.
| | * SI-7519: Additional test case covering sbt/sbt#914Mark Harrah2013-10-233-0/+26
| | | | | | | | | | | | (cherry picked from commit e72c32db03b44d6eaf1c1872765a578c5445e15f)
| | * [nomaster] SI-7519 Less brutal attribute resetting in adapt fallbackJason Zaugg2013-10-232-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prefers `resetLocalAttrs` over `resetAllAttrs`. The latter loses track of which enclosing class of the given name is referenced by a `This` node which prefixes the an applied implicit view. The code that `resetAllAttrs` originally landed in: https://github.com/scala/scala/commit/d4c63b#L6R804 Cherry picked from 433880e91cba9e1e926e9fcbf04ecd4aeb1d73eb Conflicts: src/compiler/scala/tools/nsc/typechecker/Typers.scala
* | | SI-7984 Issue unchecked warning for type aliasesJason Zaugg2013-11-267-9/+23
|/ / | | | | | | | | | | - Dealias pattern types before launching the CheckabilityChecker - Sharpen the error messages to explain that the dealiased type is the expansion of the alias.
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-07 16:38:11 +0000