summaryrefslogtreecommitdiff
path: root/src/compiler/scala/tools/nsc/typechecker/TypeDiagnostics.scala
Commit message (Collapse)AuthorAgeFilesLines
* 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
| * | SI-5744 evidence params are now SYNTHETICUladzimir Abramchuk2013-02-161-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The macro def <-> macro impl correspondence check compares names of the corresponding parameters in def and impl and reports an error if they don't match. This was originally designed to avoid confusion w.r.t named arguments (which ended up being never implemented as described in SI-5920). Sometimes parameter names are generated by the compiler, which puts the user in a tough position. Luckily, there's an escape hatch built it, which omits the name correspondence check if one of the parameters is SYNTHETIC. Everything went well until we realized that evidences generated by context bounds aren't SYNTHETIC, which led to the bug at hand. Marking auto-generated evidence parameters SYNTHETIC was only the first step, as the correspondence checker uses parameter symbols, not parameter trees. Why's that a problem? Because SYNTHETIC doesn't get propagated from def trees to their underlying symbols (see ValueParameterFlags). Unfortunately one cannot just change ValueParameterFlags, because that would break printouts generated in TypeDiagnostics, which is designed to not print synthetic symbols. Thus we modify methodTypeErrorString in TypeDiagnostics to always print synthetic symbols. Therefore now we propagate all paramSym.flags when doing correspondent sweeps to keep them in sync between def trees and their underlying symbols. This fixes the problem.
* | | Merge remote-tracking branch 'scala/2.10.x' into patmat-refactor-masterAdriaan Moors2013-02-121-5/+12
|\| | | |/ |/| | | | | Conflicts: src/compiler/scala/tools/nsc/typechecker/Implicits.scala
| * SI-6514 Avoid spurious dead code warningsJason Zaugg2013-02-101-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | `deadCode.expr` stores the method symbol most recently encountered in `handleMonomorphicCall`, and uses this to avoid warnings for arguments to label jumps and `Object#synchronized` (which sneakily acts by-name without advertising the fact in its type.) But this scheme was insufficient if the argument itself contains another method call, such as `matchEnd(throw e(""))`. This commit changes the single slot to a stack, and also grants exemption to `LabelDef` trees. They were incorrectly flagged in the enclosed test case after I made the the first change.
* | Changes many calls to normalize to dealiasWiden.Paul Phillips2013-01-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Calling normalize is very aggressive and is usually the wrong thing. It is one of the leading contributors to non-determinism in compiler outcomes (often of the form "I gave a debugging or logging compiler option and it started/stopped working") and should be used only in very specific circumstances. Almost without exception, dealiasWiden is what you want; not widen, not normalize. If possible I will remove normalize from Type entirely, making it private to those areas of the compiler which actually require it.
* | Merge pull request #1874 from paulp/pr/mode-value-classPaul Phillips2013-01-111-1/+1
|\ \ | | | | | | Made "mode" into a value class.
| * | Made "mode" into a value class.Paul Phillips2013-01-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is an obvious place to apply value class goodness and collect some safety/sanity in typing modes. It does show off a challenge in introducing value classes without disruption: there's no way to deprecate the old signature of 'typed', 'adapt', etc. because they erase the same. class Bippy(val x: Int) extends AnyVal class A { @deprecated("Use a bippy") def f(x: Int): Int = 5 def f(x: Bippy): Int = x.x } ./a.scala:5: error: double definition: method f:(x: Bippy)Int and method f:(x: Int)Int at line 4 have same type after erasure: (x: Int)Int An Int => Mode implicit handles most uses, but nothing can be done to avoid breaking anything which e.g. extends Typer and overrides typed.
* | | Incorporated Variance value class in Variances.Paul Phillips2013-01-091-7/+2
|/ / | | | | | | | | No one will ever know what it took for me to refine Variances into its current condition. A LONELY QUEST.
* | Remove Name -> TermName implicit.Paul Phillips2012-12-011-1/+1
| | | | | | | | And simplify the name implicits.
* | Removed code from the typechecker.Paul Phillips2012-11-201-13/+0
| | | | | | | | | | Removing code from this neighborhood is more difficult than elsewhere, making it all the more important that it be done.
* | Revert "Commenting out unused members."Paul Phillips2012-11-191-8/+8
| | | | | | | | This reverts commit 951fc3a486.
* | Commenting out unused members.Paul Phillips2012-11-191-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I want to get this commit into the history because the tests pass here, which demonstrates that every commented out method is not only unnecessary internally but has zero test coverage. Since I know (based on the occasional source code comment, or more often based on knowing something about other source bases) that some of these can't be removed without breaking other things, I want to at least record a snapshot of the identities of all these unused and untested methods. This commit will be reverted; then there will be another commit which removes the subset of these methods which I believe to be removable. The remainder are in great need of tests which exercise the interfaces upon which other repositories depend.
* | Removed unused imports.Paul Phillips2012-11-061-2/+0
| | | | | | | | | | | | | | | | | | A dizzying number of unused imports, limited to files in src/compiler. I especially like that the unused import option (not quite ready for checkin itself) finds places where feature implicits have been imported which are no longer necessary, e.g. this commit includes half a dozen removals of "import scala.language.implicitConversions".
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-31 21:30:09 +0000