| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
SCP-009: Improve direct dependency experience
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
|
|
| |
Nested java classes have a synthetic outer parameter, which the classfile parser
skips for the constructor symbol. When assigning parameter names from the
MethodParameters classfile attribute, we also need to skip the first name in this
case.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
```
|
|\ \
| | |
| | | |
SI-9915 Utf8_info are modified UTF8
|
| | |
| | |
| | |
| | |
| | |
| | | |
Use DataInputStream.readUTF to read CONSTANT_Utf8_info.
This fixes reading embedded null char and supplementary chars.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Tighten some types (Symbol -> ClassSymbol / ModuleSymbol), use NonFatal
instead of catching Throwable.
Also don't run the classfile parser enteringPhase(phaseBeforeRefchecks)
anymore. This was added in 0ccdb15 but seems no longer required.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Skipping other annotations not only saves some cycles / GC, but also
prevents some spurious warnings / errors related to cyclic dependencies
when parsing annotation arguments refering to members of the class.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In SymbolLoaders, when seeing a classfile `Foo.class`, we always
(unconditionally) create 3 symbols: a class, a module and a module
class. Some symbols get invalidated later (`.exists`).
Until now, the classfile parser (and unpickler) received the "root"
symbol as argument, which is the symbol whose type is being completed.
This is either the class symbol or the module symbol.
The classfile parser would then try to lookup the other symbol through
`root.companionClass` or `root.companionModule`. Howver, this lookup can
fail. One example is scala-dev#248: when a type alias (in a package
object) shadows a class symbol, `companionClass` will fail.
The implementations of the classfile parser / unpickler assume that
both the `clazz` and the `staticModule` symbols are available. This
change makes sure that they are always passed in explicitly.
Before this patch, in the example of scala-dev#248, the `classRoot` of
the unpickler was NoSymbol. This caused a bug when unpickling the
module class symbol, causing a second module class symbol to be created
mistakingly. The next commit cleans up this logic, more details there.
This second symbol would then cause the crash in the backend because it
doesn't have an `associatedFile`, therefore `isCoDefinedWith` would
spuriously return `true`.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
One of the first entries in the classfile is the class name. The
classfile parser performs a cross-check by looking up the class sybmol
corresponding to that name and ensures it's the same as `clazz`, the
class symbol that the parser currently populates.
Since 322c980 ("Another massive IDE checkin"), if at the time of the
check `clazz` but the lookup returns some class, the `clazz` field is
assigned.
The commit following this one makes sure `clazz` is never NoSymbol, so
the assignment can safely be removed.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There was a piece of logic essentially duplicating getClassByName
in Mirrors (split up a fully qualified class name by ".", look up
pieces). That piece of code was added in 0ce0ad5 to fix one example in
SI-2464.
However, since 020053c (2012, 2.10) that code was broken: the line
ss = name.subName(0, start)
should be
ss = name.subName(start, name.length).toTypeName
As a result, the code would always create a stub symbol. Returning a
stub seems to be the right thing to do anyway, and the fact that we were
doing so during two major releases is a good proof.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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`.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
JEP 118 added a MethodParameters attribute to the class file spec which
holds the parameter names of methods when compiling Java code with
`javac -parameters`.
We emit parameter names by default now.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Until now, the warning was only emitted for enums from Java class files.
This commit fixes it by
- aligning the flags set in JavaParsers with the flags set in
ClassfileParser (which are required by the pattern matcher to
even consider checking exhaustiveness)
- adding the enum members as childs to the class holding the enum
as done in ClassfileParser so that the pattern matcher sees the enum
members when looking for the sealed children of a type
|
|/ |
|
|\
| |
| | |
SI-9403 fix ICodeReader for negative BIPUSH / SIPUSH values
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The byte value of a BIPUSH instruction and the (byte1 << 8) | byte2
value of a SIPUSH instruction are signed, see [1] and [2].
Similar for the increment value of IINC [3].
[1] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.bipush
[2] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.sipush
[3] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.iinc
|
| |
| |
| |
| |
| | |
Similar to the new JAVA_ANNOTATION flag, be more explicit about flags
for java entities.
|
|/
|
|
|
|
|
|
|
|
| |
According to the spec [1] the superclass of an interface is always
Object.
Restores the tests that were moved to pending in bf951ec1,
fixex part of SI-9374.
[1] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.1
|
|\
| |
| | |
Fix 25 typos (g-i)
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The access flags in InnerClass entries for nested Java enums were
basically completely off.
A first step is to use the recently introduced backend method
`javaClassfileFlags`, which is now moved to BCodeAsmCommon.
See its doc for an explanation.
Then the flags of the enum class symbol were off. An enum is
- final if none of its values has a class body
- abstract if it has an abstract method
(https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.9)
When using the ClassfileParser:
- ENUM was never added. I guess that's just an oversight.
- ABSTRACT (together with SEALED) was always added. This is to
enable exhaustiveness checking, see 3f7b8b5. This is a hack and we
have to go through the class members in the backend to find out if
the enum actually has the `ACC_ABSTRACT` flag or not.
When using the JavaParser:
- FINAL was never added.
- ABSTRACT was never added.
This commit fixes all of the above and tests cases (Java enum read
from the classfile and from source).
|
|\
| |
| | |
SI-8679 Add support for ScalaLongSignature attribute in scalap
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
scalap didn't support really big class files. It was returning an
empty String for such files. The reason was that there were only
ScalaSignatures taken into account.
This commit adds support for ScalaLongSignature. We try to get such
an attribute when we didn't find ScalaSignature. Also there's added
an additional case to the logic retrieving bytes for a signature.
Since ScalaLongSignature can contain many parts, we have to merge
their byte arrays.
Changes are tested by a new partest-based test. These two files are
really big, but it was required (t8679.scala is a reduced version of
BigScalaClass - an example attached to JIRA).
There are also added TODOs with a JIRA ticket: We have three places,
where we process Scala signatures. In the future it would be better to
reuse some common logic, if it's possible.
|
|/
|
|
|
|
|
|
|
|
|
|
| |
Based on analysis of a stack trace in this bug report, I identified
a code path in `ClassfileParser` that can lead to an NPE in its
exception handling code. If `val in = new AbstractFileReader(file)`
throws (e.g during its construction in which it eagerly reads the
file `val buf: Array[Byte] = file.toByteArray`), the call to
`in.file` in `handleError` will NPE.
This commit stores the active file directly a field in ClassfileParser
and uses this in the error reporting.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When parsing a Java generic signature that references an inner
class `A$B`, we were tripping an assertion if the enclosing class
`A` was absent.
This commit creates a stub symbol for `B` when this happens, rather
than continuing on with `NoSymbol`.
The enclosed test shows that we can instantiate a class containing
a method referring to such an inner class with only a warning
about the absent classfile, and that an error is issued only upon
a subsequent attempt to call the method.
|
|\
| |
| | |
SI-7741: Be more tolerant of absent inner classfiles and non-Scala interface members
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1. Avoid forcing info of non-Scala interface members
This avoids parsing the ostensibly malformed class definitions that
correspond to a Groovy lambda defined in an interface.
2. Be more tolerant of absent inner classfiles
Taking a leaf out of javac's book (see transcript below),
we can use stub symbols for InnerClass entries that don't
have corresponding class files on the compilation classpath.
This will limit failures to code that directly refers to the
inner class, rather than any code that simply refers to the
enclosing class.
It seems that groovyc has a habit of emitting incongrous
bytecode in this regard. But this change seems generally
useful.
```
% cat sandbox/{Test,Client}.java
public class Test {
public class Inner {}
}
public class Client {
public Test.Inner x() { return null; }
}
% javac -d . sandbox/Test.java && javac -classpath . sandbox/Client.java
% javac -d . sandbox/Test.java && rm 'Test$Inner.class' && javac -classpath . sandbox/Client.java
sandbox/Client.java:2: error: cannot access Inner
public Test.Inner x() { return null; }
^
class file for Test$Inner not found
1 error
% cat sandbox/{Test,Client}.java
public class Test {
public class Inner {}
}
public class Client {
public Test.NeverExisted x() { return null; }
}
% javac -classpath . sandbox/Client.java
sandbox/Client.java:2: error: cannot find symbol
public Test.NeverExisted x() { return null; }
^
symbol: class NeverExisted
location: class Test
1 error
% cat sandbox/{Test,Client}.java
public class Test {
public class Inner {}
}
public class Client {
public Test x() { return null; }
}
topic/groovy-interop ~/code/scala2 javac -d . sandbox/Test.java && rm 'Test$Inner.class' && javac -classpath . sandbox/Client.java # allowed
```
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Added `since` to deprecation statement
- Added unit to parameter list
- Removed usage of deprecated method polyType
- Replaced deprecated `debugwarn` with `devWarning`
- Changed switch statement to if else in order to remove a warning
- Switched implementation of `init` and `processOptions` to prevent
warning
- Replaced deprecated `Console.readLine` with `scala.io.StdIn.readLine`
- Replaced deprecated `startOrPoint` with `start`
- Replaced deprecated `tpe_=` with `setType`
- Replaced deprecated `typeCheck` with `typecheck`
- Replaced deprecated `CompilationUnit.warning` with `typer.context.warning`
- Replaced deprecated `scala.tools.nsc.util.ScalaClassLoader` with `scala.reflect.internal.util.ScalaClassLoader`
- Replaced deprecated `scala.tools.ListOfNil` with `scala.reflect.internal.util.ListOfNil`
- Replaced deprecated `scala.tools.utils.ScalaClassLoader` with `scala.reflect.internal.util.ScalaClassLoader`
- Replaced deprecated `emptyValDef` with `noSelfType`
- In `BoxesRunTime` removed unused method and commented out unused values. Did not delete to keep a reference to the values. If they are deleted people might wonder why `1` and `2` are not used.
- Replaced deprecated `scala.tools.nsc.util.AbstractFileClassLoader` with `scala.reflect.internal.util.AbstractFileClassLoader`
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit corrects many typos found in scaladocs, comments and
documentation. It should reduce a bit number of PRs which fix one
typo.
There are no changes in the 'real' code except one corrected name of
a JUnit test method and some error messages in exceptions. In the case
of typos in other method or field names etc., I just skipped them.
Obviously this commit doesn't fix all existing typos. I just generated
in IntelliJ the list of potential typos and looked through it quickly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit is intended to create the possibility to plug in into
the compiler an alternative classpath representation which would be
possibly more efficient, use less memory etc. Such an implementation
- at least at the beginning - should exist next to the currently
existing one and be possible to turn on using a flag.
Several places in the compiler have a direct dependency on the
classpath implementation. Examples include backend's icode generator
and reader, SymbolLoaders, ClassfileParser. After closer inspection,
one realizes that all those places depend only on a very small subset
of classpath logic: they need to lookup classes from classpath. Hence
there's introduced ClassFileLookup trait that encapsulates that
functionality. The ClassPath extends that trait and an alternative
one also must do it.
There's also added ClassRepresentation - the base trait for ClassRep
(the inner class of ClassPath). Thanks to that the compiler uses
a type which is not directly related to the particular classpath
representation as it was doing until now.
|
|
|
|
|
|
|
| |
If you look at the implementation of that method and its usage
its clear that it should have been named `findClassFile` from the
beginning because that's what it does: find a class file and
not a source file.
|
|\
| |
| | |
SI-8708 Fix pickling of LOCAL_CHILD child of sealed classes
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a sealed class or trait has local children, they are not pickled
in as part of the children of the symbol (introduced in 12a2b3b to fix
Aladdin bug 1055). Instead the compiler adds a single child class
named LOCAL_CHILD. The parents of its ClassInfoType were wrong: the
first parent should be a class. For sealed traits, we were using the
trait itself.
Also, the LOCAL_CHILD dummy class was entered as a member of its
enclosing class, which is wrong: it represents a local (non-member)
class, and it's a synthetic dummy anyway.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
And update the java `ClassFileParser` to create distinguished
`StubClassSymbol`s, rather that a regular `ClassSymbol`s, when
encountering a deficient classpath. This brings it into line
with `Unpickler`, which has done as much since a55788e275f.
This stops the enclosed test case from crashing when determining
if the absent symbol, `A_1`, is a subclass of `@deprecated`.
This is ostensibly fixes a regression, although it only worked in
`2.10.[0-3]` by a fluke: the class file parser's promiscious
exception handling caught and recovered from the NPE introduced
in SI-7439!
% javac -d /tmp test/files/run/t8442/{A,B}_1.java && qbin/scalac -classpath /tmp -d /tmp test/files/run/t8442/C_2.scala && (rm /tmp/A_1.class; true) && scalac-hash v2.10.0 -classpath /tmp -d /tmp test/files/run/t8442/C_2.scala
warning: Class A_1 not found - continuing with a stub.
warning: Caught: java.lang.NullPointerException while parsing annotations in /tmp/B_1.class
two warnings found
|
| |
| |
| |
| |
| |
| |
| |
| | |
This is the first step in disentangling api#Symbol.isPackage, which is
supposed to return false for package classes, and internal#Symbol.isPackage,
which has traditionally being used as a synonym for hasPackageFlag and
hence returned true for package classes (unlike isModule which is false
for module classes).
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In #1901, handling of raw types encountered in signatures during class
file parsing was changed to work in the same manner as
`classExistentialType`, by using
`existentialAbstraction(cls.tparms, cls.tpe_*)`
But this never creates fresh existential symbols, and just sticks
the class type parameters it `quantified`:
scala> trait T[A <: String]
defined trait T
scala> val cls = typeOf[T[_]].typeSymbol
cls = trait T#101864
scala> cls.typeParams
res0 = List(type A#101865)
scala> cls.tpe_*
res1 = T#101864[A#101865]
scala> classExistentialType(cls)
res3 = T#101864[_ <: String#7209]
scala> val ExistentialType(quantified, result) = res3
List(type A#101865)
In the enclosed test case, this class type parameter was substituted
during `typeOf[X] memberType sym`, which led us unsoundly thinking
that `Raw[_]` was `Raw[X]`.
I've added a TODO comment to review the other usages of
`classExistentialType`.
Test variations include joint and separate compilation, and the
corresponding Scala-only code. All fail with type errors now,
as we expect. I've also added a distillation of a bootstrap
error that failed when I forgot to wrap the `existentialType`.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| | |
- move "erroneous type" diagnostic into a crash recovery handler,
rather than running it proactively
- move the "unexpanded macros" check into refchecks.
Cuts this phase in half, from about 1% of compile time to 0.5%.
|
|\ \
| | |
| | | |
SI-8151 Remove -Yself-in-annots and associated implementation
|