summaryrefslogtreecommitdiff
path: root/src/compiler
Commit message (Collapse)AuthorAgeFilesLines
* removes some copy/paste from AnalyzerPluginsEugene Burmako2013-12-301-37/+43
| | | | | | Abstracts away the foldLeft-based iteration pattern behind CumulativeOp[T]. In order to avoid performance regressions, `pluginsPt` and `pluginsTyped` are special-cased for empty lists of analyzer plugins.
* gives a more specific signature to `computeMacroDefType`Eugene Burmako2013-12-302-13/+12
| | | | | | | | | | | I guess having `computeMacroDefType` is the remnant from the times when we considered an immediate possibility of having non-defdef macros, for instance type macros, which would be TypeDefs. These happy early days are gone, type macros have been long buried, and the perspectives of extensions to the existing def macro scheme are unclear. Therefore let’s have maximally precise types right away and then think of generalization later on, once/if we get there.
* macroExpandApply => macroExpandEugene Burmako2013-12-302-19/+4
| | | | | | | | | | 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 #3288 from xeno-by/topic/f-interpolatorJason Zaugg2013-12-302-13/+19
|\ | | | | makes boxity of fast track macros configurable
| * makes boxity of fast track macros configurableEugene Burmako2013-12-192-13/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #3292 from xeno-by/topic/duplicate-macro-argsJason Zaugg2013-12-301-3/+3
|\ \ | | | | | | duplicates arguments to macro typer APIs
| * | duplicates arguments to macro typer APIsEugene Burmako2013-12-191-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit continues the tendency set by the parent commit to duplicate as much as possible in order to avoid potential confusion that users might run into when compiler internals start leaking. Here we plumb another way that by-reference sharing of trees might bite unsuspecting macro writers. Previously we have duplicated macro expansions, macro arguments, c.macroApplication, and now it’s arguments to typeCheck and resetAttrs. There is still an unlikely situation when someone gets to c.enclosingXXX and then starts typechecking around, but that’s left for future work, as it’s yet unclear what to do with c.enclosingXXX APIs.
* | | SI-8006 prevents infinite applyDynamicNamed desugaringsEugene Burmako2013-12-282-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | SI-7777 applyDynamic macro fails for nested applicationEugene Burmako2013-12-272-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | Interplay between the insertApply desugaring and the invokeDynamic desugarings is already quite brittle, but the real fun begins when macros crash the party. The proposed patch enriches the `isDesugaredApply` check performed in `mkInvoke`, the invokeDynamic desugarer, and makes sure that everything is safe and sound in the macroland.
* | | Merge pull request #3276 from som-snytt/issue/6120-spurious-checkAdriaan Moors2013-12-191-147/+152
|\ \ \ | | | | | | | | SI-6120 Suppress extra warnings
| * | | SI-6120 Suppress extra warningsSom Snytt2013-12-161-147/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | Merge pull request #3274 from retronym/ticket/8017Grzegorz Kossakowski2013-12-191-2/+20
|\ \ \ \ | | | | | | | | | | SI-8017 Value class awareness for -Ydelamdafy:method
| * | | | SI-8017 Value class awareness for -Ydelamdafy:methodJason Zaugg2013-12-151-2/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The delambdafy creates a bridge method which requires adaptation of the result type to the generic `Object`, which is the erased return type of FunctionN. This bridge building reused some code from erasure, now refactored into TypeAdaptingTransformer. But, it was running into problems with: class C(a: Int) extends AnyVal (x: Any) => new C(0) It created (forgive the pseudo quasiquote syntax): class anonfun$ extends Function1[Any, C] { def apply#1(a: Object): Int = 0 <bridge> def apply#2(a: Object): Object = { val result: Int = apply#1(a) ${adapt(Ident("result"), ObjectType)} } } This resulted in primitive boxing, rather than value class boxing. Instead, we need the call to the main apply method to be typed as `ErasedValueClass(C, Int)`, which `adapt` takes as a trigger to perform value class boxing. Finally, we have to run the post-erasure transformer over the adapted tree to eliminate remnants of `ErasedValueClass` from the types of trees.
* | | | | Merge pull request #3234 from retronym/ticket/5508-3Jason Zaugg2013-12-192-21/+23
|\ \ \ \ \ | | | | | | | | | | | | Fix crasher with private[this] in nested traits
| * | | | | Remove obsolete diagnostic error for SI-6231Jason Zaugg2013-12-191-15/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous commit means we no longer have a test that gets to this point.
| * | | | | SI-5508 Fix crasher with private[this] in nested traitsJason Zaugg2013-12-191-6/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #3257 from xeno-by/topic/duplicate-macro-argsJason Zaugg2013-12-191-3/+3
|\ \ \ \ \ \ | |/ / / / / |/| | | / / | | |_|/ / | |/| | | (2.11.0-M8) duplicates macro arguments before expansion
| * | | | duplicates macro arguments before expansionEugene Burmako2013-12-171-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As discussed with Jason, this is an important dimension of defenses that we can build to ensure robustness of the macro engine. This commit is important in the context of the upcoming patch to the presentation compiler that will throw away expansions and keep original macro applications (only when run in presentation compiler mode) so that hyperlinking in macro arguments starts working in the IDE. Duplication of macro arguments will make sure that macro arguments, which are going to become exposed to the IDE, can’t become corrupted by possibly misbehaving or misguided macros.
* | | | | Merge pull request #3224 from soc/SI-7971Adriaan Moors2013-12-183-49/+73
|\ \ \ \ \ | |_|_|_|/ |/| | | | SI-7971 Handle static field initializers correctly
| * | | | SI-7971 Handle static field initializers correctlySimon Ochsenreither2013-12-143-49/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this fix, static fields where erroneously treated like instance fields and the initialization was moved into the constructor. With this fix, the static initializer statements go into the static initializer of the class (called “<STATIC> def init” in Scala, <clinit> in Java). The statements are added to an existing static initializer method or, if no such method exists, a new static initializer method is created and added to the class.
* | | | | Merge pull request #3236 from xeno-by/topic/wildbox-macrosEugene Burmako2013-12-171-27/+34
|\ \ \ \ \ | |_|_|_|/ |/| | | | (2.11.0-M8) whitebox macros are now first typechecked against outerPt
| * | | | drops the redundant typecheck of blackbox expansionsEugene Burmako2013-12-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While fixing the problem with the order of typechecks for whitebox expansions, I realized that we’re doing redundant work when expanding blackbox macros. Concretely, typechecking blackbox expansions looked as follows: val expanded1 = atPos(enclosingMacroPosition.focus)(Typed(expanded0, TypeTree(innerPt))) val expanded2 = typecheck("blackbox typecheck #1", expanded1, innerPt) typecheck("blackbox typecheck #2", expanded1, outerPt) Or, if we reformulate it using quasiquotes (temporarily not taking positions into account, since they aren’t important here): val expanded2 = typed(q”$expanded: $innerPt”, innerPt) typed(expanded2, outerPt) In this formulation, it becomes apparent that the first typecheck is redundant. If something is ascribed with some type, then typechecking the ascription against that type does nothing useful. This is also highlights one of the reasons why it would be really nice to have quasiquotes used in the compiler. With them, it’s easy to notice things that would otherwise remain buried behind swaths of boilerplate.
| * | | | whitebox macros are now first typechecked against outerPtEugene Burmako2013-12-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even though whitebox macros are supposed to be used to produce expansions that refine advertised return types of their macro definitions, sometimes those more precise types aren’t picked up by the typechecker. It all started with Travis generating structural types with macros and noticing that typer needs an extra nudge in order to make generated members accessible to the outside world. I didn’t understand the mechanism of the phenomenon back then, and after some time I just gave up. Afterwards, when this issue had been brought up again in a different StackOverflow question, we discussed it at reflection meeting, figured out that typedBlock provides some special treatment to anonymous classes, and it became clear that the first macro typecheck (the one that types the expansion against the return type of the corresponding macro def) is at fault here. The thing is that if we have a block that stands for a desugard anonymous class instantiation, and we typecheck it with expected type different from WildcardType, then typer isn’t going to include decls of the anonymous class in the resulting structural type: https://github.com/scala/scala/blob/master/src/compiler/scala/tools/nsc/typechecker/Typers.scala#L2350. I tried to figure it out at https://groups.google.com/forum/#!topic/scala-internals/eXQt-BPm4i8, but couldn’t dispel the mystery, so again I just gave up. But today I had a profound WAT experience that finally tipped the scales. It turns out that if we typecheck an if, providing a suitable pt, then the resulting type of an if is going to be that pt, even though the lub of the branch types might be more precise. I’m sure that reasons for this behavior are also beyond my understanding, so I decided to sidestep this problem. upd. Here’s Jason’s clarification: Doing thing differently would require us to believe that "'Tis better to have lubbed and lost than never to have lubbed at all." But the desire for efficiency trumps such sentimentality. Now expansions of whitebox macros are first typechecked against outerPt, the expected type that comes from the enclosing context, before being typechecked against innerPt, the expected type that comes from the return type of the macro def. This means that now outerPt provides the correct expected type for the initial, most important typecheck, which makes types more precise.
| * | | | refactors macroExpandApplyEugene Burmako2013-12-101-27/+35
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Moves some code around to clearly define the concepts that the method operates on: 1) `innerPt`, which is expected type provided by the macro def return type, 2) `outerPt`, which is expected type provided by the enclosing context. Once everything is clearly defined, the gist of the expander fits in a few lines in its end. If blackbox, do this. If whitebox, do that. Note that unlike the subsequent commit, this commit doesn’t change the way how macro expansion works. It just clears everything out, so that the upcoming changes can be applied in a concise and comprehensible manner.
* | | | Merge pull request #3266 from soc/SI-7546Adriaan Moors2013-12-132-4/+7
|\ \ \ \ | | | | | | | | | | SI-7546 Use likely monotonic clock source for durations
| * | | | SI-7546 Use likely monotonic clock source for durationsSimon Ochsenreither2013-12-132-4/+7
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | System.currentTimeMillis is affected by wall-clock time, which means things can appear to jump back in time. Use System.nanoTime which is more likely¹ to be monotonic instead. ¹ See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6458294 "nanoTime affected by system clock change on Linux (RH9) or in general lacks monotonicity".
* | | | 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 #3240 from soc/SI-7618Adriaan Moors2013-12-131-10/+9
|\ \ \ \ | | | | | | | | | | SI-7618 Remove octal number literals
| * | | | SI-7618 Remove octal number literalsSimon Ochsenreither2013-12-091-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This also fixes a spurious detection of octal literals in floating point literals: Literals like 01.23 are neither deprecated nor planned for removal.
* | | | | Merge pull request #3214 from retronym/ticket/8024Adriaan Moors2013-12-131-1/+1
|\ \ \ \ \ | | | | | | | | | | | | SI-8024 Fix inaccurate message on overloaded ambiguous ident
| * | | | | SI-8024 Fix inaccurate message on overloaded ambiguous identJason Zaugg2013-12-121-1/+1
| | |_|_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `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-28/+46
|\ \ \ \ \ | | | | | | | | | | | | SI-6780 Better handling of cycles in in-scope implicit search
| * | | | | SI-6780 Refactor Context#implicitssJason Zaugg2013-12-111-30/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - split out a method for the part concernted with implicits from the current context - leaving the outer code to handle caching, cycle detection, and recursion up the context chain.
| * | | | | SI-6780 Better handling of cycles in in-scope implicit searchJason Zaugg2013-12-111-9/+24
| | |_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #3265 from retronym/merge/2.10.x-to-masterAdriaan Moors2013-12-132-1/+14
|\ \ \ \ \ | | | | | | | | | | | | Merge 2.10.x to master
| * \ \ \ \ Merge commit '9cdbe28' into merge/2.10.x-to-masterJason Zaugg2013-12-111-1/+1
| |\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: build.examples.xml build.xml docs/examples/actors/pingpong.scala docs/examples/fors.scala docs/examples/iterators.scala docs/examples/jolib/Ref.scala docs/examples/jolib/parallelOr.scala docs/examples/monads/callccInterpreter.scala docs/examples/monads/directInterpreter.scala docs/examples/monads/errorInterpreter.scala docs/examples/monads/simpleInterpreter.scala docs/examples/monads/stateInterpreter.scala docs/examples/parsing/ArithmeticParser.scala docs/examples/patterns.scala docs/examples/pilib/elasticBuffer.scala docs/examples/pilib/handover.scala docs/examples/pilib/piNat.scala docs/examples/typeinf.scala src/build/pack.xml
| | * | | | | SI-8060 Avoid infinite loop with higher kinded type aliasJason Zaugg2013-12-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `dealiasLocals` map was assuming that: tp.isAliasType implies (tp.dealias ne tp) This isn't true if `!typeParamsMatchArgs`. This commit avoids the infinite loop by checking whether or not dealiasing progresses.
| | * | | | | Merge pull request #3222 from skyluc/issue/completion-import-vals-210-7995Adriaan Moors2013-12-091-1/+5
| | |\ \ \ \ \ | | | | | | | | | | | | | | | | SI-7995 completion imported vars and vals
| | | * | | | | SI-7995 completion imported vars and valsLuc Bourlier2013-12-061-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Imported member vals and vars were always marked inaccessible, even if referencing them at the location of the completion is valid in code. The accessible flag is now set accordingly to the accessibility of the getter.
| * | | | | | | Merge commit 'a774157' into merge/2.10.x-to-masterJason Zaugg2013-12-111-0/+13
| |\| | | | | | | | |_|/ / / / | |/| | | | | | | | | | | | | | | | | | | Conflicts: src/compiler/scala/tools/nsc/transform/Erasure.scala
| | * | | | | Merge pull request #3223 from retronym/ticket/8010-2.10.xEugene Burmako2013-12-071-0/+13
| | |\ \ \ \ \ | | | | | | | | | | | | | | | | SI-8010 Fix regression in erasure double definition checks
| | | * | | | | SI-8010 Fix regression in erasure double definition checksJason Zaugg2013-12-061-0/+13
| | | |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calls to `Symbol#info` during scope iteration considered harmful. Looks like calling `info` during this Scope iteration is triggering the ExplicitOuter info transformer, which "makes all super accessors and modules in traits non-private, mangling their names.". This name change necessitates a rehashing of the owning scope, which I suspect is enough to corrupt the ScopeEntry-s being traversed in `checkNoDeclaredDoubleDefs`. The upshot was that we encountered the same symbol twice, which was reported as being a double-definition. This problem only showed up after 086702d8a74, which did nothing worse then change the order in which `{e, e1}.sym.info` were forced. I inspected SymbolPairs/OverridingPairs which *appear* to be immune as they only test flags during scope iteration; infos are not used until later, at which point we're iterating a temporary scope that isn't part of the type of the owner of the symbols.
| | * | | | | [nomaster] better error messages for various macro definition errorsEugene Burmako2013-12-061-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | backport of 1d3ec4e708154ec05554f540d7d68ed55dc12426
| | * | | | | Merge pull request #3209 from dotta/SI-7982-on-2.10.xJason Zaugg2013-12-065-15/+23
| | |\ \ \ \ \ | | | |/ / / / | | |/| | | | make askLoadedType unload arguments out of the PC by default,
| | | * | | | SI-7982 Changed contract of askLoadedType to unload units by defaultFrançois Garillot2013-12-065-15/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The rationale for not keeping units loaded by default is that the more units are loaded, the slower is background compilation. For instance, in the Scala IDE for Eclipse (which uses the presentation compiler), typechecking occurs every time the reconciler kicks-in (~500millis after you stop typing), hence it is important that units are not kept loaded unless strictly necessary (for some extra information about this, see https://www.assembla.com/spaces/scala-ide/tickets/1001388) While I agree that using a boolean argument (`keepLoaded`) for deciding if a unit should be loaded isn't a great design, other methods in `CompilerControl` also have a keepLoaded parameter, so at least we have some consistency. For the future, I'm thinking we should be able to remove the `keepLoaded` flag altogether, and change the implementation of `askLoadedType` to preserve the same units loaded in the presentation compiler before and after its execution. Basically, if you want a unit to be kept loaded, you should call `askReload` first, and then `askLoadedType`. However, to reduce impact, I think the changes carried by this commit will help us estimate if the solution I just outlined is viable (because `askLoadeType` won't be keeping units loaded by default, which wasn't the case with the former implementation). (While the patch was mostly contributed by @huitseeker, @dotta has edited the commit message to preserve the comments in the PR https://github.com/scala/scala/pull/3209)
| | * | | | | SI-7458 Pres. compiler must not observe trees in silent modeJason Zaugg2013-12-021-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise we can think that `+` in `1 + BigInt(2)` refers to a method in `Int`. In general, this protects the IDE from observing results from "exploratory" typing which is discarded as the compiler backtracks to another possibility. This protection subsumes the condition that checked for overloaded types: presentation/t7458 now passes without this.
| | * | | | | SI-7548 askTypeAt returns the same type whether the source was fully or ↵Mirco Dotta2013-12-021-9/+14
| | |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | targeted type-checked When asking for targeted typecheck, the located tree may have overloaded types is the source isn't yet fully typechecked (e.g., a select tree for an overloaded method). This is problematic as it can lead to unknown 'hovers', broken hyperlinking that suddenly starts working, unresolved ScalaDoc comments, and similar, in the Scala IDE. With this commit we are hardening the contract of `askTypeAt` to return the same type whether the file was fully type-checked or targeted type-checked. This is done by preventing the typechecker to stop too early if the `located` tree has an overloaded type. Furthermore, I'm assuming that if `located.tpe` is of type `OverloadedType`, by letting the compiler carry-on the typechecking, the `located.tpe` will eventually be resolved to a non-overloaded type. Said otherwise, I expect the targeted typechecking will always terminate (if my reasoning isn't sound, please say so). The test provided with this commit demonstrates the new behavior (the position used to execute the test is resolved to the `foo` method's call). In fact, before this commit, executing the test returned the following: (x: Int, y: String)Unit <and> (x: String)Unit <and> (x: Int)Unit Showing that the tree's type is an overloaded type. The ambiguity is fixed by this commit, and in fact the test's output is now: (x: Int)Unit
| | * | | | Merge pull request #3180 from xeno-by/topic/toolbox-rangeposJason Zaugg2013-11-261-2/+7
| | |\ \ \ \ | | | | | | | | | | | | | | teaches toolbox about -Yrangepos
| | | * | | | [nomaster] teaches toolbox about -YrangeposEugene Burmako2013-11-221-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unlike in master, in 2.10.x enabling -Yrangepos requires instantiating Global with mixed in RangePositions trait. Same story for toolboxes. Just setting Yrangepos is not enough - one needs to mix in RangePositions into ToolboxGlobal. I didn’t know that back then, so now I’m fixing the oversight. The commit is marked as [nomaster], because -Yrangepos doesn’t need special treatment in master.
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-30 00:42:28 +0000