summaryrefslogtreecommitdiff
path: root/test/files/presentation
Commit message (Collapse)AuthorAgeFilesLines
* SI-7475 Private members are not inheritableJason Zaugg2014-02-103-40/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out `findMembers` has been a bit sloppy in recent years and has returned private members from *anywhere* up the base class sequence. Access checks usually pick up the slack and eliminate the unwanted privates. But, in concert with the "concrete beats abstract" rule in `findMember`, the following mishap appeared: scala> :paste // Entering paste mode (ctrl-D to finish) trait T { def a: Int } trait B { private def a: Int = 0 } trait C extends T with B { a } // Exiting paste mode, now interpreting. <console>:9: error: method a in trait B cannot be accessed in C trait C extends T with B { a } ^ I noticed this when compiling Akka against JDK 8; a new private method in the bowels of the JDK was enough to break the build! It turns out that some finesse in needed to interpret SLS 5.2: > The private modifier can be used with any definition or declaration > in a template. They are not inherited by subclasses [...] So, can we simply exclude privates from all but the first base class? No, as that might be a refinement class! The following must be allowed: trait A { private def foo = 0; trait T { self: A => this.foo } } This commit: - tracks when the walk up the base class sequence passes the first non-refinement class, and excludes private members - ... except, if we are at a direct parent of a refinement class itself - Makes a corresponding change to OverridingPairs, to only consider private members if they are owned by the `base` Symbol under consideration. We don't need to deal with the subtleties of refinements there as that code is only used for bona-fide classes. - replaces use of `hasTransOwner` when considering whether a private[this] symbol is a member. The last condition was not grounded in the spec at all. The change is visible in cases like: // Old scala> trait A { private[this] val x = 0; class B extends A { this.x } } <console>:7: error: value x in trait A cannot be accessed in A.this.B trait A { private[this] val x = 0; class B extends A { this.x } } ^ // New scala> trait A { private[this] val x = 0; class B extends A { this.x } } <console>:8: error: value x is not a member of A.this.B trait A { private[this] val x = 0; class B extends A { this.x } } ^ Furthermore, we no longer give a `private[this]` member a free pass if it is sourced from the very first base class. trait Cake extends Slice { private[this] val bippy = () } trait Slice { self: Cake => bippy // BCS: Cake, Slice, AnyRef, Any } The different handling between `private` and `private[this]` still seems a bit dubious. The spec says: > An different form of qualification is private[this]. A member M > marked with this modifier can be accessed only from within the > object in which it is defined. That is, a selection p.M is only > legal if the prefix is this or O.this, for some class O enclosing > the reference. In addition, the restrictions for unqualified > private apply. This sounds like a question of access, not membership. If so, we should admit `private[this]` members from parents of refined types in `FindMember`. AFAICT, not too much rests on the distinction: do we get a "no such member", or "member foo inaccessible" error? I welcome scrutinee of the checkfile of `neg/t7475f.scala` to help put this last piece into the puzzle. One more thing: findMember does not have *any* code the corresponds to the last sentence of: > SLS 5.2 The modifier can be qualified with an identifier C > (e.g. private[C]) that must denote a class or package enclosing > the definition. Members labeled with such a modifier are accessible > respectively only from code inside the package C or only from code > inside the class C and its companion module (§5.4). > Such members are also inherited only from templates inside C. When I showed Martin this, he suggested it was an error in the spec, and we should leave the access checking to callers of that inherited qualified-private member.
* SI-7475 findMember and findMembers: estranged no moreJason Zaugg2014-02-102-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Swathes of important logic are duplicated between `findMember` and `findMembers` after they separated on grounds of irreconcilable differences about how fast they should run: d905558 Variation #10 to optimze findMember fcb0c01 Attempt #9 to opimize findMember. 71d2ceb Attempt #8 to opimize findMember. 77e5692 Attempty #7 to optimize findMember 275115e Fixing problem that caused fingerprints to fail in e94252e Attemmpt #6 to optimize findMember 73e61b8 Attempt #5 to optimize findMember. 04f0b65 Attempt #4 to optimize findMember 0e3c70f Attempt #3 to optimize findMember 41f4497 Attempt #2 to optimize findMember 1a73aa0 Attempt #1 to optimize findMember This didn't actually bear fruit, and the intervening years have seen the implementations drift. Now is the time to reunite them under the banner of `FindMemberBase`. Each has a separate subclass to customise the behaviour. This is primarily used by `findMember` to cache member types and to assemble the resulting list of symbols in an low-allocation manner. While there I have introduced some polymorphic calls, the call sites are only bi-morphic, and our typical pattern of compilation involves far more `findMember` calls, so I expect that JIT will keep the virtual call cost to an absolute minimum. Test results have been updated now that `findMembers` correctly excludes constructors and doesn't inherit privates. Coming up next: we can actually fix SI-7475!
* SI-8129 Make Object#== override Any#==Jason Zaugg2014-02-109-48/+16
| | | | | | | | | | | | | | | | | | | | And the same for != If we tried to declare these signatures in non-fictional classes, we would be chastised about collapsing into the "same signature after erasure". This will have an influence of typing, as the typechecking of arguments is sensitive to overloading: if multiple variants are feasible, the argument will be typechecked with a wildcard expected type. So people inspecting the types of the arguments to `==` before this change might have seen an interesting type for `if (true) x else y`, but now the `If` will have type `Any`, as we don't need to calculate the LUB. I've left a TODO to note that we should really make `Any#{==, !=}` non-final and include a final override in `AnyVal`. But I don't think that is particularly urgent.
* Merge commit '97b9b2c06a' from 2.10.x into masterAdriaan Moors2014-01-1712-0/+106
|\ | | | | | | | | | | | | | | | | Check files updated: test/files/presentation/t8085*.check Conflicts: build.xml src/compiler/scala/tools/nsc/ast/parser/Parsers.scala src/compiler/scala/tools/nsc/symtab/classfile/ICodeReader.scala
| * SI-8085 Fix BrowserTraverser for package objectsJason Zaugg2013-12-1810-11/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A source file like: import foo.bar package object baz Is parsed into: package <empty> { import foo.bar package baz { object `package` } } A special case in Namers compensates by adjusting the owner of `baz` to be `<root>`, rather than `<empty>`. This wasn't being accounted for in `BrowserTraverser`, which underpins `-sourcepath`, and allows the presentation compiler to load top level symbols from sources outside those passes as the list of sources to compile. This bug did not appear in sources like: package p1 package object p2 { ... } ... because the parser does not wrap this in the `package <empty> {}` This goes some way to explaining why it has gone unnoticed for so long.
| * Test demonstrating SI-8085Mirco Dotta2013-12-186-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * The presentation compiler sourcepath is now correctly set-up. * Amazingly enough (for me at least), the outer import in the package object seem to be responsible of the faulty behavior. In fact, if you move the import clause *inside* the package object, the test succeed! The test's output does provide the correct hint of this: ``` % diff /Users/mirco/Projects/ide/scala/test/files/presentation/t8085-presentation.log /Users/mirco/Projects/ide/scala/test/files/presentation/t8085.check @@ -1,3 +1,2 @@ reload: NodeScalaSuite.scala -prefixes differ: <empty>.nodescala,nodescala -value always is not a member of object scala.concurrent.Future +Test OK ``` Notice the ``-prefixes differ: <empty>.nodescala,nodescala``. And compare it with the output when the import clause is placed inside the package object: ``` % diff /Users/mirco/Projects/ide/scala/test/files/presentation/t8085-presentation.log /Users/mirco/Projects/ide/scala/test/files/presentation/t8085.check @@ -1,4 +1,2 @@ reload: NodeScalaSuite.scala -reload: NodeScalaSuite.scala -open package module: package object nodescala Test OK ``` Notice now the ``-open package module: package object nodescala``!
* | SI-8135 Disabled flaky hyperlinking presentation compiler testMirco Dotta2014-01-103-67/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This PR (https://github.com/scala/scala/pull/3275#issuecomment-31986434) demonstrates that the test is flaky. The disabled test was introduced with the intent of preventing a regression (here is the commit https://github.com/scala/scala/commit/ccacb06c4928fd6aebc2c2539d7565cb079dc625). It looks like there is a race condition when `askTypeAt(pos)` is called on `implicitly[Foo[A]].foo` where `pos` is matches the end point of the former expression. The issue is that the returned Tree is unattributed, which is why the error "No symbol is associated with tree implicitly[Foo[A]].foo" is reported.
* | Merge pull request #3342 from xeno-by/topic/pres-compiler-macrosJason Zaugg2014-01-093-0/+30
|\ \ | | | | | | Presentation compiler friendliness for macros
| * | Use macro expandee, rather than expansion, in pres. compilerJason Zaugg2014-01-082-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The presentation compiler is primarily interested in trees that represent the code that one sees in the IDE, not the expansion of macros. This commit continues to expand macros, but adds a hook in which the presentation compiler discards the expansion, retaining instead the expandee. The expandee is attributed with the type of the expansion, which allows white box macros to work. In addition, any domain specific errors and warnings issued by the macro will still be reported, as a side-effect of the expansion. The failing test from the last commit now correctly resolves hyperlinks in macro arguments. Related IDE ticket: https://www.assembla.com/spaces/scala-ide/tickets/1001449# This facility is configured as follows: // expand macros as per normal -Ymacro-expand:normal // don't expand the macro, takes the place of -Ymacro-no-expand -Ymacro-expand:none // expand macros to compute type and emit warnings, // but retain expandee. Set automatically be the presentation // compiler -Ymacro-expand:discard This leaves to door ajar for a new option: // Don't expand blackbox macros; expand whitebox // but retain expandee -Ymacro-expand:discard-whitebox-only The existing test for SI-6812 has been duplicated. One copy exercises the now-deprecated -Ymacro-no-expand, and the other uses the new option.
| * | Test to show the bug with hyperlinking in macro argumentsJason Zaugg2014-01-083-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | Currently, the presentation compiler sees the expansion of macros; this no longer contains the trees corresponding to the macro arguments, and hyperlink requests result incorrect results. https://www.assembla.com/spaces/scala-ide/tickets/1001449#
* | | Merge pull request #3269 from dotta/issue/si-4287Jason Zaugg2014-01-0913-0/+134
|\ \ \ | |/ / |/| | Issue/si 4287
| * | SI-4827 Corrected positions assigned to constructor's default argMirco Dotta2014-01-085-4/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Default arguments are always retained on the <init> method (i.e., the class' constructor). Therefore, when the <init> parameters are created, we need to use `duplicateAndKeepPositions` to make sure that if a default argument is present, its opaque position is retained as well. This is necessary because when parameter accessors (i.e., `fieldDefs`) are created, all default arguments are discared ( as you can see in the code, the right-hand-side of a `field` is always an `EmptyTree`) - see changes in TreeGen.scala * When constructing the `fieldDefs`, it is important to adapt their range position to avoid overlappings with the positions of default arguments. It is worth noting that updating the field's end position to `vd.rhs.pos.start` would be incorrect, because `askTypeAt(pos)` could return the incorrect tree when the position is equal to `vd.rhs.pos.start` (because two nodes including that point position would exist in the tree, and `CompilerControl.locateTree(pos)` would return the first tree that includes the passed `pos`). This is why `1` is subtracted to `vd.rhs.pos.start`. Alternatively, we could have used `vd.tpt.pos.end` with similar results. However the logic would have become slightly more complex as we would need to handle the case where `vd.tpt` doesn't have a range position (for instance, this can happen if `-Yinfer-argument-types` is enabled). Therefore, subtracting `1` from `vd.rhs.pos.start` seemed the cleanest solution at the moment. - see changes in TreeGen.scala. * If the synthetic constructor contains trees with an opaque range position (see point above), it must have a transparent position. This can only happen if the constructor's parameters' positions are considered, which is why we are now passing `vparamss1` to `wrappingPos` - see changes in TreeGen.scala. * The derived primary constructor should have a transparent position as it may contain trees with an opaque range position. Hence, the `primaryCtor` position is considered for computing the position of the derived constructor - see change in Typers.scala. Finally, below follows the printing of the tree for test t4287, which you should compare with the one attached with the previous commit message: ``` [[syntax trees at end of typer]] // Foo.scala [0:63]package [0:0]<empty> { [0:37]class Baz extends [9:37][39]scala.AnyRef { [10:20]<paramaccessor> private[this] val f: [14]Int = _; [14]<stable> <accessor> <paramaccessor> def f: [14]Int = [14][14]Baz.this.f; <10:31>def <init>(<10:31>f: [17]<type: [17]scala.Int> = [23:31]B.a): [9]Baz = <10:31>{ <10:31><10:31><10:31>Baz.super.<init>(); <10:31>() } }; [6]<synthetic> object Baz extends [6][6]AnyRef { [6]def <init>(): [9]Baz.type = [6]{ [6][6][6]Baz.super.<init>(); [9]() }; [14]<synthetic> def <init>$default$1: [14]Int = [30]B.a }; [39:63]object B extends [48:63][63]scala.AnyRef { [63]def <init>(): [48]B.type = [63]{ [63][63][63]B.super.<init>(); [48]() }; [52:61]private[this] val a: [56]Int = [60:61]2; [56]<stable> <accessor> def a: [56]Int = [56][56]B.this.a } } ``` You should notice that the default arg of `Baz` constructor now has a range position. And that explains why the associated test now returns the right tree when asking hyperlinking at the location of the default argument.
| * | SI-4827 Test to demonstrate wrong position of constructor default argMirco Dotta2013-12-123-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As demonstrated by the attached test, hyperlinking on constructor's default arg doesn't work (the returned tree is the parameter tree, i.e., `f`, which is of course wrong). Printing the tree reveals the issue: `` [[syntax trees at end of typer]] // Foo.scala [0:63]package [0:0]<empty> { [0:37]class Baz extends [9:37][39]scala.AnyRef { [10:31]<paramaccessor> private[this] val f: [14]Int = _; [14]<stable> <accessor> <paramaccessor> def f: [14]Int = [14][14]Baz.this.f; [39]def <init>([14]f: [17]<type: [17]scala.Int> = [30]B.a): [9]Baz = [39]{ [39][39][39]Baz.super.<init>(); [9]() } }; [6]<synthetic> object Baz extends [6][6]AnyRef { [6]def <init>(): [9]Baz.type = [6]{ [6][6][6]Baz.super.<init>(); [9]() }; [14]<synthetic> def <init>$default$1: [14]Int = [30]B.a }; [39:63]object B extends [48:63][63]scala.AnyRef { [63]def <init>(): [48]B.type = [63]{ [63][63][63]B.super.<init>(); [48]() }; [52:61]private[this] val a: [56]Int = [60:61]2; [56]<stable> <accessor> def a: [56]Int = [56][56]B.this.a } } `` In short, the default argument in `<init>` (the constructor) has an offset position, while we would expect it to have a range position. Therefore, when locating a tree for any position between (start=) 10 and (end=) 31, the paramaccessor tree `f` is returned. The next commit will correct the problem.
| * | SI-4287 Added test demonstrating hyperlinking to constructor's argumentMirco Dotta2013-12-123-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This test was inspired by `test/files/run/t5603`, whose output (.check file) will need to be updated in the upcoming commit that fixes SI-4287, because the positions associated to the tree have slightly changed. The additional test should demonstrate that the change in positions isn't relevant, and it doesn't affect functionality. In fact, hyperlinking to a constructor's argument work as expected before and after fixing SI-4287.
| * | Presentation compiler hyperlinking on context bounds testMirco Dotta2013-12-123-0/+67
| | | | | | | | | | | | | | | Added test to the presentation compiler regression suite to exercise hyperlinking on context bounds.
* | | Merge pull request #3262 from densh/si/8030Adriaan Moors2013-12-135-17/+167
|\ \ \ | | | | | | | | SI-8030 force symbols on presentation compiler initialization
| * | | SI-8030 force symbols on presentation compiler initializationDen Shabalin2013-12-125-17/+167
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | This commit forces a number of built-in symbols in presentation compiler to prevent them from being entered during parsing. The property “parsing doesn’t enter new symbols” is tested on a rich source file that contains significant number of variations of Scala syntax.
* | | Merge commit '0c92704' into merge/2.10.x-to-masterJason Zaugg2013-12-115-58/+112
|\ \ \ | |/ / |/| / | |/ | | | | | | | | | | | | | | | | Conflicts: bincompat-forward.whitelist.conf src/interactive/scala/tools/nsc/interactive/Global.scala test/files/presentation/scope-completion-2.check test/files/presentation/scope-completion-3.check test/files/presentation/scope-completion-import.check Conflicts in the scope completion tests handled with the help of @skyluc in https://github.com/scala/scala/pull/3264
| * Merge pull request #3222 from skyluc/issue/completion-import-vals-210-7995Adriaan Moors2013-12-095-53/+107
| |\ | | | | | | SI-7995 completion imported vars and vals
| | * SI-7995 completion imported vars and valsLuc Bourlier2013-12-065-53/+107
| | | | | | | | | | | | | | | | | | 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 pull request #3209 from dotta/SI-7982-on-2.10.xJason Zaugg2013-12-063-0/+35
| |\ \ | | |/ | |/| make askLoadedType unload arguments out of the PC by default,
* | | Merge commit '7d41094' into merge/2.10.x-and-pr-3209-to-masterJason Zaugg2013-12-063-0/+35
|\ \ \ | | |/ | |/| | | | | | | Conflicts: src/interactive/scala/tools/nsc/interactive/CompilerControl.scala
| * | SI-7982 Changed contract of askLoadedType to unload units by defaultFrançois Garillot2013-12-063-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* | | Merge commit '7c1d114' into merge-2.10.x-to-masterJason Zaugg2013-12-066-0/+55
|\ \ \ | | |/ | |/| | | | | | | Conflicts: src/compiler/scala/tools/nsc/interactive/Global.scala
| * | SI-7458 Pres. compiler must not observe trees in silent modeJason Zaugg2013-12-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Test to demonstrate residual exploratory typing bugJason Zaugg2013-12-023-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We shouldn't observe tree types under silent mode. The enclosed test is a standalone version of `1 + BigInt(2)`, a standard example of exploratory typing in Scala. Once we determine that none of the `+` methods in `Int` accepts (possibly implicitly coerced `BigInt`), we have to backtrack and look for a view from `Int => { +(_: BigInt): ? }`. The next commit will correct the problem.
| * | SI-7548 askTypeAt returns the same type whether the source was fully or ↵Mirco Dotta2013-12-023-0/+25
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #3166 from skyluc/issue/completion-import-object-7280-210Jason Zaugg2013-11-2224-16/+931
| |\ | | | | | | Backport of
| | * [nomaster] SI-7280 Scope completion not returning members provided by importsLuc Bourlier2013-11-213-0/+208
| | | | | | | | | | | | | | | | | | | | | | | | | | | Updates localeContext() to return the best context possible when there are none directly associated with the given position. It happens when an expression cannot be successfully typed, as no precise ContextTree covers the expression location, or if the position is not inside any expression. Adds corresponding tests (cherry picked from commit 3028327e2a2b553b12ee45519413515c8aa0865f)
| | * [nomaster] Adds test cases for scope completionLuc Bourlier2013-11-2112-0/+707
| | | | | | | | | | | | (cherry picked from commit 3d55fe723f1af91f4d2db421f0e0965c583346dc)
| | * [nomaster] Test infrastructure for scope completionJason Zaugg2013-11-219-16/+16
| | | | | | | | | | | | | | | | | | Adds a new marker /*_*/ to trigger scope completion test. Original type completion test oracles update for the tweaked output (cherry picked from commit 9c7c66ff7907e3ab814f0f4375eeaf6cdd230d5e)
| * | SI-7915 Corrected range positions created during default args expansionMirco Dotta2013-11-193-0/+28
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tree created during expansion of default arguments contained trees with the wrong type of positions. Let's discuss this with an example. Below is the tree generated for the `foo` method in the test class included in this commit. Before this commit: ``` [54:94]def foo(): [58]Unit = <70:90>{ [70:79]<artifact> val qual$1: [70]Bar = [70:79][70:79][70:79]new [74:77]Bar(); [80]<artifact> val x$1: [80]Int = [80]qual$1.bar$default$1; <70:90><70:83>qual$1.bar([80]x$1) } ``` Now: ``` [54:99]def foo(): [58]Unit = <70:95>{ <70:84><artifact> val qual$1: [70]Bar = [70:84][70:84][70:84]new [74:77]Bar(); [85]<artifact> val x$1: [85]Int = [85]qual$1.bar$default$1; <70:95>[84:88]qual$1.bar([85]x$1) } ``` Here are the list of changes: * The synthetic `qual$1` has a transparent position, instead of a range position. * The new Select tree (i.e., `qual$1.bar`) should always have a range position, because `selected` (i.e., the called method) is always visible in the source (in fact, this is the whole point of the fix, we need a range position or hyperlinking request from the Scala IDE won't work). * The Block that contains the expanded default arguments is forced to have a transparent position, as it never exist in the original source. The tricky part of the fix is the position assigned to the new Select tree, which needs to respect the range position's invariants. In the specific case, we ought to make sure that range positions don't overlap. Therefore, the position assigned to the new Select tree is computed by intersecting the original Select position (i.e., `baseFun`'s position) and the original qualifier's position (i.e., `qual`'s position). If you take a closer look at the range positions assigned in the tree after this commit, you'll notice that the range position of the `qual$1`'s rhs (i.e., [70:84]), and `qual$1.bar` (i.e., [84:88]) might seem to overlap, because the former ends where the latter begins. However, this not the case because of the range position's invariant 2, which states: > Invariant 2: in a range position, start <= point < end Hence, the above two positions aren't overlapping as far as the compiler is concerned. One additional aspect (that may look like a detail) is that we make sure to never generate a position such that its start is after its end. This is why we take the position with the smallest end point. Furthermore, calling `withStart` would turn any position in a range position, which isn't desiderable in general (and, even worse, this can lead to generation of invalid positions - bad offsets - if the computation is performed on offset positions). Hence, the position's computation is only performed when both `baseFun` and `qual` positions are range positions. Indeed, I expect this to be always the case if the compiler is started with -Yrangepos. (cherry picked from commit 3009a525b58a4c7865ff524899b85518884ee5f7)
* | deprecate Pair and TripleDen Shabalin2013-11-202-18/+22
| |
* | Merge pull request #3140 from skyluc/issue/completion-import-object-7280Jason Zaugg2013-11-1825-22/+937
|\ \ | | | | | | SI-7280 Scope completion not returning members provided by imports
| * | SI-7280 Scope completion not returning members provided by importsLuc Bourlier2013-11-153-0/+208
| | | | | | | | | | | | | | | | | | | | | | | | Updates localeContext() to return the best context possible when there are none directly associated with the given position. It happens when an expression cannot be successfully typed, as no precise ContextTree covers the expression location, or if the position is not inside any expression. Adds corresponding tests
| * | Adds test cases for scope completionLuc Bourlier2013-11-1512-0/+707
| | |
| * | Test infrastructure for scope completionJason Zaugg2013-11-1510-22/+22
| | | | | | | | | | | | | | | Adds a new marker /*_*/ to trigger scope completion test. Original type completion test oracles update for the tweaked output
* | | Merge pull request #3136 from dotta/issue/si-7915Jason Zaugg2013-11-183-0/+28
|\ \ \ | |/ / |/| | SI-7915 Corrected range positions created during default args expansion
| * | SI-7915 Corrected range positions created during default args expansionMirco Dotta2013-11-153-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tree created during expansion of default arguments contained trees with the wrong type of positions. Let's discuss this with an example. Below is the tree generated for the `foo` method in the test class included in this commit. Before this commit: ``` [54:94]def foo(): [58]Unit = <70:90>{ [70:79]<artifact> val qual$1: [70]Bar = [70:79][70:79][70:79]new [74:77]Bar(); [80]<artifact> val x$1: [80]Int = [80]qual$1.bar$default$1; <70:90><70:83>qual$1.bar([80]x$1) } ``` Now: ``` [54:99]def foo(): [58]Unit = <70:95>{ <70:84><artifact> val qual$1: [70]Bar = [70:84][70:84][70:84]new [74:77]Bar(); [85]<artifact> val x$1: [85]Int = [85]qual$1.bar$default$1; <70:95>[84:88]qual$1.bar([85]x$1) } ``` Here are the list of changes: * The synthetic `qual$1` has a transparent position, instead of a range position. * The new Select tree (i.e., `qual$1.bar`) should always have a range position, because `selected` (i.e., the called method) is always visible in the source (in fact, this is the whole point of the fix, we need a range position or hyperlinking request from the Scala IDE won't work). * The Block that contains the expanded default arguments is forced to have a transparent position, as it never exist in the original source. The tricky part of the fix is the position assigned to the new Select tree, which needs to respect the range position's invariants. In the specific case, we ought to make sure that range positions don't overlap. Therefore, the position assigned to the new Select tree is computed by intersecting the original Select position (i.e., `baseFun`'s position) and the original qualifier's position (i.e., `qual`'s position). If you take a closer look at the range positions assigned in the tree after this commit, you'll notice that the range position of the `qual$1`'s rhs (i.e., [70:84]), and `qual$1.bar` (i.e., [84:88]) might seem to overlap, because the former ends where the latter begins. However, this not the case because of the range position's invariant 2, which states: > Invariant 2: in a range position, start <= point < end Hence, the above two positions aren't overlapping as far as the compiler is concerned. One additional aspect (that may look like a detail) is that we make sure to never generate a position such that its start is after its end. This is why we take the position with the smallest end point. Furthermore, calling `withStart` would turn any position in a range position, which isn't desiderable in general (and, even worse, this can lead to generation of invalid positions - bad offsets - if the computation is performed on offset positions). Hence, the position's computation is only performed when both `baseFun` and `qual` positions are range positions. Indeed, I expect this to be always the case if the compiler is started with -Yrangepos.
* | | Merge commit '6045a05b83' into merge-2.10Adriaan Moors2013-11-133-0/+44
|\ \ \ | |/ / |/| / | |/ | | Conflicts: src/interactive/scala/tools/nsc/interactive/Global.scala
| * Fix completion after application with implicit argumentsJason Zaugg2013-11-063-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | `List(1, 2, 3).map(f).<ctrl-space>` now works; before the tree had the type `(bf: CanBuildFrom[...]):...` and did not contribute completions from the result type. This commit checks if the tree has an implicit method type, and typechecks it as a qualifier. That is enough to get to `adaptToImplicitMethod` in the type checker, infer the implicit arguments, and compute the final result type accordingly.
* | Merge pull request #3112 from adriaanm/modularize-scaladocJames Iry2013-11-131-1/+16
|\ \ | | | | | | Modularize scaladoc... almost
| * | Refactoring to prepare modularization of the compiler.Adriaan Moors2013-11-121-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Actual modularization is delayed until 2.12. The one big (one-line) change is to make the interactive compiler independent of scaladoc. We have one "integration test": `MemoryLeaksTest`. This commit adds a bunch of comments marked `TODO: modularize the compiler`, that should be uncommented when we're ready to continue the modularization effort. I decided to merge them commented out to avoid having to rebase xml patches. There's still some chance of bitrot, but I'm willing to take my chances. I previously refactored the build to make it easier to add jars in a coherent way, which hinges on the `init-project-prop` mechanism, so the relevant properties are already injected there.
* | | Make parameters to implicit value classes privateJason Zaugg2013-11-128-75/+15
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So that they aren't offered as an autocomplete suggestion: implicit class Shouty(string: String) extends AnyVal { def SHOUT_! = string.toUpperCase + "!" } "". // autocompletion offers `.string` here The original incarnation of value classes didn't allow this sort of encapsulation, so we either invented goofy names like `__thingToAdd` or just picked `x` or `self`. But SI-7859 has delivered us the freedom to keep the accessor private. Should we keep any of these accessors around in a deprecated form? The implicit classes in Predef were added in 2.11.0-M2 (c26a8db067e4f), so they are okay. I think we can make reason that these APIs were both accidental and unlikely to be interpreted as public, so we can break them immediately. scala> Left(1).x res0: scala.util.Either[Int,Int] = Left(1) scala> import concurrent.duration._ import concurrent.duration._ scala> 1.n res1: Int = 1
* | SI-7678 Don't cache member symbols of TypeTags in Definitions.Jason Zaugg2013-11-083-0/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Remove orphaned check files and flags files.Jason Zaugg2013-10-271-1/+0
| | | | | | | | (for f in $(find test -name '*.check' -o -name '*.flags'); do bare=$(echo $f | sed -E 's/\.\w+$//'); ([[ -f "$bare" ]] || [[ -d "$bare" ]] || [[ -f "$bare.scala" ]] || [[ -f "$bare.test" ]] || echo $f) done;) | xargs rm
* | Merge remote-tracking branch 'origin/2.10.x' into merge/2.10.x-to-master-4Jason Zaugg2013-10-185-169/+0
|\|
| * Disable flaky presentation compiler test.Jason Zaugg2013-10-175-161/+0
| | | | | | | | | | | | | | | | Francois is investigating the root cause as part of his work on stabilizing Scaladoc preview in the IDE. The test seems to only fail on the windows nightly build. I suspect this is due to a slower or loaded machine.
* | Cull extraneous whitespace.Paul Phillips2013-09-1811-43/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One last flurry with the broom before I leave you slobs to code in your own filth. Eliminated all the trailing whitespace I could manage, with special prejudice reserved for the test cases which depended on the preservation of trailing whitespace. Was reminded I cannot figure out how to eliminate the trailing space on the "scala> " prompt in repl transcripts. At least reduced the number of such empty prompts by trimming transcript code on the way in. Routed ConsoleReporter's "printMessage" through a trailing whitespace stripping method which might help futureproof against the future of whitespace diseases. Deleted the up-to-40 lines of trailing whitespace found in various library files. It seems like only yesterday we performed whitespace surgery on the whole repo. Clearly it doesn't stick very well. I suggest it would work better to enforce a few requirements on the way in.
* | SI-7643 Enable newPatternMatching in interactive.Jason Zaugg2013-09-064-0/+18
| | | | | | | | | | | | | | | | | | | | Without it, the enclosed test fails with: ArrayBuffer(Problem(RangePosition(partial-fun/src/PartialFun.scala, 62, 62, 77),type mismatch; found : Int => Int required: PartialFunction[Int,Int],2)) And with that, we can remove this option altogether.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-21 18:06:37 +0000