summaryrefslogtreecommitdiff
path: root/src/compiler/scala/tools/nsc/typechecker/ContextErrors.scala
Commit message (Collapse)AuthorAgeFilesLines
* [nomaster] macro errors now always have positionsEugene Burmako2013-08-101-1/+1
| | | | | | | | | | | | | | | Back then when I implemented macros for inclusion in trunk (Spring 2012), partest didn't support the _1, _2, ... convention for neg tests, so I had to use toolboxes to test macro-generated exceptions. Unfortunately toolboxes aren't very good with positions (mostly because their inputs are almost always constructed without corresponding sources) so I didn't notice that errors signalizing about macro-generated exceptions actually don't carry positions with them because of a typo. This patch fixes the oversight, but it doesn't need to be ported to master, because over there everything's already fixed by one of the backports from macro paradise.
* easy way of writing not implemented macrosEugene Burmako2013-05-121-0/+5
| | | | | | Even though it's easy to mark regular method bodies as stubs (using ???), there's no simple way of doing the same for macro methods. This patch fixes the inconvenience.
* [nomaster] SI-7291: No exception throwing for diverging implicit expansionHubert Plociniczak2013-05-111-3/+26
| | | | | | | | | | | | | | | | | | | | | | Since we don't throw exceptions for normal errors it was a bit odd that we don't do that for DivergingImplicit. As SI-7291 shows, the logic behind catching/throwing exception was broken for divergence. Instead of patching it, I rewrote the mechanism so that we now another SearchFailure type related to diverging expansion, similar to ambiguous implicit scenario. The logic to prevent diverging expansion from stopping the search had to be slightly adapted but works as usual. The upside is that we don't have to catch diverging implicit for example in the presentation compiler which was again showing that something was utterly broken with the exception approach. NOTE: This is a partial backport of https://github.com/scala/scala/pull/2428, with a fix for SI-7291, but without removal of error kinds (the former is absolutely necessary, while the latter is nice to have, but not a must, therefore I'm not risking porting it to 2.10.x). Also, the fix for SI-7291 is hidden behind a flag named -Xdivergence211 in order not to occasionally break the code, which relies on pre-fix behavior.
* SI-7330 better error when pattern isn't a valueAdriaan Moors2013-04-081-27/+8
| | | | | | | | 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.)
* [nomaster] Revert "refactors handling of parent types"Eugene Burmako2013-02-051-7/+6
| | | | | | | | This reverts commit 40063b0009d55ed527bf1625d99a168a8faa4124. Conflicts: src/compiler/scala/tools/nsc/ast/parser/Parsers.scala src/compiler/scala/tools/nsc/typechecker/Typers.scala
* Merge pull request #2024 from scalamacros/ticket/6812Eugene Burmako2013-02-011-3/+7
|\ | | | | SI-6812 scaladoc can opt out of expanding macros
| * SI-6812 scaladoc can opt out of expanding macrosEugene Burmako2013-01-311-3/+7
| | | | | | | | | | | | | | | | | | | | | | This is a temporary change, possible only because macros currently can't affect the global symbol table (except for the case when they will steer inference of a method's return type). Later on, e.g. with the addition of c.introduceTopLevel in master, we will have to upgrade Scaladoc to allow for separate generation of documentation, because then we'll be forced to expand macros in order to get the whole picture of the code.
* | [backport] Removed restriction on final vars, SI-2418.Paul Phillips2013-01-311-3/+0
|/ | | | | | | | | Backport of b79c7600544db9964c228b94a2f70f3ed854f89b The original fix for SI-2418 excluded final vars entirely, but the problem was not final vars per se, but the emission of ACC_FINAL in combination with ACC_VOLATILE. Since vars never get ACC_FINAL now, this is no longer an issue.
* Addressing warnings.Jason Zaugg2013-01-191-1/+1
| | | | | | | - SI-6923 uncovered a few valid warnings, these have been addressed. - A pair of "catches all throwable" warnings appeared; one of the is spurious and the subject of SI-6994.
* SI-6795 Simplify errors related to "abstract override" on type membersJames Iry2012-12-101-2/+5
| | | | | | Instead of saying "only allowed on non-type members of traits" use separate errors for "not allowed on types" and "only allowed on members of traits"
* SI-6795 Adds negative check for "abstract override" on types in traitsJames Iry2012-12-101-1/+1
| | | | | "abstract override" shouldn't was being allowed on types in traits but the result made no sense and the spec says that shouldn't be allowed.
* refactors handling of parent typesEugene Burmako2012-12-061-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | At the moment parser does too much w.r.t handling of parent types. It checks whether a parent can have value arguments or not and more importantly, it synthesizes constructors and super calls. This approach is fundamentally incompatible with upcoming type macros. Take for example the following two snippets of code: `class C extends A(2)` `class D extends A(2) with B(3)` In the first snippet, `A` might be a type macro, therefore the super call `A.super(2)` eagerly emitted by the parser might be meaningless. In the second snippet parser will report an error despite that `B` might be a type macro which expands into a trait. Unfortunately we cannot simply augment the parser with the `isTypeMacro` check. This is because to find out whether an identifier refers to a type macro, one needs to perform a typecheck, which the parser cannot do. Therefore we need a deep change in how parent types and constructors are processed by the compiler, which is implemented in this commit.
* unifies approaches to call analysis in TreeInfoEugene Burmako2012-12-061-1/+4
| | | | | | | | | | | | | | | | | Instead of a flurry of methods such as `methPart` or `typeArguments` to analyze applications, there is a single access point to related info: `treeInfo.dissectApplied(tree)` Dissection returns an instance of the `Applied` class, which can extract parts of applications and perform other application-specific operations, e.g. `applyCount`. For the sake of convenience, there's also an extractor named `Applied`, which extracts `core`, `targs` and `argss`, where core is everything except targs and argss. Extractor works for both `Tree` and `Applied` (in the former case, it's equivalent to first dissecting and pattern matching).
* Take advantage of the margin stripping interpolator.Jason Zaugg2012-11-261-14/+14
| | | | Safer and shorter.
* Brings all copyrights (in comments) up-to-date, from 2011/12 to 2013Heather Miller2012-11-021-1/+1
|
* Merge pull request #1333 from paulp/less-inlineGrzegorz Kossakowski2012-09-191-1/+0
|\ | | | | Removed many @inline annotations and final modifiers.
| * Removed many @inline annotations and final modifiers.Paul Phillips2012-09-181-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | It is my belief that these @inlines and finals landed between unhelpful and harmful. I am sure this will be disputed in some cases. It's too much and too difficult to measure except in the aggregate unless we have specific @inline sites to discuss. I don't know upon whom the burden of proof lies. I think we should err on the side given here, since there is no evidence of any consistent rationale being applied and it is easy to verify the negative impact scala compiler inlining can have on hotspot's far more sophisticated inlining.
* | Fixes SI-6354: improved error messages for Dynamic signature mismatches.amin2012-09-191-0/+7
|/ | | | | | If an error occurs afer a Dynamic rewriting, augment the error message with the rewritten tree and a hint to check the Dynamic method signature.
* Merge pull request #1311 from scalamacros/topic/magicEugene Burmako2012-09-161-1/+2
|\ | | | | deals with magic
| * extinguishes some magic from scalacEugene Burmako2012-09-161-1/+2
| | | | | | | | | | | | | | | | | | | | | | First I was quite skeptical about Paul's dislike of names that contain "magic" in them. However when I went through the code and tried to think of "magic"-less alternatives, it became apparent that resulting names are much better than the originals. Therefore I removed all the magic from reflection and macros. Feels good.
* | Merge pull request #1290 from retronym/ticket/no-implicit-to-anyrefPaul Phillips2012-09-141-1/+1
|\ \ | | | | | | A little cleanup along the Any to AnyRef trail.
| * | A little cleanup along the Any to AnyRef trail.Jason Zaugg2012-09-111-1/+1
| |/ | | | | | | | | | | | | | | Followup to 35316be and d3f879a. - Remove obsolete comments and replace them with a test. - Don't emit error addendum unless we know we're dealing with a value class.
* | SI-6310 AbsTypeTag => WeakTypeTagEugene Burmako2012-09-141-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new name for AbsTypeTag was a matter of a lengthy discussion: http://groups.google.com/group/scala-internals/browse_thread/thread/fb2007e61b505c4d I couldn't decide until having fixed SI-6323 today, which is about trying to reflect against a local class using typeOf. The problem with local classes is that they aren't pickled, so their metadata isn't preserved between Scala compilation runs. Sure, we can restore some of that metadata with Java reflection, but you get the idea. Before today typeOf of a local class created a free type, a synthetic symbol, with a bunch of synthetic children that remember the metadata, effectively creating a mini symbol table. That might be useful at time, but the problem is that this free type cannot be reflected, because the global symbol table of Scala reflection doesn't know about its mini symbol table. And then it struck me. It's not the presence of abs types (type parameters and abs type members) that differentiates arbitrary type tags from good type tags. It's the presence of types that don't map well on the runtime world - ones that can't be used to instantiate values, ones that can't be reflected. So we just need a name for these types. Phantom types are compile-time only concept, whereas our types can have partial correspondence with the runtime. "Weak types" sound more or less okish, so let's try them out.
* | Better error message for pattern arity errors.Paul Phillips2012-09-121-5/+2
|/ | | | | | Because friends don't tell friends: "wrong number of arguments for <none>"
* Better errors for Any/AnyRef issues.Paul Phillips2012-09-011-41/+67
| | | | | | | | | | | | | | | When an error occurs because some type does not conform to AnyRef (and an AnyRef-derived type would have sufficed) try to say something useful about the situation. This commit also initializes scope members before printing error messages because the + version seems more useful than the - version (taken from one of the checkfile diffs.) - def <init>: <?> - def methodIntIntInt: <?> + def <init>(): X + def methodIntIntInt(x: scala.Int,y: scala.Int): scala.Int
* pull request feedbackEugene Burmako2012-08-191-4/+7
|
* cleanup for macroExpandEugene Burmako2012-08-181-10/+101
| | | | | | | | | | | | | Error reporting is moved to ContextErrors to disentangle stuff in Macros.scala. With logics and error reporting intertwined it was an awful mess. Exceptions are used for the same reason. Instead of threading failures through the code polluting it with options/ifs, I outline the success path. It worked much better for typedMacroBody, but I'm also happy with the resulting code of macroExpand. To me a major factor towards applicability of exceptions was that they are short-lived and that there might be max one error per domain, after which we unconditionally bail.
* more cleanup for typedMacroBodyEugene Burmako2012-08-171-118/+91
|
* shaves more than 150 lines off typedMacroBodyEugene Burmako2012-08-171-9/+174
|
* update and normalize copyright noticeAdriaan Moors2012-08-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These are the regexp replacements performed: Sxcala -> Scala Copyright (\d*) LAMP/EPFL -> Copyright $1-2012 LAMP/EPFL Copyright (\d*)-(\d*)(,?) LAMP/EPFL -> Copyright $1-2012 LAMP/EPFL Copyright (\d*)-(\d*) Scala Solutions and LAMP/EPFL -> Copyright $1-2012 Scala Solutions and LAMP/EPFL \(C\) (\d*)-(\d*) LAMP/EPFL -> (C) $1-2012 LAMP/EPFL Copyright \(c\) (\d*)-(\d*)(.*?)EPFL -> Copyright (c) $1-2012$3EPFL The last one was needed for two HTML-ified copyright notices. Here's the summarized diff: Created using ``` git diff -w | grep ^- | sort | uniq | mate git diff -w | grep ^+ | sort | uniq | mate ``` ``` - <div id="footer">Scala programming documentation. Copyright (c) 2003-2011 <a href="http://www.epfl.ch" target="_top">EPFL</a>, with contributions from <a href="http://typesafe.com" target="_top">Typesafe</a>.</div> - copyright.string=Copyright 2002-2011, LAMP/EPFL - <meta name="Copyright" content="(C) 2002-2011 LAMP/EPFL"/> - * Copyright 2002-2011 LAMP/EPFL - * Copyright 2004-2011 LAMP/EPFL - * Copyright 2005 LAMP/EPFL - * Copyright 2005-2011 LAMP/EPFL - * Copyright 2006-2011 LAMP/EPFL - * Copyright 2007 LAMP/EPFL - * Copyright 2007-2011 LAMP/EPFL - * Copyright 2009-2011 Scala Solutions and LAMP/EPFL - * Copyright 2009-2011 Scxala Solutions and LAMP/EPFL - * Copyright 2010-2011 LAMP/EPFL - * Copyright 2012 LAMP/EPFL -# Copyright 2002-2011, LAMP/EPFL -* Copyright 2005-2011 LAMP/EPFL -/* NSC -- new Scala compiler -- Copyright 2007-2011 LAMP/EPFL */ -rem # Copyright 2002-2011, LAMP/EPFL ``` ``` + <div id="footer">Scala programming documentation. Copyright (c) 2003-2012 <a href="http://www.epfl.ch" target="_top">EPFL</a>, with contributions from <a href="http://typesafe.com" target="_top">Typesafe</a>.</div> + copyright.string=Copyright 2002-2012 LAMP/EPFL + <meta name="Copyright" content="(C) 2002-2012 LAMP/EPFL"/> + * Copyright 2002-2012 LAMP/EPFL + * Copyright 2004-2012 LAMP/EPFL + * Copyright 2005-2012 LAMP/EPFL + * Copyright 2006-2012 LAMP/EPFL + * Copyright 2007-2012 LAMP/EPFL + * Copyright 2009-2012 Scala Solutions and LAMP/EPFL + * Copyright 2010-2012 LAMP/EPFL + * Copyright 2011-2012 LAMP/EPFL +# Copyright 2002-2012 LAMP/EPFL +* Copyright 2005-2012 LAMP/EPFL +/* NSC -- new Scala compiler -- Copyright 2007-2012 LAMP/EPFL */ +rem # Copyright 2002-2012 LAMP/EPFL ```
* SI-6042 Improve type selection from volatile type errorJason Zaugg2012-07-081-1/+3
| | | | | | - Display the type of the typed qualifier (qual1), to avoid the message "Illegal type selection from volatile type null". - Show the upper bound, which is used to calculate the volatility.
* Improves backward compatibility of manifestsEugene Burmako2012-07-021-1/+1
| | | | | | | | | | | | | | | | 1) type ClassManifest[T] = ClassTag[T] (solves a problem with toArray[T: ClassManifest] defined on most of the collections; if these types weren't aliases, then we won't be able to change the signature of that method to toArray[T: ClassTag], because that would break source compatibility for those who override toArray in their custom collections) 2) Compiler-generated manifests no longer trigger deprecation warnings (this is implemented by using ClassManifestFactory instead of ClassManifest and ManifestFactory instead of Manifest) 3) Deprecation messages got improved to reflect the changes that were introduced in 2.10.0-M4.
* Merge pull request #735 from retronym/ticket/4842-2Adriaan Moors2012-06-211-1/+7
|\ | | | | SI-4842 Forbid access to in-construction this in self-constructor args
| * SI-4842 Forbid access to in-construction this in self-constructor argsJason Zaugg2012-06-171-1/+7
| | | | | | | | | | | | | | The check was already in place for direct calls to the super constructor. Without this additional check, ExplicitOuter crashes, as it doesn't create an $outer pointer for the constructor-arg scoped inner object, but expects one to exist when transforming the Outer.this reference.
* | Merge pull request #697 from retronym/ticket/4270-3Adriaan Moors2012-06-191-4/+4
|\ \ | |/ |/| SI-4270 Disqualify in scope implicits that are shadowed.
| * SI-4270 Rename implicits to avoid name clashes.Jason Zaugg2012-06-091-4/+4
| | | | | | | | This will fail implicit search in the next commit.
* | SI-5696 Detect excess constructor argument lists.Jason Zaugg2012-06-101-0/+5
|/ | | | An apply method fooled the usual mechanism.
* removes array tagsEugene Burmako2012-06-081-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before 2.10 we had a notion of ClassManifest that could be used to retain erasures of abstract types (type parameters, abstract type members) for being used at runtime. With the advent of ClassManifest (and its subtype Manifest) it became possible to write: def mkGenericArray[T: Manifest] = Array[T]() When compiling array instantiation, scalac would use a ClassManifest implicit parameter from scope (in this case, provided by a context bound) to remember Ts that have been passed to invoke mkGenericArray and use that information to instantiate arrays at runtime (via Java reflection). When redesigning manifests into what is now known as type tags, we decided to explore a notion of ArrayTags that would stand for abstract and pure array creators. Sure, ClassManifests were perfectly fine for this job, but they did too much - technically speaking, one doesn't necessarily need a java.lang.Class to create an array. Depending on a platform, e.g. within JavaScript runtime, one would want to use a different mechanism. As tempting as this idea was, it has also proven to be problematic. First, it created an extra abstraction inside the compiler. Along with class tags and type tags, we had a third flavor of tags - array tags. This has threaded the additional complexity though implicits and typers. Second, consequently, when redesigning tags multiple times over the course of Scala 2.10.0 development, we had to carry this extra abstraction with us, which exacerbated the overall feeling towards array tags. Finally, array tags didn't fit into the naming scheme we had for tags. Both class tags and type tags sound logical, because, they are descriptors for the things they are supposed to tag, according to their names. However array tags are the odd ones, because they don't actually tag any arrays. As funny as it might sound, the naming problem was the last straw that made us do away with the array tags. Hence this commit.
* moves positions to scala.reflect.internal.utilEugene Burmako2012-06-081-1/+1
| | | | This is the first step of factoring out scala-reflect.jar.
* Merge pull request #602 from hubertp/issue/5735Adriaan Moors2012-05-221-14/+24
|\ | | | | Closes SI-5735. Review by @adriaanm.
| * Last minor cleanupHubert Plociniczak2012-05-221-3/+3
| |
| * More consistent solution for errorenous situations when infering the ↵Hubert Plociniczak2012-05-221-15/+23
| | | | | | | | | | | | | | | | alternative. From now on we specify explicity which attempt is tried and setError on the tree depending on that. Relying on the context was a nice idea to avoid that but was fragile when we were in the silent mode (like checking named arguments).
| * Closes SI-5735, this could also potentially fix a SO problem that @adriaanm ↵Hubert Plociniczak2012-05-211-2/+4
| | | | | | | | was experiencing in IDE but could not reproduce it.
* | SI-5760: Improve error message for package$Klass conflict with KlassSom Snytt2012-05-201-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | Added a clarification to DoubleDefError for when the previous symbol was in the package object but current symbol is not. This was actually supposed to be an opportunity to hack partest to run the two-step failing compilation, but somebody beat me to it and my rebase failed. The next hacking opportunity might be to add .pt script files! The possibilities are endless.
* | Merge pull request #578 from lrytz/wip/t5044-squashedAdriaan Moors2012-05-191-0/+6
|\ \ | |/ |/| fix SI-5044: better error message on cyclic error and named/default args
| * better feedback for SI-5044Lukas Rytz2012-05-181-0/+6
| |
* | Fix SI-4928Lukas Rytz2012-05-161-2/+6
|/ | | | better error message when a parameter is first defined positionally, then with a named argument.
* Removing extraneous files.Paul Phillips2012-05-151-31/+1
| | | | Culling accumulated unnecessary code.
* minor tag-related fixesEugene Burmako2012-05-071-4/+4
|
* Updated Symbol to record classfile origin.Paul Phillips2012-05-041-10/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change should be transparent to anything using sourceFile, unless it was drinking from the inheritance well too deeply. Rather than squander the already allocated field for every ClassSymbol not being compiled from source, I'm now populating it with the file representing the class. This will make a broad range of things easier, like debugging, issuing useful error messages, symbol invalidation, signature verification, you name it. def sourceFile - still returns only source code files def binaryFile - returns only class files def associatedFile - returns whatever is there, if anything Performance: I may be mistaken, but I believe this is a zero-impact change. No new fields are allocated; fields which were null now hold a useful reference. The reference is to a file instance which was already being allocated and already long-lived. Compare error messages: // Version 1 % scalac a.scala error: type _$1 is defined twice // Version 2 % scalac a.scala error: type _$1 is defined twice conflicting symbols both originated in file './foo/package.class' Note: this may be due to a bug in the compiler involving wildcards in package objects one error found Bonus for people who read commit logs. Try this in the repl after starting power mode. ListClass.info.members groupBy (_.associatedFile) foreach { case (k, vs) => println("%s\n %s\n".format(k, vs map (_.defString) mkString "\n ")) }
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-28 16:31:01 +0000