| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Sometimes booleans and a little duplication go a long way.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
```
⚡ qscala -deprecation
Welcome to Scala 2.12.0-20160126-000825-1e302b76aa (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_66).
Type in expressions for evaluation. Or try :help.
scala> import reflect.macros.blackbox.Context; import language.experimental.macros
import reflect.macros.blackbox.Context
import language.experimental.macros
scala> def impl(c: Context) = {println(c.universe.showRaw(c.parse("val then = 0"))); c.literalUnit}; def m: Unit = macro impl;
<console>:13: warning: method literalUnit in trait ExprUtils is deprecated: Use quasiquotes instead
def impl(c: Context) = {println(c.universe.showRaw(c.parse("val then = 0"))); c.literalUnit}; def m: Unit = macro impl;
^
impl: (c: scala.reflect.macros.blackbox.Context)c.Expr[Unit]
defined term macro m: Unit
scala> m
<console>:16: error: exception during macro expansion:
scala.MatchError: pos: source-<macro>,line-1,offset=4 then is now a reserved word; usage as an identifier is deprecated WARNING (of class scala.tools.nsc.reporters.StoreReporter$Info)
at scala.reflect.macros.contexts.Parsers$class.scala$reflect$macros$contexts$Parsers$class$$$anonfun$1(Parsers.scala:17)
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
If we append a dollar to a user-provided prefix that ends in a dollar,
we create a potential for confusion for backend phases. That's why
this commit prevents such situations from happening.
|
| |\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/compiler/scala/reflect/macros/compiler/Resolvers.scala
src/compiler/scala/reflect/macros/contexts/Typers.scala
src/compiler/scala/tools/reflect/ToolBoxFactory.scala
src/reflect/scala/reflect/api/BuildUtils.scala
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
MemberDefs alone can't be typechecked as is, because namer only names
contents of PackageDefs, Templates and Blocks. And, if not named, a tree
can't be typed.
This commit solves this problem by wrapping typecheckees in a trivial block
and then unwrapping the result when it returns back from the typechecker.
|
| | |
| |
| |
| |
| | |
typingTransform and typingTransform's atOwner now work both with
solitary trees and Tree+Symbol couples.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As per Jason’s request, this commit introduces a facility to perform
tree transformations that know how to track current lexical context
and how to typecheck trees in that lexical context.
Interestingly enough, we can’t get away with the traditional “subclass the
Transformer” approach, because the required base transformer class is
declared in scala-compiler.jar, and our API is defined in scala-reflect.jar.
This forced me to play with an idea that we’ve discussed with Denys today
(actually, it’s already yesterday) - lightweight transformers that take
contextful HOFs. This commit is a sketch in that direction. Turning
`transform` and `typingTransform` into macros would make the API more
elegant (see the comments), but I didn’t have time to experiment.
I’m running short on time, so I haven’t had a chance to actually test this API,
but I’m still submitting the pull request to ignite a discussion.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Sometimes universe.internal just won’t cut it (for example, when internal
APIs need access to enclosingOwner or to the typechecker), and for that
we need c.internal.
It’s totally not a problem for us in Scala, because with first-class modules
we can just inherit c.internal from c.universe.internal and have it expose
all the basic APIs automatically. Yay for Scala!
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As per discussion at https://groups.google.com/forum/#!topic/scala-internals/nf_ooEBn6-k,
this commit introduces the new c.enclosingOwner API that is going to serve
two purposes: 1) provide a better controlled alternative to c.enclosingTree,
2) enable low-level tinkering with owner chains without having to cast
to compiler internals.
This solution is not ideal, because: 1) symbols are much more than
I would like to expose about enclosing lexical contexts (after the
aforementioned discussion I’m no longer completely sure whether exposing
nothing is the right thing to do, but exposing symbol completers is definitely
something that should be avoided), 2) we shouldn’t have to do that
low-level stuff in the first place.
However, let’s face the facts. This change represents both an improvement
over the state of the art wrt #1 and a long-awaited capability wrt #2.
I think this pretty much warrants its place in trunk in the spirit of
gradual, evolutionary development of reflection 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.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
As per multiple user requests, this commit introduces a shortcut
to typecheck trees under multiple different modes: terms (EXPRmode,
was exposed in Scala 2.10) and types (TYPEmode).
Looking into the rest of a dozen of internal typechecker modes, to the
best of my knowledge, I can’t find other modes that we could expose.
FUNmode is useful, but very situational. PATTERNmode is useful, but
also situational, because we don’t expand macros inside patterns
except for whitebox extractor macros. The rest (e.g. POLYmode or TAPPmode)
are too low-level.
|
| |
|
|
|
| |
Now when resetAllAttrs is gone, we can use a shorter name for the one
and only resetLocalAttrs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit removes resetAllAttrs from the public reflection API.
This method was previously deprecated, but on a second thought that
doesn't do it justice. People should be aware that resetAllAttrs is just
wrong, and if they have code that uses it, this code should be rewritten
immediately without beating around the bush with deprecations. There's
a source-compatible way of achieving that (resetLocalAttrs), so that
shouldn't bring much trouble.
Secondly, resetAllAttrs in compiler internals becomes deprecated. In subsequent
commits I'm going to rewrite the only two locations in the compiler that
uses it, and then I think we can remove it from the compiler as well.
|
| |\
| |
| | |
SI-6879 improves Context.freshName
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of per-compilation unit unique counters, the freshName API now
uses a per-Global counter. Fresh names now also contain dollars to exclude
clashes with supported user-defined names (the ones without dollar signs).
This doesn’t fix the bug, because per-Global counters get created anew
every time a new Global is instantiated, and that provides some potential
for name clashes even for def macros, but at least it completely excludes
clashes in typical situations.
|
| |/
|
|
|
|
| |
People are very frequently using c.eval in order to obtain underlying
values of literals. Spinning up a new compiler for that modest purpose
is a gross waste of fossil fuels.
|
| |\
| |
| | |
deprecates resetAllAttrs and resetLocalAttrs in favor of the new API
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We now have c.untypecheck, which is supposed to be a counterpart of c.typecheck
in the sense that it goes back from typed trees to untyped ones:
http://stackoverflow.com/questions/20936509/scala-macros-what-is-the-difference-between-typed-aka-typechecked-an-untyped.
Let’s hope that c.untypecheck will soon be able to solve our problems
with partially/incorrectly attributed trees emitted by macros:
https://groups.google.com/forum/#!topic/scala-internals/TtCTPlj_qcQ.
|
| |/
|
|
|
|
|
|
|
|
| |
Performs the following renamings:
* scala.reflect.macros.BlackboxContext to scala.reflect.macros.blackbox.Context
* scala.reflect.macros.BlackboxMacro to scala.reflect.macros.blackbox.Macro
* scala.reflect.macros.WhiteboxContext to scala.reflect.macros.whitebox.Context
* scala.reflect.macros.WhiteboxMacro to scala.reflect.macros.whitebox.Macro
https://groups.google.com/forum/#!topic/scala-internals/MX40-dM28rk
|
| |
|
|
|
|
|
|
|
|
| |
In Jan 2013, I submitted a number of pull requests that built up a foundation
for the upcoming type macros pull request. Unfortunately, type macros
ended up being rejected, but the extra generality introduced in advance
still persisted in the compiler until now.
This commit takes care of unused generality in the macro engine,
keeping the internal implementation as well as the public API clean.
|
| |\
| |
| | |
typeCheck => typecheck
|
| | |
| |
| |
| |
| | |
This method has always been slightly bothering me, so I was really glad
when Denys asked me to rename it. Let’s see how it pans out.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit continues the tendency set by the parent commit to duplicate
as much as possible in order to avoid potential confusion that users
might run into when compiler internals start leaking.
Here we plumb another way that by-reference sharing of trees might bite
unsuspecting macro writers. Previously we have duplicated macro expansions,
macro arguments, c.macroApplication, and now it’s arguments to typeCheck
and resetAttrs.
There is still an unlikely situation when someone gets to c.enclosingXXX
and then starts typechecking around, but that’s left for future work,
as it’s yet unclear what to do with c.enclosingXXX APIs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first commit in the series. This commit only:
1) Splits Context into BlackboxContext and WhiteboxContext
2) Splits Macro into BlackboxMacro and WhiteboxMacro
3) Introduces the isBundle property in the macro impl binding
Here we just teach the compiler that macros can now be blackbox and whitebox,
without actually imposing any restrictions on blackbox macros. These
restrictions will come in subsequent commits.
For description and documentation of the blackbox/whitebox separation
see the official macro guide at the scaladoc website:
http://docs.scala-lang.org/overviews/macros/blackbox-whitebox.html
Some infrastructure work to make evolving macros easier:
compile partest-extras with quick so they can use latest library/reflect/...
|
| |
|
|
|
| |
This should ensure that concurrent access to the
fresh name creator is properly synchronized.
|
| |
|
|
|
|
| |
In order to implement this a new parser entry point
`parseStatsOrPackages` that augments current parseStats with ability
to parse "package name { ... }" syntax.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
1. macro parsing doesn't use toolbox any more but calls parser directly
2. in order for this to work parser has to be refactored to limit
usage of currentUnit and rewire it into parser's local unit
method which might use currentUnit for some parsers but will
user proper unit for UnitParser
3. similar change has to be done to make compilation unit's
reporter overridable
|
| |
|
|
|
|
|
|
|
|
|
| |
As we've figured out from the practice, introduceTopLevel is seductively
useful but unfortunately not robust, potentially bringing compilation
order problems.
Therefore, as discussed, I'm removing it from the public macro API.
Alternatives are either: 1) delving into internals, or
2) using macro paradise and experimenting with macro annotations:
http://docs.scala-lang.org/overviews/macros/annotations.html.
|
|
|
Following typedMacroBody, macroRuntime along with its friends has also
been moved out into a separate component.
|
