summaryrefslogtreecommitdiff
path: root/src/compiler
Commit message (Collapse)AuthorAgeFilesLines
* Actually retract clashing synthetic apply/unapply [backport]Adriaan Moors2017-04-122-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also make this whole retraction of apply/unapply in case of a clashing user-defined member conditional on `-Xsource:2.12`. It turns out, as explained by lrytz, that the retraction mechanism was fragile because it relied on the order in which completers are run. We now cover both the case that: - the completer was run, the `IS_ERROR` flag was set, and the symbol was unlinked from its scope before `addSynthetics` in `typedStat` iterates over the scope (since the symbol is already unlinked, the tree is not added, irrespective of its flags). For this case, we also remove the symbol from the synthetics in its unit (for cleanliness). - the completer is triggered during the iteration in `addSynthetics`, which needs the check for the `IS_ERROR` flag during the iteration. Before, the completer just unlinked the symbol and set the IS_ERROR flag, and I assumed the typer dropped a synthetic tree with a symbol with that flag, because the tree was not shown in -Xprint output. In reality, the completer just always happened to run before the addSynthetics loop and unlinked the symbol from its scope in the test cases I came up with (including the 2.11 community build). Thankfully, the 2.12 community build caught my mistake, and lrytz provided a good analysis and review. Fix scala/bug#10261
* `CompleterWrapper` delegates `typeParams`.Adriaan Moors2017-04-041-0/+3
| | | | Fixes the problem reported with #5730 by xuwei-k in scala/scala-dev#352.
* Disable stub warning by default.Oscar Boykin2017-03-251-1/+1
| | | | | | | | | | | | | | | | When we create a class symbols from a classpath elements, references to other classes that are absent from the classpath are represented as references to "stub symbols". This is not a fatal error; for instance if these references are from the signature of a method that isn't called from the program being compiled, we don't need to know anything about them. A subsequent attempt to look at the type of a stub symbols will trigger a compile error. Currently, the creation of a stub symbol incurs a warning. This commit removes that warning on the basis that it isn't something users need to worry about. javac doesn't emit a comparable warning. The warning is still issued under any of `-verbose` / `-Xdev` / `-Ydebug`.
* Improve stub error messages (SCP-009 proposal)jvican2017-03-242-3/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following commit message is a squash of several commit messages. - This is the 1st commit message: Add position to stub error messages Stub errors happen when we've started the initialization of a symbol but key information of this symbol is missing (the information cannot be found in any entry of the classpath not sources). When this error happens, we better have a good error message with a position to the place where the stub error came from. This commit goes into this direction by adding a `pos` value to `StubSymbol` and filling it in in all the use sites (especifically `UnPickler`). This commit also changes some tests that test stub errors-related issues. Concretely, `t6440` is using special Partest infrastructure and doens't pretty print the position, while `t5148` which uses the conventional infrastructure does. Hence the difference in the changes for both tests. - This is the commit message #2: Add partest infrastructure to test stub errors `StubErrorMessageTest` is the friend I introduce in this commit to help state stub errors. The strategy to test them is easy and builds upon previous concepts: we reuse `StoreReporterDirectTest` and add some methods that will compile the code and simulate a missing classpath entry by removing the class files from the class directory (the folder where Scalac compiles to). This first iteration allow us to programmatically check that stub errors are emitted under certain conditions. - This is the commit message #3: Improve contents of stub error message This commit does three things: * Keep track of completing symbol while unpickling First, it removes the previous `symbolOnCompletion` definition to be more restrictive/clear and use only positions, since only positions are used to report the error (the rest of the information comes from the context of the `UnPickler`). Second, it adds a new variable called `lazyCompletingSymbol` that is responsible for keeping a reference to the symbol that produces the stub error. This symbol will usually (always?) come from the classpath entries and therefore we don't have its position (that's why we keep track of `symbolOnCompletion` as well). This is the one that we have to explicitly use in the stub error message, the culprit so to speak. Aside from these two changes, this commit modifies the existing tests that are affected by the change in the error message, which is more precise now, and adds new tests for stub errors that happen in complex inner cases and in return type of `MethodType`. * Check that order of initialization is correct With the changes introduced previously to keep track of position of symbols coming from source files, we may ask ourselves: is this going to work always? What happens if two symbols the initialization of two symbols is intermingled and the stub error message gets the wrong position? This commit adds a test case and modifications to the test infrastructure to double check empirically that this does not happen. Usually, this interaction in symbol initialization won't happen because the `UnPickler` will lazily load all the buckets necessary for a symbol to be truly initialized, with the pertinent addresses from which this information has to be deserialized. This ensures that this operation is atomic and no other symbol initialization can happen in the meantime. Even though the previous paragraph is the feeling I got from reading the sources, this commit creates a test to double-check it. My attempt to be better safe than sorry. * Improve contents of the stub error message This commit modifies the format of the previous stub error message by being more precise in its formulation. It follows the structured format: ``` s"""|Symbol '${name.nameKind} ${owner.fullName}.$name' is missing from the classpath. |This symbol is required by '${lazyCompletingSymbol.kindString} ${lazyCompletingSymbol.fullName}'. ``` This format has the advantage that is more readable and explicit on what's happening. First, we report what is missing. Then, why it was required. Hopefully, people working on direct dependencies will find the new message friendlier. Having a good test suite to check the previously added code is important. This commit checks that stub errors happen in presence of well-known and widely used Scala features. These include: * Higher kinded types. * Type definitions. * Inheritance and subclasses. * Typeclasses and implicits. - This is the commit message #4: Use `lastTreeToTyper` to get better positions The previous strategy to get the last user-defined position for knowing what was the root cause (the trigger) of stub errors relied on instrumenting `def info`. This instrumentation, while easy to implement, is inefficient since we register the positions for symbols that are already completed. However, we cannot do it only for uncompleted symbols (!hasCompleteInfo) because the positions won't be correct anymore -- definitions using stub symbols (val b = new B) are for the compiler completed, but their use throws stub errors. This means that if we initialize symbols between a definition and its use, we'll use their positions instead of the position of `b`. To work around this we use `lastTreeToTyper`. We assume that stub errors will be thrown by Typer at soonest. The benefit of this approach is better error messages. The positions used in them are now as concrete as possible since they point to the exact tree that **uses** a symbol, instead of the one that **defines** it. Have a look at `StubErrorComplexInnerClass` for an example. This commit removes the previous infrastructure and replaces it by the new one. It also removes the fields positions from the subclasses of `StubSymbol`s. - This is the commit message #5: Keep track of completing symbols Make sure that cycles don't happen by keeping track of all the symbols that are being completed by `completeInternal`. Stub errors only need the last completing symbols, but the whole stack of symbols may be useful to reporting other error like cyclic initialization issues. I've added this per Jason's suggestion. I've implemented with a list because `remove` in an array buffer is linear. Array was not an option because I would need to resize it myself. I think that even though list is not as efficient memory-wise, it probably doesn't matter since the stack will usually be small. - This is the commit message #6: Remove `isPackage` from `newStubSymbol` Remove `isPackage` since in 2.12.x its value is not used.
* Merge pull request #5736 from adriaanm/t10206Adriaan Moors2017-03-211-19/+22
|\ | | | | SI-10206 tighten fix for SI-6889
| * SI-10206 tighten fix for SI-6889Adriaan Moors2017-02-231-19/+22
| | | | | | | | | | There are more supertypes of `AnyRef` than you might think: `?{def clone: ?}` is one example...
* | [backport] new repo, version numbers for integration buildsLukas Rytz2017-03-091-1/+1
| | | | | | | | | | | | | | Integration builds now have version number like `2.12.2-bin-sha7` or `2.13.0-pre-sha7` and are published to scala-integration (no longer scala-release-temp). scala-release-temp is still used in the bootstrap script for publishing locker.
* | Improvements based on reviews by Lukas & JasonAdriaan Moors2017-03-021-17/+31
| |
* | Allow user-defined `[un]apply` in case companionAdriaan Moors2017-02-271-12/+69
|/ | | | | | | | | | | | | Don't emit a synthetic `apply` (or `unapply`) when it would clash with an existing one. This allows e.g., a `private apply`, along with a `case class` with a `private` constructor. We have to retract the synthetic method in a pretty roundabout way, as we need the other methods and the owner to be completed already. Unless we have to complete the synthetic `apply` while completing the user-defined one, this should not be a problem. If this does happen, this implies there's a cycle in computing the user-defined signature and the synthetic one, which is not allowed.
* SI-1459 two bridges for impl of java generic vararg methodAdriaan Moors2017-01-242-18/+22
| | | | | | | | | | | | | | | | A Scala method that implements a generic, Java-defined varargs method, needs two bridges: - to convert the collections for the repeated parameters (VBRIDGE) - to bridge the generics gap (BRIDGE) Refchecks emits the varargs "bridges", and erasure takes care of the other gap. Because a VBRIDGE was also an ARTIFACT, it was wrongly considered inert with respect to erasure, because `OverridingPairs` by default excluded artifacts. Removed the artifact flag from those VBRIDGES, so that they qualify for a real bridge. It would also work to include VBRIDGE methods that are artifacts in BridgesCursor.
* Merge pull request #5630 from adriaanm/rebase-5557Adriaan Moors2017-01-102-62/+62
|\ | | | | [backport] SI-10071 SI-8786 varargs methods
| * SI-10071 Separate compilation for varargs methodsIulian Dragos2017-01-092-64/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make sure that methods annotated with varargs are properly mixed-in. This commit splits the transformation into an info transformer (that works on all symbols, whether they come from source or binary) and a tree transformer. The gist of this is that the symbol-creation part of the code was moved to the UnCurry info transformer, while tree operations remained in the tree transformer. The newly created symbol is attached to the original method so that the tree transformer can still retrieve the symbol. A few fall outs: - I removed a local map that was identical to TypeParamsVarargsAttachment - moved the said attachment to StdAttachments so it’s visible between reflect.internal and nsc.transform - a couple more comments in UnCurry to honour the boy-scout rule
| * SI-8786 fix generic signature for @varargs forwarder methodsLukas Rytz2017-01-092-52/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When generating a varargs forwarder for def foo[T](a: T*) the parameter type of the forwarder needs to be Array[Object]. If we generate Array[T] in UnCurry, that would be erased to plain Object, and the method would not be a valid varargs. Unfortunately, setting the parameter type to Array[Object] lead to an invalid generic signature - the generic signature should reflect the real signature. This change adds an attachment to the parameter symbol in the varargs forwarder method and special-cases signature generation. Also cleans up the code to produce the varargs forwarder. For example, type parameter and parameter symbols in the forwarder's method type were not clones, but the same symbols from the original method were re-used. Backported from 0d2760dce189cdcb363e54868381175af4b2646f, with a small tweak (checkVarargs) to make the test work on Java 6, as well as later versions.
* | SI-9331 Fix canEqual for case classes with HK type paramsJason Zaugg2017-01-092-5/+5
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | Time for the courage of our convictions: follow the advice of my TODO comment from SI-8244 / f62e280825 and fix `classExistentialType` once and for all. This is the change in the generated `canEquals` method in the test case; we no longer get a kind conformance error. ``` --- sandbox/old.log 2015-05-27 14:31:27.000000000 +1000 +++ sandbox/new.log 2015-05-27 14:31:29.000000000 +1000 @@ -15,7 +15,7 @@ case _ => throw new IndexOutOfBoundsException(x$1.toString()) }; override <synthetic> def productIterator: Iterator[Any] = runtime.this.ScalaRunTime.typedProductIterator[Any](Stuff.this); - <synthetic> def canEqual(x$1: Any): Boolean = x$1.$isInstanceOf[Stuff[Proxy[PP]]](); + <synthetic> def canEqual(x$1: Any): Boolean = x$1.$isInstanceOf[Stuff[_ <: [PP]Proxy[PP]]](); override <synthetic> def hashCode(): Int = ScalaRunTime.this._hashCode(Stuff.this); override <synthetic> def toString(): String = ScalaRunTime.this._toString(Stuff.this); override <synthetic> def equals(x$1: Any): Boolean = x$1 match { @@ -38,9 +38,3 @@ } } ``` I also heeded my own advice to pass in a prefix to this method.
* SI-9630 Fix spurious warning related to same-named case accessors [backport]Jason Zaugg2016-12-212-7/+11
| | | | | | | | | | | | | | | Hash consing of trees within pattern match analysis was broken, and considered `x1.foo#1` to be the same tree as `x1.foo#2`, even though the two `foo`-s referred to different symbols. The hash consing was based on `Tree#correspondsStructure`, but the predicate in that function cannot veto correspondance, it can only supplement the default structural comparison. I've instead created a custom tree comparison method for use in the pattern matcher that handles the tree shapes that we use. (cherry picked from commit 79a52e6807d2797dee12bab1730765441a0e222d)
* More robust outer test for patmatAdriaan Moors2016-12-211-10/+8
| | | | While investigating https://github.com/scala/scala-dev/issues/251
* Small cleanups to pattern matcherAdriaan Moors2016-12-212-15/+19
| | | | While investigating https://github.com/scala/scala-dev/issues/251
* Merge pull request #5487 from lrytz/java-constantsAdriaan Moors2016-12-152-2/+61
|\ | | | | SI-3236 constant types for literal final static java fields
| * Support implicit converstions from java literalsLukas Rytz2016-11-021-38/+41
| | | | | | | | | | | | | | | | For example, public static final byte b = 127 is allowed, but 128 is not. Also factor out a method that parses a literal. It could be used to parse annotations (and their literal arguments) in Java sources.
| * SI-3236 constant types for literal final static java fieldsJohannes Rudolph2016-10-282-2/+58
| | | | | | | | | | | | | | | | | | Since we don't parse Java expressions, fields of Java classes coming from source files never have constant types. This prevents using static java fields in annotation arguments in mixed compilation This PR assigns constant types to final static java fields if the initializer is a simple literal.
* | SI-9834 Show expansion of update on errorSom Snytt2016-11-251-3/+4
| |
* | SI-9834 Improve error on failed op=Som Snytt2016-11-251-16/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | If rewriting `x += y` fails to typecheck, emit error messages for both the original tree and the assignment. If rewrite is not attempted because `x` is a val, then say so. The error message at `tree.pos` is updated with the additional advice. SI-8763 Crash in update conversion When there are already errors, don't attempt mechanical rewrites.
* | [nomerge] SI-10037 ASR/LSR switched in ICodeReaderSom Snytt2016-11-102-5/+5
| | | | | | | | | | | | | | | | | | | | Noticed when inlining from a class file. The test doesn't work because inlining fails with bytecode unavailable due to: ``` scala.reflect.internal.MissingRequirementError: object X in compiler mirror not found. ```
* | [backport] Replace println with log calls in BrowsingLoadersIulian Dragos2016-10-251-4/+4
|/ | | | | | | This alternative symbol loader is used in the presentation compiler and may generate output even when the compiler should be silent. See SI-8717 for more context, even though this does not really fix the ticket.
* Merge pull request #5343 from milessabin/topic/si-2712-backportAdriaan Moors2016-10-181-0/+1
|\ | | | | SI-2712 Add support for higher order unification
| * SI-2712 Add support for higher order unificationMiles Sabin2016-08-151-0/+1
| |
* | Merge pull request #5453 from som-snytt/issue/9832-2.11Adriaan Moors2016-10-181-5/+13
|\ \ | | | | | | SI-9832 -Xlint:help shows default
| * | SI-9832 -Xlint:help shows defaultSom Snytt2016-10-111-5/+13
| |/ | | | | | | | | | | Conclude help method with the default list. Extra words are supplied for underscore.
* | Merge pull request #5345 from milessabin/topic/si-7046-backportAdriaan Moors2016-10-184-11/+48
|\ \ | | | | | | [nomerge] Partial fix for SI-7046
| * | Partial fix for SI-7046Miles Sabin2016-08-154-11/+48
| |/
* | Merge pull request #5341 from milessabin/topci/si-9760-backportAdriaan Moors2016-10-181-1/+0
|\ \ | | | | | | SI-9760 Fix for higher-kinded GADT refinement
| * | SI-9760 Fix for higher-kinded GADT refinementMiles Sabin2016-08-151-1/+0
| |/
* | Merge pull request #5218 from retronym/ticket/9806Jason Zaugg2016-10-181-2/+2
|\ \ | |/ |/| SI-9806 Fix incorrect codegen with optimizer, constants, try/catch
| * SI-9806 Fix incorrect codegen with optimizer, constants, try/catchJason Zaugg2016-06-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The constant optimizer phase performs abstract interpretation of the icode representation of the progam in order to eliminate dead code. For each basic block, the possible and impossible states of each local variable is computed for both a normal and an exceptional exit. A bug in this code incorrectly tracked state for exception exits. This appears to have been an oversight: the new state was computed at each instruction, but it was discarded rather than folded through the intepreter.
* | SI-9245 Fresher name in Try and testSom Snytt2016-06-071-1/+1
|/ | | | | | | | Fresh name for catcher gets a dollar. "Here, have a dollar." Test due to retronym demonstrates possible conflict. Over the lifetime of the universe, surely at least one code monkey would type in that identifier to catch a banana.
* Merge pull request #4998 from som-snytt/issue/7898-iLukas Rytz2016-06-012-1/+8
|\ | | | | SI-7898 Read user input during REPL warmup
| * SI-7898 Read user input during REPL warmupSom Snytt2016-05-202-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The compiler is created on main thread and user input is read on an aux thread (opposite to currently). Fixes completion when `-i` is supplied. Now `-i` means pasted and new option `-I` means line-by-line. The temporary reader uses postInit to swap in the underlying reader. Completion is disabled for the temporary reader, rather than blocking while it waits for a compiler. But manically hitting tab is one way of knowing exactly when completion is live.
* | Merge pull request #5169 from som-snytt/issue/4625Lukas Rytz2016-05-231-44/+64
|\ \ | |/ |/| SI-4625 Recognize App in script
| * SI-4625 Warn on first non-toplevel onlySom Snytt2016-05-171-42/+46
| | | | | | | | | | | | Fixed the warning when main module is accompanied by snippets. Minor clean-up so even I can follow what is returned.
| * SI-4625 Warn when discarding script objectSom Snytt2016-05-171-4/+11
| | | | | | | | | | | | It's pretty confusing when your script object becomes a local and then nothing happens. Such as when you're writing a test and it takes forever to figure out what's going on.
| * SI-4625 Permit arbitrary top-level in scriptSom Snytt2016-05-161-1/+3
| | | | | | | | | | | | | | In an unwrapped script, where a `main` entry point is discovered in a top-level object, retain all top-level classes. Everything winds up in the default package.
| * SI-4625 App is a thingSom Snytt2016-05-161-1/+4
| | | | | | | | Scripting knows it by name.
| * SI-4625 Recognize App in scriptSom Snytt2016-05-161-1/+5
| | | | | | | | | | | | | | | | | | Cheap name test: if the script object extends "App", take it for a main-bearing parent. Note that if `-Xscript` is not `Main`, the default, then the source is taken as a snippet and there is no attempt to locate an existing `main` method.
* | Remove default value for sourcepath in scalac (ant version). (#5166)Krzysztof Romanowski2016-05-171-2/+0
|/
* SI-9425 Fix a residual bug with multi-param-list case classesJason Zaugg2016-03-041-3/+10
| | | | | | | | During code review for the fix for SI-9546, we found a corner case in the SI-9425 that remained broken. Using `finalResultType` peels off all the constructor param lists, and solves that problem.
* SI-9546 Fix regression in rewrite of case apply to constructor callJason Zaugg2016-03-021-4/+3
| | | | | | | | | | | | | | | | | | | | | In SI-9425, I disabled the rewrite of `CaseClass.apply(x)` to `new CaseClass(x)` if the constructor was was less accessible than the apply method. This solved a problem with spurious "constructor cannot be accessed" errors during refchecks for case classes with non-public constructors. However, for polymorphic case classes, refchecks was persistent, and even after refusing to transform the `TypeApply` within: CaseClass.apply[String]("") It *would* try again to transform the enclosing `Select`, a code path only intended for monomorphic case classes. The tree has a `PolyType`, which foiled the newly added accessibility check. I've modified the call to `isSimpleCaseApply` from the transform of `Select` nodes to exclude polymorphic apply's from being considered twice.
* Refactor transform of case apply in refchecksJason Zaugg2016-03-021-28/+30
| | | | | | | | | | | | | | | | I've identified a dead call to `transformCaseApply` that seems to date back to Scala 2.6 vintages, in which case factory methods were a fictional companion method, rather than a real apply method in a companion module. This commit adds an abort in that code path to aide code review (if our test suite still passes, we know that I've removed dead code, rather than silently changing behaviour.) The following commit will remove it altogether I then inlined a slightly clunky abstraction in the two remaining calls to `transformCaseApply`. It was getting in the way of a clean fix to SI-9546, the topic of the next commit.
* Merge pull request #4928 from szeiger/wip/document-e-ncLukas Rytz2016-02-101-1/+5
|\ | | | | Document that `scala -e` starts/uses a compilation daemon
| * Document when the `scala` command starts/uses a compilation daemonStefan Zeiger2016-02-011-1/+5
| |
* | SI-9572 Check for illegal tuple sizes in the parserStefan Zeiger2016-01-283-35/+58
|/ | | | | | | | | | | | | | | This commit adds explicit checks with syntax errors for tuple literals and types of more than 22 elements. An alternative approach to fixing SI-9572 would be to revert to the old failure mode of Scala 2.10 where references to arbitrary `scala.TupleXY` would be generated in the parser, which then leads to “type/object not found” errors in the typechecker. This fix here is more intrusive but arguably provides a better user experience. Methods `stripParens` and `makeBinop` are moved from `TreeBuilder` to `Parsers` because they can now generate syntax errors. New methods `makeSafeTupleType` and `makeSafeTupleTerm` implement the error checking on top of `makeTupleType` and `makeTupleTerm`. They are overridden with no-op versions in the quasiquotes parser because it also overrides `makeTupleType` and `makeTupleTerm` in a way that supports arbitrary tuple sizes.
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-30 15:42:50 +0000