summaryrefslogtreecommitdiff
path: root/src/compiler/scala/tools/nsc/typechecker/TypeDiagnostics.scala
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #5402 from som-snytt/issue/8040-unusedSeth Tisue2017-04-101-42/+143
|\ | | | | SI-8040 Improve unused warnings
| * SD-363 Xlint no warn deprecated params, defaultsSom Snytt2017-04-061-4/+10
| | | | | | | | | | | | | | 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-1/+2
| | | | | | | | It's just a dummy.
| * SI-8040 No warn args to super, main argsSom Snytt2017-03-111-12/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | `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-8040 Avoid Null companionSom Snytt2017-03-111-2/+2
| | | | | | | | | | | | Don't warn on the private constructor of an abstract class. Instead, take it as a signal that the class must not be instantiated.
| * SI-7860 No warn private implicit value classSom Snytt2017-03-111-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | 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-111-1/+12
| | | | | | | | | | | | | | | | 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-8040 Warn unused parametersSom Snytt2017-03-111-41/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-111-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-8040 Warn unused pattern varsSom Snytt2017-03-111-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | 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-111-7/+26
| | | | | | | | | | | | | | Add symbol names, don't warn for both getters and setters or for synthetics (except default arg getters). Tweak messages for readability.
* | Fix Greek Mythology references in compiler packageJanek Bogucki2017-04-101-2/+2
|/ | | | | | | Improve documentation some packages and correct some typos in these directories, - compiler - library
* Match error lengthsEdmund Noble2017-02-071-2/+5
|
* Improved error messages for identically named, differently prefixed typesEdmund Noble2016-12-311-22/+41
|
* Fields phase expands lazy vals like modulesAdriaan Moors2016-08-291-2/+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
* Fields phaseAdriaan Moors2016-08-111-7/+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
* SI-8892 Fix incorrect qualification in error messageJason Zaugg2015-06-231-1/+1
| | | | | | | | | | | | | | | | | | Since beadafa2, we've ended up with nutty error messages for type errors involving aliases that target types in `java.lang` and `scala` packages. I think the intent of that change was to force the error messages to qualify types like `String` when needed, but to leave them unqualified by default. However, this led to this flat out wrong message in the enclosed test. found : B required: C.this.java.lang.B (which expands to) String I've changed the heuristic slightly limit this code to aliases that are eponymous with their targets. Still feels pretty kludgy, but we can at least book a little progress.
* SI-8777 Avoid redundant disambiguation in error messagesJason Zaugg2015-06-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | When printing types in error messages, we attempt to disambiguate symbol names by qualifying them in various ways. Type paramters symbols are qualified by adding `(in someMethod)`. However, the type errors generated by higher kinded subtyping can contain clones of type parameter symbols, as creater in `isPolySubType`. The disambiguation tries fruitlessly to distinguish them but ended up adding the same suffix to both names repeatedly. ``` found : [F[_]]Foo[[X(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)]Bar[F,X(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)]] required: Foo[[X(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)]Bar[[X]Or[String,X],X(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)]] ``` This commit limits the post qualification of type parameter symbols to a single attempt to limit the damage. An alternative might be to mark a clone (we could determine its status by checking whether it is a type parameter of its owner.) But I'm not sure how to present this information in a comphrenensible way, so for now I'm limiting my ambitions to stopping the stutter.
* new{Term,Type}Name→{Term,Type}Name, tpename/nme→{type,term}NamesSimon Ochsenreither2015-03-261-1/+1
|
* Deprecations: Use of isPackage, hasSymbol, getter, setter...Simon Ochsenreither2015-03-261-2/+2
| | | | ... replaced by hasPackageFlag, hasSymbolIn, getterIn, setterIn.
* SI-8916 Further fixes with -Ywarn-unused includedSimon Ochsenreither2014-10-241-1/+1
|
* SI-8398 - unused warning reports lazy val as a methodKonstantin Fedorov2014-09-101-1/+1
| | | | 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 #3905 from gourlaysama/wip/t5691-2Lukas Rytz2014-08-261-0/+17
|\ | | | | 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-121-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Remove `def error(pos: Position, err: Throwable)`Adriaan Moors2014-07-171-1/+1
| | | | | | | | The overload was used only once.
* | Rely less on intricacies of `contextMode`-based reporting.Adriaan Moors2014-07-171-3/+3
|/ | | | | | - when warning must not be suppressed, use `reporter.warning` - don't (implicitly) rely on `reporter.warning` being silent after typer --> don't do pure expression check after typer
* Rip out reporting indirection from CompilationUnitAdriaan Moors2014-07-041-12/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Inline the forwarders from CompilationUnit, which should not affect behavior. Since all forwarders lead to global.reporter, don't first navigate to a compilation unit, only to then forward back to global.reporter. The cleanup in the previous commits revealed a ton of confusion regarding how to report an error. This was a mechanical search/replace, which has low potential for messing things up, since the list of available methods are disjoint between `reporter` and `currentRun.reporting`. The changes involving `typer.context` were done previously. Essentially, there are three ways to report: - via typer.context, so that reporting can be silenced (buffered) - via global.currentRun.reporting, which summarizes (e.g., deprecation) - via global.reporter, which is (mostly) stateless and straightforward. Ideally, these should all just go through `global.currentRun.reporting`, with the typing context changing that reporter to buffer where necessary. After the refactor, these are the ways in which we report (outside of typer): - reporter.comment - reporter.echo - reporter.error - reporter.warning - currentRun.reporting.deprecationWarning - currentRun.reporting.incompleteHandled - currentRun.reporting.incompleteInputError - currentRun.reporting.inlinerWarning - currentRun.reporting.uncheckedWarning Before: - c.cunit.error - c.enclosingUnit.deprecationWarning - context.unit.error - context.unit.warning - csymCompUnit.warning - cunit.error - cunit.warning - currentClass.cunit.warning - currentIClazz.cunit.inlinerWarning - currentRun.currentUnit.error - currentRun.reporting - currentUnit.deprecationWarning - currentUnit.error - currentUnit.warning - getContext.unit.warning - getCurrentCUnit.error - global.currentUnit.uncheckedWarning - global.currentUnit.warning - global.reporter - icls.cunit.warning - item.cunit.warning - reporter.comment - reporter.echo - reporter.error - reporter.warning - reporting.deprecationWarning - reporting.incompleteHandled - reporting.incompleteInputError - reporting.inlinerWarning - reporting.uncheckedWarning - typer.context.unit.warning - unit.deprecationWarning - unit.echo - unit.error - unit.incompleteHandled - unit.incompleteInputError - unit.uncheckedWarning - unit.warning - v1.cunit.warning All these methods ended up calling a method on `global.reporter` or on `global.currentRun.reporting` (their interfaces are disjoint). Also clean up `TypeDiagnostics`: inline nearly-single-use private methods.
* Merge pull request #3452 from xeno-by/topic/palladium0Jason Zaugg2014-02-191-4/+4
|\ | | | | SI-8063 and its seventy friends
| * Merge remote-tracking branch 'origin/master' into topic/palladium0Eugene Burmako2014-02-161-2/+1
| |\ | | | | | | | | | | | | | | | | | | | | | Conflicts: src/compiler/scala/reflect/macros/compiler/Resolvers.scala src/compiler/scala/reflect/macros/contexts/Typers.scala src/compiler/scala/tools/reflect/ToolBoxFactory.scala src/reflect/scala/reflect/api/BuildUtils.scala
| * | disambiguates uses of “local” in internal symbol APIEugene Burmako2014-02-121-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There’s been a conflation of two distinct meanings of the word “local” in the internal symbol API: the first meaning being “local to this” (as in has the LOCAL flag set), the second meaning being “local to block” (as in declared in a block, i.e. having owner being a term symbol). Especially confusing is the fact that sym.isLocal isn’t the same as sym.hasFlag(LOCAL), which has led to now fixed SI-6733. This commit fixes the semantic mess by deprecating both Symbol.isLocal and Symbol.hasLocalFlag (that we were forced to use, because Symbol.isLocal had already been taken), and replacing them with Symbol.isLocalToThis and Symbol.isLocalToBlock. Unfortunately, we can’t remove the deprecated methods right away, because they are used in SBT, so I had to take small steps.
* | | SI-7707 SI-7712 Exclude unused warnings from -XlintJason Zaugg2014-02-171-2/+0
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Experience building open source projects like Specs that use `-Xlint` suggests that this warning is too noisy to lump in with the others. We are lacking in more fine-grained control of these things, so simply turning of `-Xlint` in favour of its underlying `-Y` options ends up *losing* some other important warnings that are predicated directly on `-Xlint`. Furthermore, bug reports against M8, SI-7707 SI-7712, show that unused private/local warnings, while far less noisy, are still in need of polish. This commit moves these warnings to a pair of new -Y options, neither of which is part of `-Xlint`.. Let's ask people to opt in for 2.11, and as it stabilizes, we can consider adding it to Xlint (or the desirable evolution of that) in the next release.
* | standardizes checks for default gettersEugene Burmako2014-02-101-2/+1
|/
* Better error messages for common Function/Tuple mistakesJason Zaugg2013-12-011-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | Firstly, for `((a, b) => c): (Tuple2[A, B] => C)`, we currently just offer "missing parameter type." Is something of a rite of passage to know that you need `{ case (...)}` This commit stops short DWIM, but does offer a diagnostic to guide the user towards the supported way of destructuring a `Tuple` in the sole argument of a `Function1`. Secondly, another (less common?) way one might try to write a function to destructure a single tuple argument is: (((a, b)) => c) The parser now matches offers a specific error message for this, and points out the alternatives. In both cases, we avoid offering syntactically invalid alternatives, by detecting names that aren't valid as variable-patterns, and falling back to generic "paramN" in the error message. A handly utility function to sequence a list of options is liberated from the pattern matcher for broader use.
* Merge pull request #2930 from retronym/topic/patmat-inference-prepJason Zaugg2013-09-111-2/+2
|\ | | | | Topic/patmat inference prep
| * Limit bad advice given for erroneous pattern.Paul Phillips2013-08-291-2/+2
| | | | | | | | | | Don't suggest "_: <none>" as an alternative when the pattern type doesn't conform to the expected type.
* | Merge remote-tracking branch 'scala/2.10.x'Grzegorz Kossakowski2013-08-291-4/+7
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After the merge, the test/run/t7733 started to fail on Jenkins. I tried to reproduce it locally but I couldn't so I think it's system dependent failure. Per @retronym's suggestion I moved it to pending to not block the whole merge. Conflicts: bincompat-backward.whitelist.conf bincompat-forward.whitelist.conf src/compiler/scala/tools/nsc/symtab/classfile/ClassfileParser.scala src/compiler/scala/tools/nsc/typechecker/ContextErrors.scala src/compiler/scala/tools/nsc/typechecker/Macros.scala src/compiler/scala/tools/nsc/typechecker/Namers.scala src/compiler/scala/tools/nsc/typechecker/NamesDefaults.scala src/compiler/scala/tools/nsc/typechecker/RefChecks.scala src/compiler/scala/tools/nsc/util/MsilClassPath.scala src/compiler/scala/tools/reflect/ToolBoxFactory.scala src/reflect/scala/reflect/internal/ClassfileConstants.scala src/reflect/scala/reflect/internal/Importers.scala src/reflect/scala/reflect/internal/Trees.scala src/reflect/scala/reflect/runtime/JavaMirrors.scala test/files/run/macro-duplicate/Impls_Macros_1.scala test/files/run/t6392b.check test/files/run/t7331c.check
| * SI-7752 Don't disambiguate type parameters of overloaded altsJason Zaugg2013-08-151-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These are passed through from `InferencerContextErrors#applyErrorMsg` to `withDisambiguation` as the `locals` parameter, which is promptly ignored. This looks to be an unintended change in 39938bcc299. Without this patch, the enclosed test case enters a pathalogical disambiguation session, that not only flirts with unpleasant big-O complexities, but also flails about appending "(in method foo)" only to find that *all* occurences of the same-named type parameter come from some method named "foo". [snipping error message 40 seconds in the making] method foo), O(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo), P(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo), Q(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo), R(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo), S(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo), T, U(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo)(in method foo), V) cannot be applied to (Int) foo((1))
* | No longer crash on NoSymbol.owner.Paul Phillips2013-08-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Historically calling NoSymbol.owner has crashed the compiler. With this commit, NoSymbol owns itself. This is consistent with the way ownership chains are handled elsewhere in the compiler (e.g. NoContext.owner is NoContext, NoSymbol.enclClass is NoSymbol, and so on) and frees every call site which handles symbols from having to perform precondition tests against NoSymbol. Since calling NoSymbol.owner sometimes (not always) indicates a bug which we'd like to catch sooner than later, I have introduced a couple more methods for selected call sites. def owner: Symbol // NoSymbol.owner is self, log if -Xdev def safeOwner: Symbol // NoSymbol.owner is self, ignore def assertOwner: Symbol // NoSymbol.owner is fatal The idea is that everyone can call sym.owner without undue anxiety or paranoid null-like tests. When compiling under -Xdev calls to `owner` are logged with a stack trace, so any call sites for which that is an expected occurrence should call safeOwner instead to communicate the intention and stay out of the log. Conversely, any call site where crashing on the owner call was a desirable behavior can opt into calling assertOwner. This commit also includes all the safeOwner calls necessary to give us a silent log when compiling scala.
* | Make -Ytyper-debug output readable.Paul Phillips2013-07-171-3/+3
| |
* | Make all numeric coercions explicit.Paul Phillips2013-05-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Optimistically, this is preparation for a day when we don't let numeric types drift with the winds. Even without the optimism it's a good idea. It flushed out an undocumented change in the math package object relative to the methods being forwarded (a type is widened from what is returned in java) so I documented the intentionality of it. Managing type coercions manually is a bit tedious, no doubt, but it's not tedious enough to warrant abandoning type safety just because java did it.
* | Concision contribution.Paul Phillips2013-05-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have lots of core classes for which we need not go through the symbol to get the type: ObjectClass.tpe -> ObjectTpe AnyClass.tpe -> AnyTpe I updated everything to use the concise/direct version, and eliminated a bunch of noise where places were calling typeConstructor, erasedTypeRef, and other different-seeming methods only to always wind up with the same type they would have received from sym.tpe. There's only one Object type, before or after erasure, with or without type arguments. Calls to typeConstructor were especially damaging because (see previous commit) it had a tendency to cache a different type than the type one would find via other means. The two types would compare =:=, but possibly not == and definitely not eq. (I still don't understand what == is expected to do with types.)
* | Corralling Modes into a smaller pen.Paul Phillips2013-05-111-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Attempting to reduce the frequency of low-level operations with modes. I mean stuff like this: if ((mode & (EXPRmode | LHSmode)) == EXPRmode) THey don't make those ten line boolean guards any easier to understand. Hopefully this will lead us toward eliminating some of the modes entirely, or at least better isolating their logic rather than having it interspersed at arbitrary points throughout the typer. Modes are in their entirety a leaked implementation detail. Typing a tree requires a tree and optionally an expected type. It shouldn't require a bucket of state bits. In subsequent commits I will start eliminating them. This commit also breaks adapt down into more digestible chunks.
* | Merge 2.10.x into masterAdriaan Moors2013-05-021-0/+18
|\| | | | | | | | | | | | | | | | | | | Conflicts: bincompat-forward.whitelist.conf src/compiler/scala/tools/nsc/matching/Patterns.scala src/compiler/scala/tools/nsc/transform/patmat/Logic.scala src/compiler/scala/tools/nsc/typechecker/Infer.scala src/scaladoc/scala/tools/nsc/doc/model/ModelFactory.scala test/files/neg/t5663-badwarneq.check
| * SI-7330 better error when pattern isn't a valueAdriaan Moors2013-04-081-0/+18
| | | | | | | | | | | | | | | | Somehow an applied type managed to sneak past the type checker in pattern mode. Patterns must be values, though. `case C[_] =>` was probably meant to be `case _: C[_] =>` Advice is dispensed accordingly. (Generalizing the existing advice machinery.)
* | SI-7261 Implicit conversion of BooleanSetting to Boolean and BooleanFlagSom Snytt2013-03-271-2/+2
| | | | | | | | | | | | | | This commit shortens expressions of the form `if (settings.debug.value)` to `if (settings.debug)` for various settings. Rarely, the setting is supplied as a method argument. The conversion is not employed in simple definitions where the Boolean type would have to be specified.
* | Name boolean arguments in src/compiler.Jason Zaugg2013-03-051-3/+3
| | | | | | | | | | | | | | | | | | | | What would you prefer? adaptToMemberWithArgs(tree, qual, name, mode, false, false) Or: adaptToMemberWithArgs(tree, qual, name, mode, reportAmbiguous = false, saveErrors = false)
* | Merge pull request #2195 from vigdorchik/lint_libraryPaul Phillips2013-03-051-0/+2
|\ \ | | | | | | Changes around lint
| * | Since the problem in SI-6758 is fixed, it's ok to move checking for unused ↵Eugene Vigdorchik2013-03-051-0/+2
| | | | | | | | | | | | imports to Analyzer. This allows the check to be used in the IDE.
* | | Address some ScaladocrotJason Zaugg2013-02-251-1/+1
| | | | | | | | | | | | | | | | | | - @param tags whose name drifted from the corresponding parameter - Remove or complete a few stray stub comments (@param foo ...) - Use @tparam where appropriate.
* | | Merge 2.10.x into master.Adriaan Moors2013-02-201-6/+1
|\ \ \ | | |/ | |/| | | | | | | | | | | | | | | | Conflicts: build.number src/compiler/scala/tools/nsc/doc/base/MemberLookupBase.scala src/compiler/scala/tools/nsc/typechecker/Macros.scala test/files/presentation/doc/doc.scala
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-23 04:35:32 +0000