summaryrefslogtreecommitdiff
path: root/test/files
Commit message (Collapse)AuthorAgeFilesLines
* SI-8217 allow abstract type members in objectsPaolo G. Giarrusso2014-10-016-8/+25
| | | | | | | | | | | | | | | | Previously, abstract type members were allowed in objects only when inherited, but not when declared directly. This inconsistency was not intended. In dotty, abstract type members are allowed in values and represent existentials; so upon discussion, it was decided to fix things to conform to dotty and allow such type members. Adriaan also asked to keep rejecting abstract type members in methods even though they would conceivably make sense. Discussions happened on #3407, scala/scala-dist#127. This code is improved from #3442, keeps closer to the current logic, and passes tests. Existing tests that have been converted to `pos` tests show that this works, and a new test has been added to show that local aliases (ie term-owned) without a RHS are still rejected.
* SI-8398 - unused warning reports lazy val as a methodKonstantin Fedorov2014-09-102-18/+22
| | | | Compiler internals treat lazy vals as methods. Therefore, we need to have a special case for them when assembling the warning message.
* Merge pull request #3938 from gourlaysama/wip/t8764Grzegorz Kossakowski2014-09-096-0/+38
|\ | | | | SI-8764 fix return type of case class productElement under Xexperimental
| * [nomaster] SI-8764 fix return type of case class productElement under ↵Antoine Gourlay2014-09-096-0/+38
| | | | | | | | | | | | | | | | | | | | Xexperimental Under Xexperimental, productElement now returns the lub instead of the weak lub of case class parameter types (numeric widening shouldn't magically happen *inside* productElement). This was removed from 2.12.x in 6317ae2.
* | Merge pull request #3935 from lrytz/t8803Jason Zaugg2014-09-052-0/+73
|\ \ | | | | | | SI-8803 generate super accessor for super[A], if A is outer superclass
| * | SI-8803 generate super accessor for super[A], if A is outer superclassLukas Rytz2014-08-202-0/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | class C extends A with T { class I { C.super[T] C.super[A] } } A super call in a nested class of the form super[T] where T is a parent trait of the outer class doesn't need an accessor: mixin can directly re-route the call to the correct implementation class - it's statically known to be T$class. However, if a nested class accesses super[A] and A is the superclass of the outer class (not a trait), then we need a super accessor in the outer class. We need to add the mixin name to the super accessor name, otherwise it clashes with non-qualified super accessors.
* | | Merge pull request #3961 from lrytz/t8786-disable-testJason Zaugg2014-09-041-1/+3
|\ \ \ | | | | | | | | SI-8786 disable part of thest that's failing the jdk8 build
| * | | SI-8786 disable part of test that's failing the jdk8 buildLukas Rytz2014-09-041-1/+3
| | | |
* | | | Merge pull request #3932 from gourlaysama/wip/t8498Jason Zaugg2014-09-042-4/+7
|\ \ \ \ | |/ / / |/| | | SI-8498 @compileTimeOnly should be aware of bridge methods.
| * | | SI-8498 @compileTimeOnly should be aware of bridge methods.Antoine Gourlay2014-08-212-4/+7
| |/ / | | | | | | | | | | | | | | | Calling a @compileTimeOnly method from another @compileTimeOnly method happens when the former gets a bridge method. It should not throw an error. Calling the bridge or the method will anyway.
* | | Merge pull request #3955 from som-snytt/issue/8410Grzegorz Kossakowski2014-09-032-0/+16
|\ \ \ | | | | | | | | SI-8410 Don't warn fatally on disabled flag
| * | | SI-8410 Don't warn fatally on disabled flagSom Snytt2014-09-012-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since boolean settings can now be set false by user, summary warnings should not be issued when the flag is explicitly off (as opposed to unset, default). In particular, `-Xfatal-warnings` should not fail if there were no warnings otherwise. ``` $ ~/scala-2.11.2/bin/scalac -d /tmp -deprecation:false test/files/pos/t8410.scala $ ~/scala-2.11.2/bin/scalac -d /tmp -deprecation:false -Xfatal-warnings test/files/pos/t8410.scala warning: there were three deprecation warnings; re-run with -deprecation for details error: No warnings can be incurred under -Xfatal-warnings. one warning found one error found ``` After this commit: ``` $ skalac -d /tmp -Xfatal-warnings test/files/pos/t8410.scala warning: there were three deprecation warnings; re-run with -deprecation for details error: No warnings can be incurred under -Xfatal-warnings. one warning found one error found $ skalac -d /tmp -deprecation:false -Xfatal-warnings test/files/pos/t8410.scala ``` Similarly for other collecting flags: ``` $ skalac -d /tmp -optimise -Yinline-warnings -deprecation:false -Xfatal-warnings test/files/pos/t8410.scala test/files/pos/t8410.scala:14: warning: Could not inline required method dropWhile because access level required by callee not matched by caller. def k = List(0).dropWhile(_ < 1) // inlining warns doubly ^ test/files/pos/t8410.scala:14: warning: At the end of the day, could not inline @inline-marked method dropWhile def k = List(0).dropWhile(_ < 1) // inlining warns doubly ^ error: No warnings can be incurred under -Xfatal-warnings. two warnings found one error found $ skalac -d /tmp -optimise -Yinline-warnings:false -deprecation:false -Xfatal-warnings test/files/pos/t8410.scala ``` Footnote: handling of deprecated locals also changed in 2014: ``` $ ~/scala-2.11.0-M7/bin/scalac -d /tmp -deprecation -Xfatal-warnings test/files/pos/t8410.scala test/files/pos/t8410.scala:8: warning: method f in object Test is deprecated: Console println f // warns ^ error: No warnings can be incurred under -Xfatal-warnings. one warning found one error found $ ~/scala-2.11.0-M8/bin/scalac -d /tmp -deprecation -Xfatal-warnings test/files/pos/t8410.scala test/files/pos/t8410.scala:5: warning: method _f is deprecated: def g = { @deprecated("","") def _f = f ; _f } // warns in 2.11.0-M8 ^ test/files/pos/t8410.scala:6: warning: class X is deprecated: def x = { @deprecated("","") class X { def x = f } ; new X().x } // warns in 2.11.0-M8 ^ test/files/pos/t8410.scala:8: warning: method f in object Test is deprecated: Console println f // warns ^ error: No warnings can be incurred under -Xfatal-warnings. three warnings found one error found ```
* | | | Merge pull request #3952 from gourlaysama/wip/t8828-lint-innacessibleGrzegorz Kossakowski2014-09-022-0/+21
|\ \ \ \ | | | | | | | | | | SI-8828 fix regression in Xlint visibility warning for sealed classes
| * | | | SI-8828 fix regression in Xlint visibility warning for sealed classesAntoine Gourlay2014-08-282-0/+21
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5dfcf5e reverted a change to `Symbol#isEffectivelyFinal` (made in adeffda) that broke overriding checks, and moved the new enhanced version to a new method. However, the test for inaccessible type access still uses the old one, so it lost the ability to see that the owner of some method is either final or sealed and not overridden. This just makes it use the new `isEffectivelyFinalOrNotOverriden`.
* | | | Merge pull request #3948 from retronym/ticket/8823Grzegorz Kossakowski2014-09-021-0/+10
|\ \ \ \ | | | | | | | | | | SI-8823 Exclude specialized methods from extension method rewrite
| * | | | SI-8823 Exclude specialized methods from extension method rewriteJason Zaugg2014-08-271-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a value class extends a specialized class, it can sprout specialized members after the specialization info transformer has run. However, we only install extension methods for class members we know about at the extmethods phase. This commit simply disables rewiring calls to these methods in erasure to an extention method. This follows the approach taken from super accessors. Note: value class type parameters themselves currently are not allowed to be specialized.
* | | | | Merge pull request #3931 from lrytz/opt/tracked-finalLukas Rytz2014-09-018-40/+816
|\ \ \ \ \ | |_|/ / / |/| | | | GenBCode refactoring (remove Tracked) and fix InnerClass / EnclosingMethod attributes
| * | | | Fix InnerClass / EnclosingMethod attributesLukas Rytz2014-09-018-40/+816
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit seems bigger than it is. Most of it is tests, and moving some code around. The actual changes are small, but a bit subtle. The InnerClass and EnclosingMethod attributes should now be close to the JVM spec (which is summarized in BTypes.scala). New tests make sure that changes to these attributes, and changes to the way Java reflection sees Scala classfiles, don't go unnoticed. A new file, BCodeAsmCommon, holds code that's shared between the two backend (it could hold more, future work). In general, the difficulty with emitting InnerClass / EnclosingMethod is that we need to find out source-level properties. We need to make sure to do enough phase-travelling, and work around destructive changes to the ownerchain in lambdalift (we use originalOwner a lot). The change to JavaMirrors is prompted by the change to the EnclosingMethod attribute, which changes Java reflection's answer to getEnclosingMethod and getEnclosingConstructor. Classes defined in field initializers no longer have an enclosing method, just an enclosing class, which broke an assumption in JavaMirrors. There's one change in erasure. Before this change, when an object declaration implements / overrides a method, and a bridge is required, then the bridge method was actually a ModuleSymbol (it would get the lateMETHOD flag and be emitted as a method anyway). This is confusing, when iterating through the members of a class, you can find two modules with the same name, and one of them doesn't have a module class. Now, such bridge methods will be MethodSymbols. Removed Symbol.originalEnclosingMethod, that is a backend thing and doesn't need to live in the symbol API.
* | | | Merge pull request #3949 from lrytz/t8627Grzegorz Kossakowski2014-08-271-1/+1
|\ \ \ \ | | | | | | | | | | SI-8627 make Stream.filterNot non-eager
| * | | | SI-8627 make Stream.filterNot non-eagerLukas Rytz2014-08-271-1/+1
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The obvious fix, overriding `filterNot` in Stream, is not binary compatible, see https://github.com/scala/scala/pull/3925 Instead, this makes `filterImpl` in TaversableLike private[scala], which allows overriding it in Stream. The corresponding mima-failures can be whitelisted, as the changes are only to private[scala]. In 2.12.x we can remove the override of `filter` in Stream, but in 2.11.x this is not binary compatible. Eventually we'd also like to make filter / filterNot in TraversableLike final, but that's not source compatible, so it cannot be done in 2.12.x.
* | | | Merge pull request #3905 from gourlaysama/wip/t5691-2Lukas Rytz2014-08-267-7/+59
|\ \ \ \ | |_|/ / |/| | | SI-5691 lint warning when a type parameter shadows an existing type.
| * | | SI-5691 lint warning when a type parameter shadows an existing type.Antoine Gourlay2014-08-127-7/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a new lint warning for when a class/method/type-member's type parameter shadows an existing type: `-Xlint:type-parameter-shadow`. It excludes type parameters of synthetic methods (the user can't rename or remove those anyway), otherwise, for example, every case class triggers the warning. Also fixes a test that contained wrong java sources (that didn't even compile...), discovered thanks to the warning. --- This kind of errors shows up every now and then on the mailing-list, on stackoverflow, etc. so maybe a warning would be useful. I was afraid this would yield too many warnings for libraries that are heavy on type parameters, but no: running this on scalaz and shapeless HEAD (`v7.1.0-RC1-41-g1cc0a96` and `v2.0.0-M1-225-g78426a0` respectively) yields 44 warnings. None of them are false positives; they usually come from: - scalaz loving using `A` as type parameter, even several levels deep of parametrized classes/methods - or calling a type parameter that will hold a map `Map`, or similar, thus shadowing an existing type
* | | | Merge pull request #3929 from retronym/ticket/8793Lukas Rytz2014-08-261-0/+15
|\ \ \ \ | | | | | | | | | | SI-8793 Fix patmat regression with extractors, existentials
| * | | | SI-8793 Fix patmat regression with extractors, existentialsJason Zaugg2014-08-151-0/+15
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the same vein as SI-8128 / 3e9e2c65a, revert to the 2.10.x style of determining the types of the product elements of an extractor when using `TupleN`. I believe we can discard the special casing for Option/Tuple/Seq altogether with judicious application of `repackExistential` in `unapplyMethodTypes`. That ought to also fix fix SI-8149. But I'll target that work at 2.12.x.
* | | | Merge pull request #3886 from adriaanm/report-filterGrzegorz Kossakowski2014-08-262-1/+10
|\ \ \ \ | |_|_|/ |/| | | part 2 of the big error reporting refactoring
| * | | Encapsulate reporting mode as class of reportBuffer.Adriaan Moors2014-07-181-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reporting mode used to be governed by contextMode. This logic is left in place by this commit, and the consistency of the new and the old is checked. Will be removed in follow-up commit. The main difference is that we no longer throw TypeErrors in buffering mode. There was one instance of context.error in implicit search the exploited the fact that implicit search runs in buffering (silent) mode and thus calls to error(pos,msg) used to throw new TypeError(pos, msg) -- made this explicit, and removed throwing behavior from the buffering context reporter.
| * | | Simplify (ambiguous) error issuing.Adriaan Moors2014-07-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The two functional differences are: - always add the diagnostics string - check erroneousness in `issueAmbiguousTypeErrorUnlessErroneous`, before even constructing the error message. Consider this nugget: ``` - def issueAmbiguousError(pre: Type, sym1: Symbol, sym2: Symbol, err: AbsTypeError) { - issueCommon(err) { case _ if ambiguousErrors => - if (!pre.isErroneous && !sym1.isErroneous && !sym2.isErroneous) ``` I'd like to state for the record that the if-erroneous in the case of the partial function looked super-dodgy: it meant that, when `ambiguousErrors`, `issueCommon` would not get to the `else` branches that buffer or throw, and if the erroneous condition was met, nothing would be issued/buffered/thrown. This refactoring checks this condition up front.
* | | | SI-8512 Infer Any for the qSom Snytt2014-08-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Avoid the widening bug for q. This resolution also suffers from the inference of Any, which can trigger a warning and an anxiety attack. But that's still better than doing the wrong thing. Right?
* | | | SI-8512 Infer a type for f"$args"Som Snytt2014-08-121-1/+1
| |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The f-interpolator gets a type param that better be Any to avoid unfortunate widenings. Hey, it worked! Unfortunately, when `Any` is inferred, `-Xlint:infer-any` takes notice. This is probably a greater problem for the f-interpolator than for quasiquotes, which are a more specialized tool.
* | | Merge pull request #3927 from lrytz/innerClassesTestLukas Rytz2014-08-123-0/+310
|\ \ \ | | | | | | | | test for InnerClass and EnclosingMethod attributes
| * | | test for InnerClass and EnclosingMethod attributesLukas Rytz2014-08-123-0/+310
| | | | | | | | | | | | | | | | | | | | | | | | Some parts of the test assert (current) buggy behavior. This is marked in the test file with TODO. It will be fixed in later work on the backend.
* | | | Merge pull request #3902 from gourlaysama/wip/t4563Lukas Rytz2014-08-1278-80/+80
|\ \ \ \ | | | | | | | | | | SI-4563 friendlier behavior for Ctrl+D in the REPL
| * | | | SI-4563 friendlier behavior for Ctrl+D in the REPLAntoine Gourlay2014-07-2978-80/+80
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Closing the REPL with Ctrl+D does not issue a newline, so the user's prompt displays on the same line as the `scala>` prompt. This is bad. We now force a newline before closing the interpreter, and display `:quit` while we're at it so that people know how to exit the REPL (since `exit` doesn't exist anymore). The tricky part was to only add a newline when the console is interrupted, and *not* when it is closed by a command (like `:quit`), since commands are processed after their text (including newline) has been sent to the console.
* | | | Merge pull request #3889 from som-snytt/issue/6476-altLukas Rytz2014-08-122-20/+2
|\ \ \ \ | |_|/ / |/| | | SI-6476 Improve error on escapement
| * | | SI-6476 DocumentationSom Snytt2014-07-181-18/+0
| | | | | | | | | | | | | | | | And adjust the test.
| * | | SI-6476 Improve error on escapementSom Snytt2014-07-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Behavior of escape processing under string interpolation can be confusing. This commit improves the exception message so you know at least what sort of escapes are handled. This came up on SO in the form `s"\d".r`, where it may not be obvious what is throwing and how to work around it. ``` scala> s"\d".r scala.StringContext$InvalidEscapeException: invalid escape '\d' not one of [\b, \t, \n, \f, \r, \\, \", \'] at index 0 in "\d". Use \\ for literal \. scala> s"a\" scala.StringContext$InvalidEscapeException: invalid escape at terminal index 1 in "a\". Use \\ for literal \. ``` Referencing SI-6476 because that has become the magnet ticket for "escape processing under string interpolation, huh?" This doesn't address `$"` and doesn't handle the more interesting parse error `s"a\"b"`.
* | | | Merge pull request #3914 from som-snytt/issue/orphan-checkGrzegorz Kossakowski2014-08-071-1/+0
|\ \ \ \ | | | | | | | | | | Orphan check file
| * | | | Orphan check fileSom Snytt2014-08-031-1/+0
| | |/ / | |/| | | | | | | | | | | | | | | | | | Orphaned by the override check reversion that deleted the test source. 2524fdde3edc7b668fdb4bf68e990141d3ec18d6
* / | | SI-8781 Avoid double-expansion under -Ymacro-expand:discardJason Zaugg2014-08-063-0/+19
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This mode of macro expansion is used by the presentation compiler to leave the original macro applications ("expandees") in the type checked trees, annotated with the types of the expansions. However, under some circumstances involving implicits, we would re-expand the macro. If the macro wasn't stable, this could lead to a type mismatch. The originally reported problem was with the shapeless `mkSingletonOps` macro. Its expansion had the type of a freshly-named class local to the expansion. Upon the re-expansion, a new class was generated, which lead to errors like: client/Client.scala:4: error: type mismatch; found : fresh$macro$2 required: fresh$macro$1 This commit suppressed re-expansion of the expandee by use of the existing, tree attachment driven mechanism.
* | | Merge pull request #3894 from adriaanm/depmsgGrzegorz Kossakowski2014-07-255-16/+19
|\ \ \ | | | | | | | | Better error message than 'bad symbolic reference'.
| * | | Better error message than 'bad symbolic reference'.Adriaan Moors2014-07-225-16/+19
| | | | | | | | | | | | | | | | | | | | | | | | Let's not scare people, and try to give them some advice. PS: we should really come up with a better mechanism for testing errors/warnings
* | | | SI-8743 Fix crasher with poly-methods annotated with @varargsJason Zaugg2014-07-234-2/+19
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code that generated the Java varargs forwarder was basing things on the `ValDef-s` of the parameters of the source method. But, their types refer to a type parameter skolems of the enclosing method, which led to a type mismatch when typechecking the forwarder. Instead, I've reworked the code to simply use the `DefDef`-s symbol's info, which *doesn't* refer to skolems. This actually simplifies the surrounding code somewhat; rather than repeated symbols in a map we can just time travel the pre-uncurry method signatures to figure out which params are releated.
* | | Merge pull request #3888 from som-snytt/issue/8736v2.11.2Lukas Rytz2014-07-217-0/+35
|\ \ \ | | | | | | | | SI-8736 Restore -language to former glory
| * | | SI-8736 Restore -language to former glorySom Snytt2014-07-207-0/+35
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MultiChoice allows -language to work like -Xlint. The bug as described was that the setting value was set instead of updated (++=) with additional flags. The unreported bug was that `_` no longer set all settings. The corrected behavior is that "contains" means "it was enabled, or _ was set and it was not disabled explicitly." That is the behavior of `-Xlint` but with a different mechanism, since each lint option is a Setting. A semantic difference is that -Xlint enables all the lint options, but -language does not enable all the language features. `scalac -X` does not explain this additional behavior of the `-Xlint` flag. Also worth noting that `scalac -feature -language unused.scala` failed in 2.11.1 but succeeds silently now.
* / / SI-8738 Regression in range equalityRex Kerr2014-07-201-0/+16
|/ / | | | | | | | | | | Missed the case of comparing a non-empty range to an empty one. Fixed by checking nonEmpty/isEmpty on other collection. Added a test to verify the behavior.
* / SI-8525 Clarify usage of -Xlint:_,flagSom Snytt2014-07-163-20/+2
|/ | | | | | | | | | | | | | | | | | | | | Also clarify usage of -Xlint flag. Align more with javac -Xlint:all,-flag,flag where once a flag is explicitly enabled it cannot be disabled, but where the wildcard is a backstop only. (There is no all option yet here.) -Xlint and -Xlint:_ just set a flag which is consulted by any unset lint warning. Xlint warnings consult the state of Xlint when they are unset. Individual -Ywarn-ings do not. Other warnings are explicitly set to false. They can only be enabled programmatically. Some tests are corrected. Also, option order is no longer significant, see the unit test.
* Merge pull request #3792 from som-snytt/issue/8525Lukas Rytz2014-07-1616-13/+124
|\ | | | | SI-8525 -Xlint:nowarn-missing-interpolator
| * SI-8525 No anonymous lintSom Snytt2014-07-107-6/+24
| | | | | | | | | | | | | | | | | | Turn anonymous references to `settings.lint` into named settings. After that, trust to Adriaan to make them filterable. There are a few remaining top-level -Y lint warnings that are deprecated.
| * SI-8525 Add -Xlint:-warn-missing-interpolatorSom Snytt2014-07-0810-21/+50
| | | | | | | | | | | | | | | | | | | | Turn off lint warnings with negating prefix, and add a lint-only warning for the infamously nagging "Did you forget the interpolator?" That message is made more dignified. Without `-Xlint:false`, there is no mechanism to turn off anonymous linters once `-Xlint` is selected.
| * SI-8610 -Xlint is multichoice optionSom Snytt2014-07-089-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make -Xlint a "multichoice" option for purposes of option parsing. This allows turning on "lint with these warnings" instead of only "turn off these warnings but enable other lint warnings". ``` $ scalac -Xlint:warn-adapted-args linty.scala # lint plus a warning $ scalac -Xlint warn-adapted-args linty.scala # same $ scalac -Xlint linty.scala # same as now $ scalac -Xlint -- linty.scala # ok, not necessary $ scalac -Xlint _ -- linty.scala # another funky underscore ``` This would also enable Xlint options that are not standalone options, although that is not implemented in this commit. For example, `-Xlint:no-missing-interpolator` could be used to disable that warning. (There is no `-Xoption:flavor=off` syntax.) (`no-` switches would not be enabled by `_`.)
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-20 00:56:33 +0000