summaryrefslogtreecommitdiff
path: root/test
Commit message (Collapse)AuthorAgeFilesLines
* Actually retract clashing synthetic apply/unapplyAdriaan Moors2017-04-122-0/+18
| | | | | | | | | | | | | | | | | | | | | | | The completer set the IS_ERROR flag and I assumed the typer dropped a synthetic tree with a symbol with that flag, because the tree was not shown in -Xprint output. It turns out, as explained by lrytz, that the mechanism was fragile because it relied on the order in which completers are run. We now cover both the case that: - the completer was run (and the `IS_ERROR` flag was set) before `addSynthetics` in `typedStat` iterates over the scope (since the symbol is already unlinked, the tree is not added, irrespective of its flags). For this case, we also remove the symbol from the synthetics in its unit. - the completer is triggered during the iteration in `addSynthetics`, which needs the check for the `IS_ERROR` flag during the iteration. Thankfully, the community build caught my mistake, and lrytz provided a good analysis and review. Fix scala/bug#10261
* Merge pull request #5402 from som-snytt/issue/8040-unusedSeth Tisue2017-04-1031-36/+493
|\ | | | | SI-8040 Improve unused warnings
| * SD-363 Xlint no warn deprecated params, defaultsSom Snytt2017-04-061-0/+5
| | | | | | | | | | | | | | Deprecation is an escape hatch for unused params. Since default arg getters receive values of previous args, don't warn when they are unused.
| * SI-8040 No warn DummyImplicitSom Snytt2017-03-111-0/+2
| | | | | | | | It's just a dummy.
| * SI-8040 Xlint enables unused warningsSom Snytt2017-03-1114-13/+19
| | | | | | | | | | | | | | | | | | | | | | | | `-Ywarn-unused-import` is deprecated in favor of `-Ywarn-unused:imports`. `-Xlint` does not yet enable `-Ywarn-unused:patvars`. But the default for `-Ywarn-unused` is everything, including `patvars`. So `-Xlint:unused` is the populist option, `-Ywarn-unused` more exclusive. Tests are fixed by narrowing scope of `-Xlint` when specified.
| * SI-8040 No warn args to super, main argsSom Snytt2017-03-115-4/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | `class B(x: X) extends A(x)` uses `x` in ctor, where it is detectable as an ordinary param. `implicit class C(val s: String)` may not use `s` in extension methods, so don't warn. Don't warn required args to main method. Don't warn about synthetic isDefinedAt in anonymous functions, or about defaultCase$.
| * SI-7860 No warn private implicit value classSom Snytt2017-03-115-1/+64
| | | | | | | | | | | | | | | | | | | | | | | | Previously, warned on unused synthetic companion. Also avoid false negative via hashcode reference to the underlying value. Avoid the synthetic conversion method for the implicit class (whose RHS always uses the class); the def itself is synthetic so is normally not warned.
| * SI-8040 Warn patvars in casedefsSom Snytt2017-03-112-2/+24
| | | | | | | | | | | | | | | | Collect bindings in casedefs unless "@-bound to _". Also minor refactor to make it easier to see the cases of `id @ _`. Tupled matching is supposed to be efficient either now or soon.
| * SI-9839 Avoid crash in macro import selector posSom Snytt2017-03-113-1/+23
| | | | | | | | | | | | Ignore bad name pos. Also delete unused val. Thanks, `-Ywarn-unused`!
| * SI-8040 Warn unused parametersSom Snytt2017-03-1110-4/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One can `-Ywarn-unused:params` or more narrowly warn only for unused implicit parameters with `-Ywarn-unused:implicits`. Params includes constructor parameters. The settings for privates and locals are not yet distinguished. ``` $ skalac -Ywarn-unused:help Enable or disable specific `unused' warnings imports Warn if an import selector is not referenced. patvars Warn if a variable bound in a pattern is unused. privates Warn if a private member is unused. locals Warn if a local definition is unused. params Warn if a value parameter is unused. implicits Warn if an implicit parameter is unused. ```
| * SI-8040 Warn unused flagsSom Snytt2017-03-114-1/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce `-Ywarn-unused:x,y,z` and exploit `-Ywarn-unused:patvars`. Although the tree attachment for shielding patvars from warnings is not structural, sneaking the settings flag into the reflection internal TreeGen is awkward. Add test to ensure isolation of patvars warning from others. `-Ywarn-unused-import` is an alias for `-Ywarn-unused:imports`. `-Xlint:unused` is an alias for `-Ywarn-unused`, but not enabled yet. The help text advises to use `-Ywarn-unused`. The future can decide if `-Xlint:unused-imports` is warranted.
| * SI-9158 No warn for comprehension patvarsSom Snytt2017-03-112-4/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Midstream assignments should not cause unused warnings. Currently the encoding doesn't pass them along, but passes the value from which they were destructured. For for-comprehensions only, the patvar transform tags the binds so that they are not warned if they turn up in a valdef and are unused. Extractors are invoked multiple times if the patvar is used later, as noted on the ticket. In a yield, the valdef is emitted only if the patvar is referenced (possibly saving the extra extraction), so there is no warning there currently.
| * SI-8040 Warn unused pattern varsSom Snytt2017-03-112-1/+51
| | | | | | | | | | | | | | | | | | | | | | | | Warn for unused `case X(x) =>` but, as an escape hatch, not for `case X(x @ _) =>`. The latter form is deemed documentary. (Named args could serve a similar purpose, `case X(x = _) =>`.) An attachment is used to mark the bound var, and the symbol position is used to correlate the identifier with the variable that is introduced. This mechanism doesn't work yet when only a single var is defined.
| * SI-8040 Improve unused warningsSom Snytt2017-03-112-21/+75
| | | | | | | | | | | | | | Add symbol names, don't warn for both getters and setters or for synthetics (except default arg getters). Tweak messages for readability.
* | Merge pull request #5816 from adriaanm/userdefined-apply-212Adriaan Moors2017-04-104-0/+149
|\ \ | | | | | | Allow user-defined `[un]apply` in case companion
| * | `CompleterWrapper` delegates `typeParams`.Adriaan Moors2017-04-061-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes the problem reported with #5730 by xuwei-k in scala/scala-dev#352. The problem was already present before the introduction of `applyUnapplyMethodCompleter`, as 63f7b35 (in #5294) introduced a similar bug where the `PolyTypeCompleter`'s `typeParams` override was masked.
| * | Improvements based on reviews by Lukas & JasonAdriaan Moors2017-04-063-4/+60
| | |
| * | Allow user-defined `[un]apply` in case companionAdriaan Moors2017-04-053-0/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't emit a synthetic `apply` (or `unapply`) when it would clash with an existing one. This allows e.g., a `private apply`, along with a `case class` with a `private` constructor. We have to retract the synthetic method in a pretty roundabout way, as we need the other methods and the owner to be completed already. Unless we have to complete the synthetic `apply` while completing the user-defined one, this should not be a problem. If this does happen, this implies there's a cycle in computing the user-defined signature and the synthetic one, which is not allowed.
* | | SI-2458 Make spec example live testSom Snytt2017-04-095-33/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | Synchronize the live test with the spec update, which is trivial. Also add a neg test showing that an imported name remains ambiguous even if it resolves to the definition in scope with which it is ambiguous.
* | | Revert "Optimised implementation of List.filter/filterNot"Adriaan Moors2017-04-071-4/+4
| | | | | | | | | | | | This reverts commit eb5c51383a63c5c3420e53ef021607ff5fd20296.
* | | Merge 2.11.x into 2.12.xAdriaan Moors2017-04-073-2/+21
|\ \ \ | | | | | | | | | | | | Include 99f41a1 Merge pull request #5736
| * \ \ Merge pull request #5736 from adriaanm/t10206Adriaan Moors2017-03-213-2/+21
| |\ \ \ | | | | | | | | | | SI-10206 tighten fix for SI-6889
| | * | | Test case for SI-10206Jason Zaugg2017-03-021-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implicit search implements a restriction that the target type for an implicit view should be more specific that AnyRef or AnyVal. scala> def foo(s: String): AnyVal = s <console>:12: error: the result type of an implicit conversion must be more specific than AnyVal def foo(s: String): AnyVal = s ^ Without this, an implicit value classes over `String` would be applied, which is unlikely to be what was intended. Implicit views are implemented as an implicit search for a function type with a structural type as its result. This structural type is created with: scala> val schema = analyzer.HasMethodMatching.apply(TermName("clone"), Nil, WildcardType) schema: $r.intp.global.analyzer.global.Type = ?{def clone(): ?} The quirk arises when, as above, we're seeking a member with the same name as a member of AnyRef. AnyRef is seen to be a subtype of the result type: scala> AnyRefClass.tpe <:< schema res23: Boolean = true Which leads to the implicit in the test case being disqualified. The typer opts to report the error about the inapplicability of the inherited clone method, so we don't even know why the implicit was discarded.
| | * | | SI-10206 tighten fix for SI-6889Adriaan Moors2017-02-232-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | There are more supertypes of `AnyRef` than you might think: `?{def clone: ?}` is one example...
| * | | | Improvements based on reviews by Lukas & JasonAdriaan Moors2017-03-023-4/+60
| | | | |
| * | | | Allow user-defined `[un]apply` in case companionAdriaan Moors2017-02-273-0/+80
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't emit a synthetic `apply` (or `unapply`) when it would clash with an existing one. This allows e.g., a `private apply`, along with a `case class` with a `private` constructor. We have to retract the synthetic method in a pretty roundabout way, as we need the other methods and the owner to be completed already. Unless we have to complete the synthetic `apply` while completing the user-defined one, this should not be a problem. If this does happen, this implies there's a cycle in computing the user-defined signature and the synthetic one, which is not allowed.
* | / / t5717: test message, not just absence of compiler crashLukas Rytz2017-04-072-1/+2
| |/ / |/| |
* | | Make ImplicitInfo hashCode consistent with equals.Miles Sabin2017-04-031-0/+39
| | |
* | | Merge pull request #5724 from jvican/stub-errors-2.12.xAdriaan Moors2017-03-2723-23/+363
|\ \ \ | | | | | | | | SCP-009: Improve direct dependency experience
| * | | Improve stub error messages (SCP-009 proposal)jvican2017-03-2423-23/+363
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following commit message is a squash of several commit messages. - This is the 1st commit message: Add position to stub error messages Stub errors happen when we've started the initialization of a symbol but key information of this symbol is missing (the information cannot be found in any entry of the classpath not sources). When this error happens, we better have a good error message with a position to the place where the stub error came from. This commit goes into this direction by adding a `pos` value to `StubSymbol` and filling it in in all the use sites (especifically `UnPickler`). This commit also changes some tests that test stub errors-related issues. Concretely, `t6440` is using special Partest infrastructure and doens't pretty print the position, while `t5148` which uses the conventional infrastructure does. Hence the difference in the changes for both tests. - This is the commit message #2: Add partest infrastructure to test stub errors `StubErrorMessageTest` is the friend I introduce in this commit to help state stub errors. The strategy to test them is easy and builds upon previous concepts: we reuse `StoreReporterDirectTest` and add some methods that will compile the code and simulate a missing classpath entry by removing the class files from the class directory (the folder where Scalac compiles to). This first iteration allow us to programmatically check that stub errors are emitted under certain conditions. - This is the commit message #3: Improve contents of stub error message This commit does three things: * Keep track of completing symbol while unpickling First, it removes the previous `symbolOnCompletion` definition to be more restrictive/clear and use only positions, since only positions are used to report the error (the rest of the information comes from the context of the `UnPickler`). Second, it adds a new variable called `lazyCompletingSymbol` that is responsible for keeping a reference to the symbol that produces the stub error. This symbol will usually (always?) come from the classpath entries and therefore we don't have its position (that's why we keep track of `symbolOnCompletion` as well). This is the one that we have to explicitly use in the stub error message, the culprit so to speak. Aside from these two changes, this commit modifies the existing tests that are affected by the change in the error message, which is more precise now, and adds new tests for stub errors that happen in complex inner cases and in return type of `MethodType`. * Check that order of initialization is correct With the changes introduced previously to keep track of position of symbols coming from source files, we may ask ourselves: is this going to work always? What happens if two symbols the initialization of two symbols is intermingled and the stub error message gets the wrong position? This commit adds a test case and modifications to the test infrastructure to double check empirically that this does not happen. Usually, this interaction in symbol initialization won't happen because the `UnPickler` will lazily load all the buckets necessary for a symbol to be truly initialized, with the pertinent addresses from which this information has to be deserialized. This ensures that this operation is atomic and no other symbol initialization can happen in the meantime. Even though the previous paragraph is the feeling I got from reading the sources, this commit creates a test to double-check it. My attempt to be better safe than sorry. * Improve contents of the stub error message This commit modifies the format of the previous stub error message by being more precise in its formulation. It follows the structured format: ``` s"""|Symbol '${name.nameKind} ${owner.fullName}.$name' is missing from the classpath. |This symbol is required by '${lazyCompletingSymbol.kindString} ${lazyCompletingSymbol.fullName}'. ``` This format has the advantage that is more readable and explicit on what's happening. First, we report what is missing. Then, why it was required. Hopefully, people working on direct dependencies will find the new message friendlier. Having a good test suite to check the previously added code is important. This commit checks that stub errors happen in presence of well-known and widely used Scala features. These include: * Higher kinded types. * Type definitions. * Inheritance and subclasses. * Typeclasses and implicits. - This is the commit message #4: Use `lastTreeToTyper` to get better positions The previous strategy to get the last user-defined position for knowing what was the root cause (the trigger) of stub errors relied on instrumenting `def info`. This instrumentation, while easy to implement, is inefficient since we register the positions for symbols that are already completed. However, we cannot do it only for uncompleted symbols (!hasCompleteInfo) because the positions won't be correct anymore -- definitions using stub symbols (val b = new B) are for the compiler completed, but their use throws stub errors. This means that if we initialize symbols between a definition and its use, we'll use their positions instead of the position of `b`. To work around this we use `lastTreeToTyper`. We assume that stub errors will be thrown by Typer at soonest. The benefit of this approach is better error messages. The positions used in them are now as concrete as possible since they point to the exact tree that **uses** a symbol, instead of the one that **defines** it. Have a look at `StubErrorComplexInnerClass` for an example. This commit removes the previous infrastructure and replaces it by the new one. It also removes the fields positions from the subclasses of `StubSymbol`s. - This is the commit message #5: Keep track of completing symbols Make sure that cycles don't happen by keeping track of all the symbols that are being completed by `completeInternal`. Stub errors only need the last completing symbols, but the whole stack of symbols may be useful to reporting other error like cyclic initialization issues. I've added this per Jason's suggestion. I've implemented with a list because `remove` in an array buffer is linear. Array was not an option because I would need to resize it myself. I think that even though list is not as efficient memory-wise, it probably doesn't matter since the stack will usually be small. - This is the commit message #6: Remove `isPackage` from `newStubSymbol` Remove `isPackage` since in 2.12.x its value is not used.
* | | | Merge pull request #5783 from lrytz/t10231Adriaan Moors2017-03-222-0/+16
|\ \ \ \ | | | | | | | | | | SI-10231 Skip outer parameter when classfile parsing java param names
| * | | | SI-10231 Skip outer parameter when classfile parsing java param namesLukas Rytz2017-03-172-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Nested java classes have a synthetic outer parameter, which the classfile parser skips for the constructor symbol. When assigning parameter names from the MethodParameters classfile attribute, we also need to skip the first name in this case.
* | | | | Merge pull request #5643 from som-snytt/issue/8417Adriaan Moors2017-03-223-0/+22
|\ \ \ \ \ | | | | | | | | | | | | SI-8417 Check adapts of each param section
| * | | | | SI-8417 Check adapts of each param sectionSom Snytt2017-02-203-0/+22
| | |/ / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, adaptations like auto-tupling were checked only on the last param section of an application. This commit runs the sanity check always.
* | | | | Merge pull request #5741 from monkey-mas/bump-up-sbt-jmh-to-0.2.21Seth Tisue2017-03-211-1/+1
|\ \ \ \ \ | | | | | | | | | | | | Bump up sbt-jmh to 0.2.21
| * | | | | Bump up sbt-jmh to 0.2.21Masaru Nomura2017-02-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | With this change, we'll use JMH 1.17.4.
* | | | | | remove test/pending directory tooSeth Tisue2017-03-21357-9792/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | it will all stay right there in the Git history to be consulted anytime we want...
* | | | | | rm -r test/{flaky,disabled*,checker-tests,support,debug}Seth Tisue2017-03-20188-74446/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | keeping this stuff, somewhere, forever and ever and ever is what version control is for. who dares disturb the ancient and accursed tomb of all this code...?
* | | | | | remove orphaned checkfilesSeth Tisue2017-03-203-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | thank you tools/rm-orphan-checkfiles script
* | | | | | unset a stray execute bitSeth Tisue2017-03-201-0/+0
| |_|/ / / |/| | | |
* | | | | Merge pull request #5755 from rorygraves/2.12.x_map4Jason Zaugg2017-03-143-6/+62
|\ \ \ \ \ | |_|_|_|/ |/| | | | Improve the performance of Map4 to HashMap and Set4 to HashSet transitions
| * | | | Add benchmarks for Map4 to HashMap and Set4 to HashSet transitionsRory Graves2017-03-042-0/+58
| | | | |
| * | | | Fix compile error on existing ListBenchmarkRory Graves2017-03-041-6/+4
| | | | |
* | | | | Merge pull request #5675 from piyush-jaiswal/issue/9729som-snytt2017-03-101-0/+173
|\ \ \ \ \ | | | | | | | | | | | | Add tests for ConsoleReporter.
| * | | | | Add tests for ConsoleReporter.piyush-jaiswal2017-03-111-0/+173
| | | | | |
* | | | | | Merge pull request #5761 from lrytz/sd329Adriaan Moors2017-03-102-2/+78
|\ \ \ \ \ \ | | | | | | | | | | | | | | Don't use `equals` for comparing java.lang.Double/Float
| * | | | | | Don't use `equals` for comparing java.lang.Double/FloatLukas Rytz2017-03-092-2/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes https://github.com/scala/scala-dev/issues/329 The `equals` method for java.lang.Double/Float behaves differently than comparing the `doubleValue`s / `floatValues` for `-0.0`/`0.0`/`NaN`.
* | | | | | | Merge pull request #5719 from retronym/ticket/10187Adriaan Moors2017-03-101-0/+38
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | SI-10187 Support mutation of mutable.HashMap in getOrElseUpdate
| * | | | | | | SI-10187 Support mutation of mutable.HashMap in getOrElseUpdateJason Zaugg2017-03-031-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Scala 2.12.1 included optimizations to `HashMape.getOrElseUpdate` to avoid recomputing the index in the hash table when adding an the element. However, this index could be stale if the callback added elements to the map and triggered a resize. This commit checks that the table is unchanged before reusing the index, restoring the 2.12.0 behaviour.
* | | | | | | | SI-8969 Accept poly+implicit for assignment syntaxSom Snytt2017-03-091-2/+13
| |_|/ / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Follow-up to fb061f22d4c35df626d9651e017820a11f8fe56e which allowed the type param only. Reported: ``` scala> object Test { | def a[R](implicit s: List[R]):Int = 0 | def a_=[R](v: Int)(implicit s: List[R]) = () | } ```
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-03 03:59:14 +0000