summaryrefslogtreecommitdiff
path: root/test/files/neg
Commit message (Collapse)AuthorAgeFilesLines
* Improved message for missing argument listSom Snytt2015-06-273-2/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | Clarifies the language and rules for eta-expansion. A missing argument in a list, as opposed to a missing argument list, results in a different message. The comical expansion in parens does not attempt to show what was already applied, but succeeds in showing at a glance the shape of the method in question. ``` scala> def m(i: Int, j: Int)(x: Int) = ??? m: (i: Int, j: Int)(x: Int)Nothing scala> m <console>:12: error: missing argument list for method m Unapplied methods are only converted to functions when a function type is expected. You can make this conversion explicit by writing `m _` or `m(_,_)(_)` instead of `m`. m ^ ``` The original submission was due to sschaef and the wording due to adriaanm, with a minor tweak.
* Fix 8 typos (j-l)Janek Bogucki2015-06-231-1/+1
|
* Fix 25 typos (g-i)Janek Bogucki2015-06-221-1/+1
|
* Fix 36 typos (d-f)Janek Bogucki2015-06-213-3/+3
|
* Fix another several typosMichał Pociecha2015-06-182-2/+2
| | | | | | I just used text search to check whether there are no more typos like these corrected by janekdb, and by the way fixed also some other ones which I saw.
* Fix some typos (a-c)Janek Bogucki2015-06-182-4/+4
|
* Merge pull request #4519 from lrytz/opt/nullness-2.11Jason Zaugg2015-06-072-3/+3
|\ | | | | Nullness Analysis for GenBCode
| * Enable nullness analysis in the inlinerLukas Rytz2015-05-252-3/+3
| | | | | | | | | | | | | | When inlining an instance call, the inliner has to ensure that a NPE is still thrown if the receiver object is null. By using the nullness analysis, we can avoid emitting this code in case the receiver object is known to be not-null.
* | SI-9343 Xlint less strict on pattern sequencesSom Snytt2015-06-032-19/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | -Xlint:stars-align warns only if elementarity > 0, that is, if an extracted sequence is not matched entirely by a pattern sequence, that is, in SLS 8.1.9 on pattern sequences, n = 1 and that pattern is a pattern sequence. This is still only triggered if productarity > 0, that is, a non-pattern-sequence pattern is required for the match. This is a sensitive area because it borders on exhaustiveness checking: it would be preferable to verify just that the match is exhaustive, and to emit this warning only if it is not.
* | Fix several tests under GenBCodeLukas Rytz2015-05-261-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | - private-inline, t8601-closure-elim, inline-in-constructors - test closure inlining / elimination, which is not yet implemented in GenBCode. noted in https://github.com/scala-opt/scala/issues/14. - constant-optimization, t7006 - no constant folding in GenBCode yet. noted in https://github.com/scala-opt/scala/issues/29. - patmat_opt_ignore_underscore, patmat_opt_no_nullcheck, patmat_opt_primitive_typetest - not all optimizations in GenBCode yet. noted in https://github.com/scala-opt/scala/issues/30. - t3234 - tests a warning of trait inlining - trait inlining works in GenBCode - synchronized - ignore inliner warnings (they changed a bit) - t6102 - account for the changed outputo of -Ydebug has under GenBCode
* SI-9286 Check subclass privates for "same type after erasure"Jason Zaugg2015-05-186-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The overriding pairs cursor used to detect erased signature clashes was turning a blind eye to any pair that contained a private method. However, this could lead to a `VerifyError` or `IllegalAccessError`. Checking against javac's behaviour in both directions: ``` % cat sandbox/Test.java public abstract class Test { class C { int foo() { return 0; } } class D extends C { private <A> int foo() { return 1; } } } % javac sandbox/Test.java sandbox/Test.java:3: error: name clash: <A>foo() in Test.D and foo() in Test.C have the same erasure, yet neither overrides the other class D extends C { private <A> int foo() { return 1; } } ^ where A is a type-variable: A extends Object declared in method <A>foo() 1 error ``` ``` % cat sandbox/Test.java public abstract class Test { class C { private int foo() { return 0; } } class D extends C { <A> int foo() { return 1; } } } % javac sandbox/Test.java % ``` This commit only the exludes private symbols from the superclass from the checks by moving the test from `excludes` to `matches`.
* Move test files to the right place.Gerard Basler2015-05-033-0/+40
|
* SI-9273 Avoid unpositioned error for bare classOfJason Zaugg2015-04-152-0/+19
| | | | | | | | | | | | | | A bare identifier `classOf` in a position wth an expected type of `Class[_]` was leading to an unpositioned error. This is due to special treatment of bare `classOf` in `typedIdent` creating an ephemeral, but unpositioned, `TypeTree`. This commit positions that tree and tests that the error is issued at a sensible position. There is still an irregularity between `classOf` and `Predef.classOf`, but that seems esoteric enough to leave alone for now.
* Merge pull request #4431 from adriaanm/rebase-4379Adriaan Moors2015-04-133-0/+814
|\ | | | | Patmat: efficient reasoning about mutual exclusion
| * Patmat: efficient reasoning about mutual exclusionGerard Basler2015-04-063-0/+814
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Faster analysis of wide (but relatively flat) class hierarchies by using a more efficient encoding of mutual exclusion. The old CNF encoding for mutually exclusive symbols of a domain added a quadratic number of clauses to the formula to satisfy. E.g. if a domain has the symbols `a`, `b` and `c` then the clauses ``` !a \/ !b /\ !a \/ !c /\ !b \/ !c ``` were added. The first line prevents that `a` and `b` are both true at the same time, etc. There's a simple, more efficient encoding that can be used instead: consider a comparator circuit in hardware, that checks that out of `n` signals, at most 1 is true. Such a circuit can be built in the form of a sequential counter and thus requires only 3n-4 additional clauses [1]. A comprehensible comparison of different encodings can be found in [2]. [1]: http://www.carstensinz.de/papers/CP-2005.pdf [2]: http://www.wv.inf.tu-dresden.de/Publications/2013/report-13-04.pdf
* | Error message improvementesfandiar amirrahimi2015-04-082-4/+4
| | | | | | | | 'may be not be' -> 'may not be'
* | Merge pull request #4413 from lrytz/opt/inliningEverythingLukas Rytz2015-04-074-1/+19
|\ \ | |/ |/| Fixes and Improvements for the new inliner
| * Don't inlinie if the resulting method becomes too large for the JVMLukas Rytz2015-04-013-0/+18
| | | | | | | | | | | | | | | | | | This threshold is really the last resort and should never be reached. An inlining heuristic that blows up methods to the maximum size allowed by the JVM is broken. In the future we need to include some heuristic about code size when making an inlining decision, see github.com/scala-opt/scala/issues/2
| * Don't force the GenASM backend when passing -optimizeLukas Rytz2015-04-011-1/+1
| | | | | | | | | | | | This behavior is confusing and also problematic for writing partest tests: CI passes -optimize, which negates the -Ybackend:GenBCode entry in a flags file.
* | Merge pull request #4418 from lrytz/t8731-relaxAdriaan Moors2015-03-311-4/+1
|\ \ | |/ |/| SI-8731 don't issue a @switch warning for two-case matches
| * SI-8731 don't issue a @switch warning for two-case matchesLukas Rytz2015-03-311-4/+1
| | | | | | | | | | | | This allows annotating small pattern matches with `@switch` without getting any warnings. There's no reason to warn, the performance of the generated bytecode is good.
* | Merge pull request #4318 from soc/topic/remove-deprecation-warningsLukas Rytz2015-03-282-19/+0
|\ \ | |/ |/| Remove deprecation warnings
| * new{Term,Type}Name→{Term,Type}Name, tpename/nme→{type,term}NamesSimon Ochsenreither2015-03-262-19/+0
| |
* | Merge pull request #4358 from xeno-by/topic/names-defaultsLukas Rytz2015-03-262-13/+26
|\ \ | |/ |/| better errors for macro applications with wrong number of arguments
| * better errors for macro applications with wrong number of argumentsEugene Burmako2015-02-242-13/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tryNamesDefaults branch of application typechecking contains the checkNotMacro check, which errors out when we try to do named/default arguments for macros (that's not supported yet, see SI-5920 for discussion). Unfortunately, the check activates too early, because it turns out that we can also enter tryNamesDefaults when the user just provides insufficient number of arguments to a method by mistake, without expecting any default arguments at all. This leads to really confusing errors, which can luckily be fixed in a very simple way by moving the checkNotMacro check down the happy path of named/default typechecking.
* | Merge pull request #4310 from som-snytt/issue/9127-bLukas Rytz2015-03-255-2/+25
|\ \ | | | | | | SI-9127 Xlint doesn't think spaces are significant
| * | SI-9127 Xlint doesn't think spaces are significantSom Snytt2015-02-215-2/+25
| |/ | | | | | | | | | | | | | | | | | | | | For purposes of warning about missing interpolators, such as `"$greeting"` when the intended code was `s"$greeting"`, spaces are no longer significant. The heuristic was previously intended to allow compileresque strings, where the dollar sign is a common prefix. Currently, the Xlint warning can be selectively disabled.
* / SI-9231 Don't attempt implicit search for erroneous parameterJason Zaugg2015-03-172-0/+13
|/ | | | | | | | If the instantiated type of an implicit parameter is erroneous, we should not attempt the implicit search. This avoids the following useless error message in the enclosed test: error: ambiguous implicit values: ... match expected type M[<error>]
* Merge pull request #4195 from lrytz/t8841Adriaan Moors2015-02-136-11/+52
|\ | | | | SI-8841 report named arg / assignment ambiguity also in silent mode.
| * SI-8841 report named arg / assignment ambiguity also in silent mode.Lukas Rytz2014-12-126-11/+52
| | | | | | | | | | | | | | | | | | | | | | | | For local definitions (eg. in a block that is an argument of a method call), the type completer may have a silent context. A CyclicReference is then not thrown but transformed into a NormalTypeError. When deciding if 'x = e' is an assignment or a named arg, we need to report cyclic references, but not other type errors. In the above case, the cyclic reference was not reported. Also makes sure that warnings are printed after typing argument expressions.
* | Merge pull request #4288 from adriaanm/retronym-ticket/9041Adriaan Moors2015-02-092-0/+21
|\ \ | | | | | | SI-9041 Avoid unreported type error with overloading, implicits
| * | SI-9041 Avoid unreported type error with overloading, implicitsJason Zaugg2015-02-022-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If `qual.foo(args)` fails to typecheck, we fall back to `ImplicitView(qual).foo(args)`. However, if the original type error stemmed from an overload ambiguity, the tree `Select(qual, 'foo')` holds onto an error symbol. The fall back attempt just returns an `Apply` tree containing the erroneous qualifier, as it does not want to issue cascading type errors. This commit replaces the error symbol with a `NoSymbol`, which triggers the second try typechecking to perform overload resolution again. A more principled fix might be to more pervasively duplicate trees before mutating their types and symbols, that this is beyond the scope of this bug fix.
* | | Merge pull request #4260 from retronym/ticket/9093Lukas Rytz2015-02-032-0/+11
|\ \ \ | | | | | | | | SI-9093 Fix value discarding / multiple param list crasher
| * | | SI-9093 Fix value discarding / multiple param list crasherJason Zaugg2015-01-202-0/+11
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | The type error stemming from missing argument list was being swallowed when the expected type was `Unit` and there were undetermined type parameters in the expression. This commit modifies `adapt` to avoid using `instantiateExpectingUnit` when the tree is typed with `MethodType`.
* / / SI-7623 Trailing sequence wildcard warningSom Snytt2015-01-213-0/+60
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An -Xlint:stars-align warning for the case of patterns with at least one "fixed" component and a varargs component. Warn if the fixed patterns don't exactly align with the fixed value components, such that a sequence wildcard aligns exactly with the varargs component (either a T* parameter in a case class or a Seq[T] in an extractor result). This addresses the case of the xml.Elem extractor, which does not correspond to the Elem class constructor. One can be fooled into supplying an extra field for extraction. Vanilla extractors of type `Option[Seq[_]]` are unaffected by this flag. It's OK to ask for `case X(a, b, c)` in the expectation that three results are forthcoming. There is no semantic confusion over where the varargs begin.
* | Fix many typos in docs and commentsmpociecha2014-12-142-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 #4078 from gbasler/topic/fix-analysis-budgetAdriaan Moors2014-12-123-0/+40
|\ \ | |/ |/| Avoid the `CNF budget exceeded` exception via smarter translation into CNF.
| * Avoid the `CNF budget exceeded` exception via smarter translation into CNF.Gerard Basler2014-10-273-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The exhaustivity checks in the pattern matcher build a propositional formula that must be converted into conjunctive normal form (CNF) in order to be amenable to the following DPLL decision procedure. However, the simple conversion into CNF via negation normal form and Shannon expansion that was used has exponential worst-case complexity and thus even simple problems could become untractable. A better approach is to use a transformation into an _equisatisfiable_ CNF-formula (by generating auxiliary variables) that runs with linear complexity. The commonly known Tseitin transformation uses bi- implication. I have choosen for an enhancement: the Plaisted transformation which uses implication only, thus the resulting CNF formula has (on average) only half of the clauses of a Tseitin transformation. The Plaisted transformation uses the polarities of sub-expressions to figure out which part of the bi-implication can be omitted. However, if all sub-expressions have positive polarity (e.g., after transformation into negation normal form) then the conversion is rather simple and the pseudo-normalization via NNF increases chances only one side of the bi-implication is needed. I implemented only optimizations that had a substantial effect on formula size: - formula simplification, extraction of multi argument operands - if a formula is already in CNF then the Tseitin/Plaisted transformation is omitted - Plaisted via NNF - omitted: (sharing of sub-formulas is also not implemented) - omitted: (clause subsumption)
* | Merge pull request #4182 from som-snytt/issue/multizeroAdriaan Moors2014-12-092-0/+76
|\ \ | | | | | | SI-9015 Reject 0x and minor parser cleanup
| * | SI-9015 Reject 0x and minor parser cleanupSom Snytt2014-12-052-0/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Only print error results. Show deprecated forms. Test for rejected literals and clean up parser There was no negative test for what constitutes a legal literal. The ultimate goal is for the test to report all errors in one compilation. This commit follows up the removal of "1." syntax to simplify number parsing. It removes previous paulp code to contain the erstwhile complexity. Leading zero is not immediately put to the buffer. Instead, the empty buffer is handled on evaluation. In particular, an empty buffer due to `0x` is a syntax error. The message for obsolete octal syntax is nuanced and deferred until evaluation by the parser, which is slightly simpler to reason about. Improve comment on usage of base The slice-and-dicey usage of base deserves a better comment. The difference is that `intVal` sees an empty char buffer for input `"0"`.
* | | Merge pull request #4169 from retronym/ticket/9008Adriaan Moors2014-12-054-0/+14
|\ \ \ | | | | | | | | SI-9008 Fix regression with higher kinded existentials
| * | | SI-9008 Fix regression with higher kinded existentialsJason Zaugg2014-12-034-0/+14
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow a naked type constructor in an existential type if we are directly within a type application. Recently, 84d4671 changed nested context creation to avoid passing down the `TypeConstructorAllowed`, which led to missing kind errors in code like `type T[({type M = List})#M]`. However, when typechecking `T forSome { quantifiers }`, we create a nested context to represent the nested scope introduced for the quantifiers. But we need to propagate the `TypeConstructorAllowed` bit to the nested context to allow for higher kinded existentials. The enclosed tests show: - pos/t9008 well kinded application of an hk existential - neg/t9008 hk existential forbidden outside of type application - neg/t9008b kind error reported for hk existential Regressed in 84d4671.
* / / SI-8502 Improve resiliance to absent packagesJason Zaugg2014-11-281-1/+6
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When unpickling a class, we create stub symbols for references to classes absent from the current classpath. If these references only appear in method signatures that aren't called, we can proceed with compilation. This is in line with javac. We're getting better at this, but there are still some gaps. This bug is about the behaviour when a package is completely missing, rather than just a single class within that package. To make this work we have to add two special cases to the unpickler: - When unpickling a `ThisType`, convert a `StubTermSymbol` into a `StubTypeSymbol`. We hit this when unpickling `ThisType(missingPackage)`. - When unpickling a reference to `<owner>.name` where `<owner>` is a stub symbol, don't call info on that owner, but rather allow the enclosing code in `readSymbol` fall through to create a stub for the member. The test case was distilled from an a problem that a Spray user encountered when Akka was missing from the classpath. Two existing test cases have progressed, and the checkfiles are accordingly updated.
* | Merge pull request #4115 from retronym/ticket/8597Grzegorz Kossakowski2014-11-217-1/+90
|\ \ | | | | | | SI-8597 Improved pattern unchecked warnings
| * | SI-8597 Improved pattern unchecked warningsJason Zaugg2014-11-097-1/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The spec says that `case _: List[Int]` should be always issue an unchecked warning: > Types which are not of one of the forms described above are > also accepted as type patterns. However, such type patterns > will be translated to their erasure (§3.7). The Scala compiler > will issue an “unchecked” warning for these patterns to flag > the possible loss of type-safety. But the implementation goes a little further to omit warnings based on the static type of the scrutinee. As a trivial example: def foo(s: Seq[Int]) = s match { case _: List[Int] => } need not issue this warning. These discriminating unchecked warnings are domain of `CheckabilityChecker`. Let's deconstruct the reported bug: def nowarn[T] = (null: Any) match { case _: Some[T] => } We used to determine that if the first case matched, the scrutinee type would be `Some[Any]` (`Some` is covariant). If this statically matches `Some[T]` in a pattern context, we don't need to issue an unchecked warning. But, our blanket use of `existentialAbstraction` in `matchesPattern` loosened the pattern type to `Some[Any]`, and the scrutinee type was deemed compatible. I've added a new method, `scrutConformsToPatternType` which replaces pattern type variables by wildcards, but leaves other abstract types intact in the pattern type. We have to use this inside `CheckabilityChecker` only. If we were to make `matchesPattern` stricter in the same way, tests like `pos/t2486.scala` would fail. I have introduced a new symbol test to (try to) identify pattern type variables introduced by `typedBind`. Its not pretty, and it might be cleaner to reserve a new flag for these. I've also included a test variation exercising with nested matches. The pattern type of the inner case can't, syntactically, refer to the pattern type variable of the enclosing case. If it could, we would have to be more selective in our wildcarding in `ptMatchesPatternType` by restricting ourselves to type variables associated with the closest enclosing `CaseDef`. As some further validation of the correctness of this patch, four stray warnings have been teased out of neg/unchecked-abstract.scala I also had to changes `typeArgsInTopLevelType` to extract the type arguments of `Array[T]` if `T` is an abstract type. This avoids the "Checkability checker says 'Uncheckable', but uncheckable type cannot be found" warning and consequent overly lenient analysis. Without this change, the warning was suppressed for: def warnArray[T] = (null: Any) match { case _: Array[T] => }
* | | Merge pull request #4118 from retronym/ticket/5639Jason Zaugg2014-11-195-0/+108
|\ \ \ | | | | | | | | SI-5639 Fix spurious discarding of implicit import
| * | | SI-5639 Predicate bug fix on -Xsource:2.12Jason Zaugg2014-11-183-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | To be conservative, I've predicated this fix in `-Xsource:2.12`. This is done in separate commit to show that the previous fix passes the test suite, rather than just tests with `-Xsource:2.12`.
| * | | SI-5639 Fix spurious discarding of implicit importJason Zaugg2014-11-092-0/+76
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Scala fa0cdc7b (just before 2.9.0), a regression in implicit search, SI-2866, was discovered by Lift and fixed. The nature of the regression was that an in-scope, non-implicit symbol failed to shadow an eponymous implicit import. The fix for this introduced `isQualifyingImplicit` which discards in-scope implicits when the current `Context`'s scope contains a name-clashing entry. Incidentally, this proved to be a shallow solution, and we later improved shadowing detection in SI-4270 / 9129cfe9. That picked up cases where a locally defined symbol in an intervening scope shadowed an implicit. This commit includes the test case from the comments of SI-2866. Part of it is tested as a neg test (to test reporting of ambiguities), and the rest is tested in a run test (to test which implicits are picked.) However, in the test case of SI-5639, we see that the scope lookup performend by `isQualifyingImplicit` is fooled by a "ghost" module symbol. The apparition I'm referring to is entered when `initializeFromClassPath` / `enterClassAndModule` encounters a class file named 'Baz.class', and speculatively enters _both_ a class and module symbol. AFAIK, this is done to defer parsing the class file to determine what inside. If it happens to be a Java compiled class, the module symbol is needed to house the static members. This commit adds a condition that `Symbol#exists` which shines a torch (forces the info) in the direction of the ghost module symbol. In our test, this causes it to vanish, as we only need a class symbol for the Scala defined `class Baz`. The existing `pos` test for this actually did not exercise the bug, separate compilation is required. It was originally checked in to `pending` with this error, and then later moved to `pos` when someone noticed it was not failing.
* | | Merge pull request #4114 from retronym/ticket/8534Adriaan Moors2014-11-175-4/+23
|\ \ \ | | | | | | | | SI-8534 Avoid crash in erroneous SelectFromTypeTree
| * | | SI-8534 Avoid crash in erroneous SelectFromTypeTreeJason Zaugg2014-11-095-4/+23
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PR #2374 changed the behaviour of `typedSingletonTypeTree` in the presence of an error typed reference tree. It incorrectly returns the reference tree in case on an error. However, this is a term tree, which is an inconsistent result with the input type tree. Consequently, a `typedSelectInternal` later fails when using this as the qualifier of a `SelectFromTypeTree`. Both test cases enclosed show this symptom. This commit: - Returns `tree` rather than `refTyped` when `refTyped` is error typed or when it isn't suitable as a stable prefix. - Avoids issuing a cascading "not a stable prefix" error if the `refTyped` is error typed. - Adds an extra layer of defense in `typedSelectFromTypeTree` to bail out quickly if the qualifier is error typed. The last measure is not necessary to fix this bug.