summaryrefslogtreecommitdiff
path: root/test/files/presentation
Commit message (Collapse)AuthorAgeFilesLines
* Replace println with log calls in BrowsingLoadersIulian Dragos2016-10-192-2/+0
| | | | | | | This alternative symbol loader is used in the presentation compiler and may generate output even when the compiler should be silent. See SI-8717 for more context, even though this does not really fix the ticket.
* Fields phase expands lazy vals like modulesAdriaan Moors2016-08-292-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | They remain ValDefs until then. - remove lazy accessor logic now that we have a single ValDef for lazy vals, with the underlying machinery being hidden until the fields phase leave a `@deprecated def lazyAccessor` for scala-refactoring - don't skolemize in purely synthetic getters, but *do* skolemize in lazy accessor during typers Lazy accessors have arbitrary user code, so have to skolemize. We exempt the purely synthetic accessors (`isSyntheticAccessor`) for strict vals, and lazy accessors emitted by the fields phase to avoid spurious type mismatches due to issues with existentials (That bug is tracked as https://github.com/scala/scala-dev/issues/165) When we're past typer, lazy accessors are synthetic, but before they are user-defined to make this hack less hacky, we could rework our flag usage to allow for requiring both the ACCESSOR and the SYNTHETIC bits to identify synthetic accessors and trigger the exemption. see also https://github.com/scala/scala-dev/issues/165 ok 7 - pos/existentials-harmful.scala ok 8 - pos/t2435.scala ok 9 - pos/existentials.scala previous attempt: skolemize type of val inside the private[this] val because its type is only observed from inside the accessor methods (inside the method scope its existentials are skolemized) - bean accessors have regular method types, not nullary method types - must re-infer type for param accessor some weirdness with scoping of param accessor vals and defs? - tailcalls detect lazy vals, which are defdefs after fields - can inline constant lazy val from trait - don't mix in fields etc for an overridden lazy val - need try-lift in lazy vals: the assign is not seen in uncurry because fields does the transform (see run/t2333.scala) - ensure field members end up final in bytecode - implicit class companion method: annot filter in completer - update check: previous error message was tangled up with unrelated field definitions (`var s` and `val s_scope`), now it behaves consistently whether those are val/vars or defs - analyzer plugin check update seems benign, but no way to know... - error message gen: there is no underlying symbol for a deferred var look for missing getter/setter instead - avoid retypechecking valdefs while duplicating for specialize see pos/spec-private - Scaladoc uniformly looks to field/accessor symbol - test updates to innerClassAttribute by Lukas
* Determistically enter classes from directory into package scopeJason Zaugg2016-08-191-4/+1
| | | | | | | | | | | | | | | | | | | | On Linux, the directory listing is not automatically sorted on Mac. This leads to non-determistic ids of Symbols of the classes in a directory, which in turn leads to instability of the ordering of parents within inferred refinement types. Notable, with this patch, we will stably infer: ``` scala> case class C(); case class D(); List(C(), D()).head defined class C defined class D res0: Product with Serializable = C() ``` rather than sometimes getting `Serializable with Product` on Linux. As such, I've removed the workarounds for this instability in two test cases.
* Fields phaseAdriaan Moors2016-08-116-31/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One step towards teasing apart the mixin phase, making each phase that adds members to traits responsible for mixing in those members into subclasses of said traits. Another design tenet is to not emit symbols or trees only to later remove them. Therefore, we model a val in a trait as its accessor. The underlying field is an implementation detail. It must be mixed into subclasses, but has no business in a trait (an interface). Also trying to reduce tree creation by changing less in subtrees during tree transforms. A lot of nice fixes fall out from this rework: - Correct bridges and more precise generic signatures for mixed in accessors, since they are now created before erasure. - Correct enclosing method attribute for classes nested in trait fields. Trait fields are now created as MethodSymbol (no longer TermSymbol). This symbol shows up in the `originalOwner` chain of a class declared within the field initializer. This promoted the field getter to being the enclosing method of the nested class, which it is not (the EnclosingMethod attribute is a source-level property). - Signature inference is now more similar between vals and defs - No more field for constant-typed vals, or mixed in accessors for subclasses. A constant val can be fully implemented in a trait. TODO: - give same treatment to trait lazy vals (only accessors, no fields) - remove support for presuper vals in traits (they don't have the right init semantics in traits anyway) - lambdalift should emit accessors for captured vals in traits, not a field Assorted notes from the full git history before squashing below. Unit-typed vals: don't suppress field it affects the memory model -- even a write of unit to a field is relevant... unit-typed lazy vals should never receive a field this need was unmasked by test/files/run/t7843-jsr223-service.scala, which no longer printed the output expected from the `0 to 10 foreach` Use getter.referenced to track traitsetter reify's toolbox compiler changes the name of the trait that owns the accessor between fields and constructors (`$` suffix), so that the trait setter cannot be found when doing mkAssign in constructors this could be solved by creating the mkAssign tree immediately during fields anyway, first experiment: use `referenced` now that fields runs closer to the constructors phase (I tried this before and something broke) Infer result type for `val`s, like we do for `def`s The lack of result type inference caused pos/t6780 to fail in the new field encoding for traits, as there is no separate accessor, and method synthesis computes the type signature based on the ValDef tree. This caused a cyclic error in implicit search, because now the implicit val's result type was not inferred from the super member, and inferring it from the RHS would cause implicit search to consider the member in question, so that a cycle is detected and type checking fails... Regardless of the new encoding, we should consistently infer result types for `def`s and `val`s. Removed test/files/run/t4287inferredMethodTypes.scala and test/files/presentation/t4287c, since they were relying on inferring argument types from "overridden" constructors in a test for range positions of default arguments. Constructors don't override, so that was a mis-feature of -Yinfer-argument-types. Had to slightly refactor test/files/presentation/doc, as it was relying on scalac inferring a big intersection type to approximate the anonymous class that's instantiated for `override lazy val analyzer`. Now that we infer `Global` as the expected type based on the overridden val, we make `getComment` private in navigating between good old Skylla and Charybdis. I'm not sure why we need this restriction for anonymous classes though; only structural calls are restricted in the way that we're trying to avoid. The old behavior is maintained nder -Xsource:2.11. Tests: - test/files/{pos,neg}/val_infer.scala - test/files/neg/val_sig_infer_match.scala - test/files/neg/val_sig_infer_struct.scala need NMT when inferring sig for accessor Q: why are we calling valDefSig and not methodSig? A: traits use defs for vals, but still use valDefSig... keep accessor and field info in synch
* Switch the bootstrap build over to sbtStefan Zeiger2016-07-151-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | All of the individual ant builds that occured during `bootstrap` are replaced by equivalent sbt builds. - Allow extra dashes in version suffix when using SPLIT - Clean up ScriptCommands - Building an extra `locker` for stability testing with ant was not necessary but sbt also drops `strap`, so we need to build again with `quick` to get the equivalent of `strap`. The script for checking stability is invoked directly from the bootstrap script, not from sbt. - `STARR` and `locker` build output is still logged to `logs/builds`, the main build runs log directly to the main console with colored output. - Allow `—show-log` option on partest command line in sbt - Normalize inferred LUB in `run/t7747-repl.scala` - Add `normalize` feature from `ReplTest` to `InteractiveTest` - Normalize inferred LUBs in `presentation/callcc-interpreter`
* Right-bias EitherSimon Ochsenreither2016-05-272-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Add operations like map, flatMap which assume right-bias - Deprecate {Left,Right}Projection - Deprecate left and right in favor of swap - Add contains, toOption, toTry, toSeq and filterOrElse - toSeq returns collection.immutable.Seq instead of collection.Seq - Don't add get There are no incompatible changes. The only possibility of breakage that exists is when people have added extension methods named map, flatMap etc. to Either in the past doing something different than the methods added to Either now. One detail that moved the scales in favor of deprecating LeftProjection and RightProjection was the desire to have toSeq return scala.collection.immutable.Seq instead of scala.collection.Seq like LeftProjection and RightProjection do. Therefore keeping LeftProjection and RightProjection would introduce inconsistency. filter is called filterOrElse because filtering in a for-comprehension doesn't work if the method needs an explicit argument. contains was added as safer alternative to if (either.isRight && either.right.get == $something) ... While adding filter with an implicit zero value is possible, it's dangerous as it would require that developers add a "naked" implicit value of type A to their scope and it would close the door to a future in which the Scala standard library ships with Monoid and filter could exist with an implicit Monoid parameter.
* SI-9684 Deprecate JavaConversionsSom Snytt2016-04-221-1/+1
| | | | | | | | | Implicit conversions are now in package convert as ImplicitConversions, ImplicitConversionsToScala and ImplicitConversionsToJava. Deprecated WrapAsJava, WrapAsScala and the values in package object. Improve documentation.
* Fix some typos in `spec` documents and comments.Dongjoon Hyun2016-03-151-1/+1
|
* Merge commit 'bf599bc' into merge/2.11.x-to-2.12.x-20160203Jason Zaugg2016-02-031-0/+6
|\ | | | | | | | | | | | | | | | | Conflicts: src/compiler/scala/tools/nsc/backend/opt/ConstantOptimization.scala src/compiler/scala/tools/nsc/transform/Constructors.scala src/compiler/scala/tools/nsc/typechecker/Contexts.scala src/scaladoc/scala/tools/nsc/doc/html/page/Template.scala src/scaladoc/scala/tools/nsc/doc/html/resource/lib/jquery.layout.js
| * disable flaky presentation compiler test on WindowsSeth Tisue2016-01-151-0/+6
| | | | | | | | see https://github.com/scala/scala-dev/issues/72 for details
* | Merge commit '03aaf05' into merge-2.11-to-2.12-sep-22Lukas Rytz2015-09-221-1/+10
|\|
| * Merge remote-tracking branch 'origin/2.11.x' into topic/completely-2.11Jason Zaugg2015-09-174-0/+0
| |\
| * | Fix completion for synthetic case modules and methodsJason Zaugg2015-09-101-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I'm pretty sure the `isSynthetic` call added in 854de25ee6 should instead be `isArtifact`, so that's what I've implemented here. `isSynthetic` used to also filter out error symbols, which are created with the flags `SYNTHETIC | IS_ERROR`. I've added an addition test for `isError`, which was needed to keep the output of `presentation/scope-completion-import` unchanged. The checkfile for `presentation/callcc-interpreter` is modified to add the additional completion proposals: synthetic companion objects.
* | | Merge commit 'a170c99' into 2.12.xLukas Rytz2015-09-224-0/+0
|\ \ \ | | |/ | |/|
| * | unset inappropriate execute bitsSeth Tisue2015-09-024-0/+0
| |/ | | | | | | | | | | | | | | | | | | I imagine these date back to old Subversion days and are probably the result of inadvertent commits from Windows users with vcs client configs. having the bit set isn't really harmful most of the time, but it's just not right, and it makes the files stand out in directory listings for no reason
* / SI-9473 Cleaner references to statically owned symbolsJason Zaugg2015-09-222-2/+2
|/ | | | | | | | | | | | Ever wonder why `identity("")` typechecks to `scala.this.Predef.identity("")`? It turns out that `mkAttributedRef` was importing `q"$scalaPackageClass.this.Predef._"` for all these years, rather than `q"$scalaModule.Predef._"`. This commit makes `mkAttributedRef` special case static owners by referring the the corresponding module, instead.
* Fix 25 typos (s)Janek Bogucki2015-07-061-3/+3
|
* Remove incorrect completions: implicits can't add type membersJason Zaugg2015-02-172-4/+2
| | | | | | | The checkfile of the tests added in the last commit offered a type member from `RichInt` in the completions for the type `Int`. However, only term members can be extension methods; type members cannot.
* SI-9153 More complete and stable results for completionsJason Zaugg2015-02-176-0/+414
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Three items of background are needed to understand this bug. 1. When typechecking an application like `qual.m({stats; expr})`, the argument is typechecked using the formal parameter type of `m` as the expected type. If this fails with a type error located within in `expr`, the typer instead re-typechecks under `ContextMode.ReTyping` without an expected type, and then searches for an implicit adaptation to enable `view(qual).m(args)`. Under this mode, `Typer#typed1` clears the type of incoming trees. 2. The presentation compiler performs targetted operations like type completions by: - typechecking the enclosing tree, registering all typechecker `Context`s created in the process (`registerContext`) - finding the smallest enclosing `Context` around the target position (`doLocateContext`) - Using this context to perform implicit search, which can contribute members to the completion. (`applicableViews` within `interactive.Global#typeMembers`) 3. When verifiying whether or not a candidate implicit is applicable as a view from `F => T`, implicit search typechecks a dummy call of the form `q"candiate(${Ident("<argument>").setType(typeOf[F])})". Now, picture yourself at the nexus of these three storms. In the enclosed test case, we search for completions at: x + 1.<caret> 1. Because the code is incomplete, the application of `Int#+` doesn't typecheck, and the typer also tries to adapt `x` to a method applicable to the re-typechecked argument. 2. This process registers a context with `retypechecking` set to true. (If multiple contexts at the same position are registered, the last one wins.) 3. Implicit search uses this context to typecheck `Predef.Ensuring(<argument>.setType(Int))`, but the argument is promptly stripped of its type and retypechecking fails as there is no definition named `<argument>` in scope. As such, we missed out on extension methods, like `ensuring` in the list of completions. This commit changes the presentation compiler to turn off retyping mode in the context before starting to work with it. (Are the other modes that might cause similar bugs?) Once I made that change, I noticed that the results the enclosed test was not stable. I tracked this down to the use of a `HashMap` to carry the applicable implicit views, together with the way that the presentation compiler removes duplicates. This commit switched to a `LinkedHashMap`.
* Fix many typos in docs and commentsmpociecha2014-12-141-2/+2
| | | | | | | | | | | | | This commit corrects many typos found in scaladocs, comments and documentation. It should reduce a bit number of PRs which fix one typo. There are no changes in the 'real' code except one corrected name of a JUnit test method and some error messages in exceptions. In the case of typos in other method or field names etc., I just skipped them. Obviously this commit doesn't fix all existing typos. I just generated in IntelliJ the list of potential typos and looked through it quickly.
* Merge pull request #4081 from retronym/ticket/8943Jason Zaugg2014-11-023-0/+40
|\ | | | | SI-8943 Handle non-public case fields in pres. compiler
| * SI-8943 Handle non-public case fields in pres. compilerJason Zaugg2014-10-293-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a case class is type checked, synthetic methods are added, such as the `hashCode`/`equals`, implementations of the `Product` interface. At the same time, a case accessor method is added for each non-public constructor parameter. This the accessor for a parameter named `x` is named `x$n`, where `n` is a fresh suffix. This is all done to retain universal pattern-matchability of case classes, irrespective of access. What is the point of allowing non-public parameters if pattern matching can subvert access? I believe it is to enables private setters: ``` case class C(private var x: String) scala> val x = new C("") x: C = C() scala> val c = new C("") c: C = C() scala> val C(x) = c x: String = "" scala> c.x <console>:11: error: variable x in class C cannot be accessed in C c.x ^ scala> c.x = "" <console>:13: error: variable x in class C cannot be accessed in C val $ires2 = c.x ^ <console>:10: error: variable x in class C cannot be accessed in C c.x = "" ^ ``` Perhaps I'm missing additional motivations. If you think scheme sounds like a binary compatiblity nightmare, you're right: https://issues.scala-lang.org/browse/SI-8944 `caseFieldAccessors` uses the naming convention to find the right accessor; this in turn is used in pattern match translation. The accessors are also needed in the synthetic `unapply` method in the companion object. Here, we must tread lightly to avoid triggering a typechecking cycles before; the synthesis of that method is not allowed to force the info of the case class. Instead, it uses a back channel, `renamedCaseAccessors` to see which parameters have corresonding accessors. This is pretty flaky: if the companion object is typechecked before the case class, it uses the private param accessor directly, which it happends to have access to, and which duly gets an expanded name to allow JVM level access. If the companion appears afterwards, it uses the case accessor method. In the presentation compiler, it is possible to typecheck a source file more than once, in which case we can redefine a case class. This uses the same `Symbol` with a new type completer. Synthetics must be re-added to its type. The reported bug occurs when, during the second typecheck, an entry in `renamedCaseAccessors` directs the unapply method to use `x$1` before it has been added to the type of the case class symbol. This commit clears corresponding entries from that map when we detect that we are redefining a class symbol. Case accessors are in need of a larger scale refactoring. But I'm leaving that for SI-8944.
* | Merge pull request #4079 from retronym/ticket/8941Jason Zaugg2014-11-025-0/+152
|\ \ | | | | | | SI-8941 Idempotent presentation compilation of implicit classes
| * | SI-8941 Deterministic tests for pres. compiler idempotencyJason Zaugg2014-10-282-0/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A retrospective test case which covers typechecking idempotency which was introduced in 0b78a0196 / 148736c3df. It also tests the implicit class handling, which was fixed in the previous commit. It is difficult to test this using existing presentation compiler testing infrastructure, as one can't control at which point during the first typechecking the subesquent work item will be noticed. Instead, I've created a test with a custom subclass of `interactive.Global` that allows precise, deterministic control of when this happens. It overrides `signalDone`, which is called after each tree is typechecked, and watches for a defintion with a well known name. At that point, it triggers a targetted typecheck of the tree marked with a special comment. It is likely that this approach can be generalized to a reusable base class down the track. In particular, I expect that some of the nasty interactive ScalaDoc bugs could use this single-threaded approach to testing the presentation compiler.
| * | SI-8941 Idempotent presentation compilation of implicit classesJason Zaugg2014-10-283-0/+26
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we name an implicit class, `enterImplicitWrapper` is called, which enters the symbol for the factory method into the owning scope. The tree defining this factory method is stowed into `unit.synthetics`, from whence it will be retrieved and incorporated into the enclosing tree during typechecking (`addDerivedTrees`). The entry in `unit.synthetics` is removed at that point. However, in the presentation compiler, we can typecheck a unit more than once in a single run. For example, if, as happens in the enclosed test, a call to ask for a type at a given position interrupts type checking of the entire unit, we can get into a situation whereby the first type checking invocation has consumed the entry from `unit.synthetics`, and the second will crash when it can't find an entry. Similar problems have been solved in the past in `enterExistingSym` in the presentation compiler. This method is called when the namer encounters a tree that already has a symbol attached. See 0b78a0196 / 148736c3df. This commit takes a two pronged approach. First, `enterExistingSym` is extended to handle implicit classes. Any previous factory method in the owning scope is removed, and `enterImplicitWrapper` is called to place a new tree for the factory into `unit.synthetics` and to enter its symbol into the owning scope. Second, the assertions that could be tripped in `addDerivedTrees` and in `ImplicitClassWrapper#derivedSym` have been converted to positioned errors. The first change is sufficient to fix this bug, but the second is also enough to make the enclosed test pass, and has been retained as an extra layer of defence.
* / SI-8934 Fix whitebox extractor macros in the pres. compilerJason Zaugg2014-10-274-0/+39
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code that "aligns" patterns and extractors assumes that it can look at the type of the unapply method to figure the arity of the extractor. However, the result type of a whitebox macro does not tell the whole story, only after expanding an application of that macro do we know the result type. During regular compilation, this isn't a problem, as the macro application is expanded to a call to a synthetic unapply: { class anon$1 { def unapply(tree: Any): Option[(Tree, List[Treed])] } new anon$1 }.unapply(<unapply selector>) In the presentation compiler, however, we now use `-Ymacro-expand:discard`, which expands macros only to compute the type of the application (and to allow the macro to issue warnings/errors). The original application is retained in the typechecked tree, modified only by attributing the potentially-sharper type taken from the expanded macro. This was done to improve hyperlinking support in the IDE. This commit passes `sel.tpe` (which is the type computed by the macro expansion) to `unapplyMethodTypes`, rather than using the `finalResultType` of the unapply method. This is tested with a presentation compiler test (which closely mimics the reported bug), and with a pos test that also exercises `-Ymacro-expand:discard`. Prior to this patch, they used to fail with: too many patterns for trait api: expected 1, found 2
* Revert "Disable flaky presentation compiler test."Iulian Dragos2014-10-035-0/+169
| | | | | | | This reverts commit 8986ee4fd56c53d563165d992185c6c532f35790. Scaladoc seems to work reliably for 2.11.x. We are using it in the IDE builds and haven't noticed any flakiness, so we'd like to get reinstate this test.
* SI-8459 fix incorrect positions for incomplete selection treesghik2014-09-173-0/+31
| | | | | | The mentioned issue is a presentation compiler issue, but its root cause is a bug in the parser which incorrectly assigned positions to incomplete selection trees (i.e. selections that lack an indentifier after dot and have some whitespace instead). In detail: for such incomplete selection trees, the "point" of the position should be immediately after the dot but instead was at the start of next token after the dot. For range positions, this caused a pathological situation where the "point" was greater than the "end" of the position. This position is later used by the typechecker during resolution of dynamic calls and causes it to crash. Of course, because a syntactically incorrect code is required for the bug to manifest, it only happens in the presentation compiler.
* Merge pull request #3815 from retronym/topic/java8-support-2Adriaan Moors2014-06-103-103/+30
|\ | | | | Java 8 agnostism for our test suite
| * Java 6-8 agnosticism for a testJason Zaugg2014-06-043-103/+30
| | | | | | | | | | | | | | | | Under Java 8, the output contains newly added methods in j.u.Iterator. I've created cut down, test-local versions of the relevant types to decouple.
* | Merge remote-tracking branch 'origin/2.10.x' into ↵Jason Zaugg2014-06-042-1/+23
|\ \ | |/ |/| | | | | | | | | merge/2.10.x-to-2.11.x-20140604 Conflicts: src/compiler/scala/tools/nsc/typechecker/NamesDefaults.scala
| * SI-8596 Fix rangepos crasher with defaults, poly methodsJason Zaugg2014-05-292-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Regressed in SI-7915 / 3009a525b5 We should be deriving the position of the synthetic `Select` from `basefun1`, rather than `basefun`. In the new, enclosed test, the difference amounts to: new Container().typeParamAndDefaultArg[Any]() `------------ basefun1 --------------' `----------------- basefun ---------------' For monomorphic methods, these are one and the same, which is why `presentation/t7915` was working. I've extended that test to a polymorphic method to check that hyperlink resolution works.
* | 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-13 09:50:00 +0000