| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
A missing range check in case anyone ever wants to use
```
-Dscala.repl.format=across
```
which was observed only because of competition from Ammonite.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under -Ydelambdafy:method (the basis of the upcoming "indylambda"
translation for -target:jvm-1.8), an anonymous function is currently
encoded as:
1. a private method containing the lambda's code
2. a public, static accessor method that allows access to 1 from
other classes, namely:
3. an anonymous class capturing free variables and implementing
the suitable FunctionN interface.
In our prototypes of indylambda, we do away with 3, instead deferring
creating of this class to JDK8's LambdaMetafactory by way of an
invokedynamic instruction at the point of lambda capture. This
facility can use a private method as the lambda target; access is
mediated by the runtime-provided instance of
`java.lang.invoke.MethodHandles.Lookup` that confers the privelages
of the lambda capture call site to the generated implementation class.
Indeed, The java compiler uses this to emit private lambda body
methods.
However, there are two Scala specific factors that make this
a little troublesome.
First, Scala's optimizer may want to inline the lambda capture
call site into a new enclosing class. In general, this isn't a
safe optimization, as `invokedynamic` instructions have call-site
specific semantics. But we will rely the ability to inline like
this in order to eliminate closures altogether where possible.
Second, to support lambda deserialization, the Java compiler creates
a synthetic method `$dersializeLamda$` in each class that captures
them, just to be able to get the suitable access to spin up an
anoymous class with access to the private method. It only needs
to do this for functional interfaces that extends Serializable,
which is the exception rather than the rule. But in Scala, *every*
function must support serialization, so blindly copying the Java
approach will lead to some code bloat.
I have prototyped a hybrid approach to these challenges: use the
private method directly where it is allowed, but fall back to
using the accessor method in a generic lambda deserializer or
in call sites that have been inlined into a new enclosing class.
However, the most straight forward approach is to simply emit the
lambda bodies as public (with an mangled name and with the SYHTNETIC
flag) and use them in all cases. That is what is done in this commit.
This does moves us one step backwards from the goals of SI-7085,
but it doesn't seem sensible to incur the inconvenience from locking
down one small part of our house when we don't have a plan or the
budget to complete that job.
The REPL has some fancy logic to decompile the bodys of lambdas
(`:javap -fun C#m`) which needed tweaking to accomodate this change.
I haven't tried to make this backwards compatible with the old
encoding as `-Ydelambdafy:method` is still experimental.
|
| |
|
|
|
|
|
|
|
|
| |
SessionTest session text can include line continuations
and pasted text. Pasted script (which looks like a
double prompt) probably doesn't work.
This commit includes @retronym's SI-9170 one-liner.
|
|\
| |
| | |
SI-6502 More robust REPL :require
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before, we got in an endless loop if using ^D to try to end the
session. When piping commands into the REPL, this was rather annoying!
```
scala-hash v2.11.5
Welcome to Scala version 2.11.5-20150101-184742-3fafbc204f (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_25).
Type in expressions to have them evaluated.
Type :help for more information.
scala> :require xxx
java.lang.NullPointerException
at scala.tools.nsc.interpreter.ILoop.scala$tools$nsc$interpreter$ILoop$$flatten$1(ILoop.scala:651)
at scala.tools.nsc.interpreter.ILoop.require(ILoop.scala:654)
That entry seems to have slain the compiler. Shall I replay
your session? I can re-run each line except the last one.
[y/n]^D
You must enter y or n.
That entry seems to have slain the compiler. Shall I replay
your session? I can re-run each line except the last one.
[y/n]^D
...
```
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- handle missing files gracefully (rather than NPE)
- read the class name with ASM, rather than with a dummy
classloader. The dummy classloader is prone to throwing
`LinkageError`s, as reported in the comments of SI-6502.
Manual test of the original report:
```
% qscala
Welcome to Scala version 2.11.5-20150115-183424-155dbf3fdf (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_25).
Type in expressions to have them evaluated.
Type :help for more information.
scala> :require does/not/exist
Cannot read: does/not/exist
scala> classOf[org.junit.Test]
<console>:8: error: object junit is not a member of package org
classOf[org.junit.Test]
^
scala> :require /Users/jason/.m2/repository/junit/junit/4.11/junit-4.11.jar
Added '/Users/jason/.m2/repository/junit/junit/4.11/junit-4.11.jar' to classpath.
scala> classOf[org.junit.Test]
res1: Class[org.junit.Test] = interface org.junit.Test
```
I have commited an automated test that is a minimization of this one.
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
The alternative, flat representation of classpath elements
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit contains some minor changes made by the way when
implementing flat classpath.
Sample JUnit test that shows that all pieces of JUnit infrastructure
work correctly now uses assert method form JUnit as it should do from
the beginning.
I removed commented out lines which were obvious to me. In the case
of less obvious commented out lines I added TODOs as someone should
look at such places some day and clean them up.
I removed also some unnecessary semicolons and unused imports.
Many string concatenations using + have been changed to string
interpolation.
There's removed unused, private walkIterator method from ZipArchive.
It seems that it was unused since this commit:
https://github.com/scala/scala/commit/9d4994b96c77d914687433586eb6d1f9e49c520f
However, I had to add an exception for the compatibility checker
because it was complaining about this change.
I made some trivial corrections/optimisations like use 'findClassFile'
method instead of 'findClass' in combination with 'binary' to find
the class file.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit integrates with the compiler the whole flat classpath
representation build next to the recursive one as an alternative.
From now flat classpath really works and can be turned on. There's
added flag -YclasspathImpl with two options: recursive (the default
one) and flat.
It was needed to make the dynamic dispatch to the particular
classpath representation according to the chosen type of a classpath
representation.
There's added PathResolverFactory which is used instead of a concrete
implementation of a path resolver. It turned out that only a small
subset of path resolvers methods is used outside this class in Scala
sources. Therefore, PathResolverFactory returns an instance of a base
interface PathResolverResult providing only these used methods.
PathResolverFactory in combination with matches in some other places
ensures that in all places using classpath we create/get the proper
representation.
Also the classPath method in Global is modified to use the dynamic
dispatch. This is very important change as a return type changed to
the base ClassFileLookup providing subset of old ClassPath public
methods. It can be problematic if someone was using in his project
the explicit ClassPath type or public methods which are not provided
via ClassFileLookup. I tested flat classpath with sbt and Scala IDE
and there were no problems. Also was looking at sources of some other
projects like e.g. Scala plugin for IntelliJ and there shouldn't be
problems, I think, but it would be better to check these changes
using the community build.
Scalap's Main.scala is changed to be able to use both implementations
and also to use flags related to the classpath implementation.
The classpath invalidation is modified to work properly with the old
(recursive) classpath representation after changes made in a Global.
In the case of the attempt to use the invalidation for the flat cp it
just throws exception with a message that the flat one currently
doesn't support the invalidation. And also that's why the partest's
test for the invalidation has been changed to use (always) the old
implementation. There's added an adequate comment with TODO to this
file.
There's added partest test generating various dependencies
(directories, zips and jars with sources and class files) and testing
whether the compilation and further running an application works
correctly, when there are these various types of entries specified as
-classpath and -sourcepath. It should be a good approximation of real
use cases.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The method asClasspathString is now deprecated. Moreover it's moved
to ClassFileLookup in the case someone was using it in some project
(an alternative classpath also will support it - just in the case).
All its usages existing in Scala sources are changed to
asClassPathString method. The only difference is the name.
Some operations on files or their names are moved from ClassPath to
the newly created FileUtils dedicated to classpath. It will be
possible to reuse them when implementing an alternative classpath
representation. Moreover such allocation-free extension methods like
the one added in this commit will improve the readability.
|
|\ \
| |/
|/| |
SI-8981 Tweak REPL help
|
| |
| |
| |
| |
| |
| | |
Tweak colon command processing.
Fixes an unhelpful message about the ambiguity of colon.
|
|\ \
| |/
|/| |
SI-6502 Reenables loading jars into the running REPL (regression in 2.10)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes SI-6502, reenables loading jars into the running REPL
(regression in 2.10). This PR allows adding a jar to the compile
and runtime classpaths without resetting the REPL state (crucial
for Spark SPARK-3257).
This follows the lead taken by @som-snytt in PR #3986, which
differentiates two jar-loading behaviors (muddled by cp):
- adding jars and replaying REPL expressions (using replay)
- adding jars without resetting the REPL (deprecated cp,
introduced require) This PR implements require (left
unimplemented in #3986)
This PR is a simplification of a similar approach taken by
@gkossakowski in #3884. In this attempt, we check first to make
sure that a jar is only added if it only contains new
classes/traits/objects, otherwise we emit an error. This differs
from the old invalidation approach which also tracked deleted
classpath entries.
|
|\ \
| |/
|/| |
SI-8922 REPL load -v
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Verbose mode causes the familiar prompt and
line echo so you can see what you just loaded.
The quit message is pushed up a level in the
process loop.
This has the huge payoff that if you start the
repl and immediately hit ctl-D, you don't have to
wait for the compiler to init (yawn) before you
get a shell prompt back.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To support both -Ydelambdafy strategies, look for both inline
(anonfun) and method (lambda) closure classes.
For method (lambda) style, use the anonfun method that is
invoked by the accessor.
Also, the output of javap must be captured eagerly for
filtering for the current target method.
If the user asks for a module, e.g., `Foo$`, don't yield
results for companion class, but for `Foo`, do yield
companion module results. Just because.
|
|\
| |
| | |
Color REPL under -Dscala.color
|
| | |
|
| |
| |
| |
| |
| | |
* Errors are red
* Warnings are yellow
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We already use -Dscala.color when using -Ytyper-debug
This tries to reuse the colors chosen from the debug flag:
* Bold blue for vals (e.g. "res0")
* Bold green for types (e.g. "Int")
* Magenta for the shell prompt (e.g. "scala>")
|
|\ \
| | |
| | | |
SI-8843 AbsFileCL acts like a CL
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Let the AbstractFileClassLoader override just the usual suspects.
Normal delegation behavior should ensue.
That's instead of overriding `getResourceAsStream`, which was intended
that "The repl classloader now works more like you'd expect a classloader to."
(Workaround for "Don't know how to construct an URL for something which exists
only in memory.")
Also override `findResources` so that `getResources` does the obvious thing,
namely, return one iff `getResource` does.
The translating class loader for REPL only special-cases `foo.class`: as
a fallback, take `foo` as `$line42.$read$something$foo` and try that class file.
That's the use case for "works like you'd expect it to."
There was a previous fix to ensure `getResource` doesn't take a class name.
The convenience behavior, that `classBytes` takes either a class name or a resource
path ending in ".class", has been promoted to `ScalaClassLoader`.
|
|\ \
| | |
| | | |
SI-6502 Repl reset/replay take settings args
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The reset and replay commands take arbitrary command line args.
When settings args are supplied, the compiler is recreated.
For uniformity, the settings command performs only the usual
arg parsing: use -flag:true instead of +flag, and clearing a
setting is promoted to the command line, so that -Xlint: is not
an error but clears the flags.
```
scala> maqicode.Test main null
<console>:8: error: not found: value maqicode
maqicode.Test main null
^
scala> :reset -classpath/a target/scala-2.11/sample_2.11-1.0.jar
Resetting interpreter state.
Forgetting all expression results and named terms: $intp
scala> maqicode.Test main null
Hello, world.
scala> val i = 42
i: Int = 42
scala> s"$i is the loneliest numbah."
res1: String = 42 is the loneliest numbah.
scala> :replay -classpath ""
Replaying: maqicode.Test main null
Hello, world.
Replaying: val i = 42
i: Int = 42
Replaying: s"$i is the loneliest numbah."
res1: String = 42 is the loneliest numbah.
scala> :replay -classpath/a ""
Replaying: maqicode.Test main null
<console>:8: error: not found: value maqicode
maqicode.Test main null
^
Replaying: val i = 42
i: Int = 42
Replaying: s"$i is the loneliest numbah."
res1: String = 42 is the loneliest numbah.
```
Clearing a clearable setting:
```
scala> :reset -Xlint:missing-interpolator
Resetting interpreter state.
scala> { val i = 42 ; "$i is the loneliest numbah." }
<console>:8: warning: possible missing interpolator: detected interpolated identifier `$i`
{ val i = 42 ; "$i is the loneliest numbah." }
^
res0: String = $i is the loneliest numbah.
scala> :reset -Xlint:
Resetting interpreter state.
Forgetting this session history:
{ val i = 42 ; "$i is the loneliest numbah." }
scala> { val i = 42 ; "$i is the loneliest numbah." }
res0: String = $i is the loneliest numbah.
```
|
| |/
| |
| |
| |
| |
| |
| |
| | |
People expect to change the class path midstream.
Let's disabuse them by removing the broken command.
The internals are deprecated.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under load on Jenkins, we've been seeing:
```
% diff /localhome/jenkins/a/workspace/scala-nightly-auxjvm-2.12.x/jdk/jdk7/label/auxjvm/test/files/run/t4542-run.log /localhome/jenkins/a/workspace/scala-nightly-auxjvm-2.12.x/jdk/jdk7/label/auxjvm/test/files/run/t4542.check
@@ -2,75 +2,14 @@ Type in expressions to have them evaluated.
Type :help for more information.
scala> @deprecated("foooo", "ReplTest version 1.0-FINAL") class Foo() {
java.util.concurrent.TimeoutException: Futures timed out after [60 seconds]
at scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:219)
at scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:153)
at scala.concurrent.Await$$anonfun$ready$1.apply(package.scala:95)
at scala.concurrent.Await$$anonfun$ready$1.apply(package.scala:95)
at scala.concurrent.BlockContext$DefaultBlockContext$.blockOn(BlockContext.scala:53)
at scala.concurrent.Await$.ready(package.scala:95)
at scala.tools.nsc.interpreter.ILoop.processLine(ILoop.scala:431)
at scala.tools.nsc.interpreter.ILoop.loop(ILoop.scala:457)
at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply$mcZ$sp(ILoop.scala:875)
```
This commit bumps the timeout up be a factor of ten to try to
restore that comforting green glow to https://scala-webapps.epfl.ch/jenkins/view/2.N.x
|
|
|
|
|
|
|
|
| |
That nice little `-Dscala.repl.vids` feature regressed in f56f9a3c when
a string.format was replaced by string interpolation.
The ones in scala-reflect were caught by Xlint (who knew building with
Xlint was actually useful...), the other was just luck.
|
|\
| |
| | |
part 2 of the big error reporting refactoring
|
| |
| |
| |
| |
| |
| | |
Create a trait Parsing, which, like Reporting,
factors our functionality from Global (aka. "the cake"),
that is related to global aspects of configuring parsing.
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
Closing the REPL with Ctrl+D does not issue a newline, so the user's
prompt displays on the same line as the `scala>` prompt. This is bad.
We now force a newline before closing the interpreter, and display
`:quit` while we're at it so that people know how to exit the REPL
(since `exit` doesn't exist anymore).
The tricky part was to only add a newline when the console is
interrupted, and *not* when it is closed by a command (like `:quit`),
since commands are processed after their text (including newline) has
been sent to the console.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move code from Global/SymbolTable to separate Reporting traits to
start carving out an interface in scala.reflect.internal.Reporting,
with internals in scala.tools.nsc. Reporting is mixed into the cake.
It contains a nested class PerRunReporting.
Should do the same for debugging/logging.
The idea is that CompilationUnit and Global forward all reporting
to Reporter. The Reporting trait contains these forwarders, and
PerRunReporting, which accumulates warning state during a run.
In the process, I slightly changed the behavior of `globalError`
in reflect.internal.SymbolTable: it used to abort, weirdly.
I assume that was dummy behavior to avoid introducing an abstract method.
It's immediately overridden in Global, and I couldn't find any other subclasses,
so I don't think the behavior in SymbolTable was ever observed.
Provide necessary hooks for scala.reflect.macros.Parsers#parse.
See scala/reflect/macros/contexts/Parsers.scala's parse method,
which overrides the reporter to detect when parsing goes wrong.
This should be refactored, but that goes beyond the scope of this PR.
Don't pop empty macro context stack.
(Ran into this while reworking -Xfatal-warnings logic.)
Fix -Xfatal-warnings behavior (and check files): it wasn't meant to
influence warning reporting, except for emitting one final error;
if necessary to fail the compile (when warnings but no errors were reported).
Warnings should stay warnings.
This was refactored in fbbbb22946, but we soon seem to have relapsed.
An hour of gitfu did not lead to where it went wrong. Must've been a merge.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor to reduce the Reporter interface. Working towards
minimal interfaces in scala.reflect.internal that can be consumed by sbt/IDE/....
The scala.tools.nsc package is entirely private to the compiler (in principle).
A `Reporter` should only be used to inform (info/warning/error). No state.
Ideally, we'd move to having only one reporter, whose lifetime is adjusted
appropriately (from per-run in general to per-context for type checking,
so errors can be buffered -- "silenced" -- during nested type checking calls).
Start the clean up by moving truncation to the REPL,
since it's not relevant for regular reporting. Perversely, we were checking
truncation all the time, even though it's only on during a repl run.
(Truncation is now always turned off in the repl under -verbose.)
Untangle error resetting on symbols from error reporting (reportAdditionalErrors).
This fixes a nice&subtle bug that caused feature warnings to be suppressed under
`-Xfatal-warnings`:
```
def reportCompileErrors() {
if (!reporter.hasErrors && reporter.hasWarnings && settings.fatalWarnings)
globalError("No warnings can be incurred under -Xfatal-warnings.")
if (reporter.hasErrors) { ... }
else {
// will erroneously not get here if
// `reporter.hasWarnings && settings.fatalWarnings`
// since the `globalError` call above means `reporter.hasErrors`...
allConditionalWarnings foreach (_.summarize())
...
}
}
```
The second `if`'s condition depends on the `globalError` call in the first `if`...
|
|\
| |
| | |
SI-8494 Restore filtering javap output
|
| |
| |
| |
| |
| |
| | |
When filtering javap output, include specialized versions
of methods. For anonfuns, in particular, the apply$sp is
the method of interest.
|
| |
| |
| |
| |
| |
| |
| | |
Regressed in support for new delayedEndPoint, where it must
pick what to filter for.
`s/claas/klass/` and similar.
|
|/
|
|
|
|
|
|
|
|
|
| |
And the Scala runner exits with 0 for info settings.
Producing the version string is consolidated.
The compiler driver uses the default settings hook to
short-circuit on -version. That's to avoid creating
the compiler; really it should check shouldStopWithInfo
first, as the runner does.
|
|
|
|
|
|
|
|
| |
Incremental robustness, and probe for typer phase.
The probe would be unnecessary if repl contributed a
terminal phase that "requires" whatever it needs; that
is checked when the Run is built.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under a weird coincidence of circumstances provided by `sbt console-quick`,
new XML parsing logic in compiler plugin initialization could lead to stack
overflow errors.
Here's the abridged sequence events that led to this unfortunate problem
(full description can be found on the JIRA issue page):
1) Initialization of the compiler underlying the REPL would kick off
plugin initialization.
2) PluginDescription.fromXML would call into DocumentBuilderFactory, i.e.
DocumentBuilderFactory.newInstance.newDocumentBuilder.parse(xml).
3) That thing would call into javax.xml.parsers.SecuritySupport.getResourceAsStream,
requesting META-INF/services/javax.xml.parsers.DocumentBuilderFactory.
4) That request would get serviced by TranslatingClassLoader provided
by the REPL to expose dynamically compiled code.
5) TranslatingClassLoader would call translatePath that would call into
IMain.symbolOfIdent trying to map the requested resource onto one of the
classes defined by the REPL (which don't exist yet, because REPL hasn't
yet finished initializing).
6) IMain.symbolOfIdent would request IMain.global, which is exactly the
instance of the compiler that underlies the REPL, and that's currently
being initialized.
7..inf) Repeat until a StackOverflowError.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It’s almost 1am, so I’m only scratching the surface, mechanistically
applying the renames that I’ve written down in my notebook:
* typeSignature => info
* declarations => decls
* nme/tpnme => termNames/typeNames
* paramss => paramLists
* allOverriddenSymbols => overrides
Some explanation is in order so that I don’t get crucified :)
1) No information loss happens when abbreviating `typeSignature` and `declarations`.
We already have contractions in a number of our public APIs (e.g. `typeParams`),
and I think it’s fine to shorten words as long as people can understand
the shortened versions without a background in scalac.
2) I agree with Simon that `nme` and `tpnme` are cryptic. I think it would
be thoughtful of us to provide newcomers with better names. To offset
the increase in mouthfulness, I’ve moved `MethodSymbol.isConstructor`
to `Symbol.isConstructor`, which covers the most popular use case for nme’s.
3) I also agree that putting `paramss` is a lot to ask of our users.
The double-“s” convention is very neat, but let’s admit that it’s just
weird for the newcomers. I think `paramLists` is a good compromise here.
4) `allOverriddenSymbols` is my personal complaint. I think it’s a mouthful
and a shorter name would be a much better fit for the public API.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reflection API exhibits a tension inherent to experimental things:
on the one hand we want it to grow into a beautiful and robust API,
but on the other hand we have to deal with immaturity of underlying mechanisms
by providing not very pretty solutions to enable important use cases.
In Scala 2.10, which was our first stab at reflection API, we didn't
have a systematic approach to dealing with this tension, sometimes exposing
too much of internals (e.g. Symbol.deSkolemize) and sometimes exposing
too little (e.g. there's still no facility to change owners, to do typing
transformations, etc). This resulted in certain confusion with some internal
APIs living among public ones, scaring the newcomers, and some internal APIs
only available via casting, which requires intimate knowledge of the
compiler and breaks compatibility guarantees.
This led to creation of the `internal` API module for the reflection API,
which provides advanced APIs necessary for macros that push boundaries
of the state of the art, clearly demarcating them from the more or less
straightforward rest and providing compatibility guarantees on par with
the rest of the reflection API.
This commit does break source compatibility with reflection API in 2.10,
but the next commit is going to introduce a strategy of dealing with that.
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
| |
The problem is that the repl underneath the script engine evaluates input to
val res0..resN, so it is a one shot operation. To allow repetition,
compile(script) now returns a CompiledScript object whose eval method can be
called any number of times.
|