| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Existing enclosing tree macro APIs face both technical and philosophical problems.
On the one hand, it’s close to impossible to provide their robust
implementation within the current typer infrastructure. From the very
beginning, these APIs have been very experimental, and I was very much
hoping to tackle the underlying technical problems, but after a year and
a half I can say that it’s still outside our reach.
On the other hand, we’re gravitating towards increasingly more local macro
expansion, which is in direct contradiction with the existence of
c.enclosingTree APIs. Therefore, in order to be able to further evolve
macros, we need need additional freedom to reshape the enclosing tree APIs.
Therefore I suggest we deprecate the aforementioned APIs and start
preparing ourselves to removing them for good in 2.12.0.
I hope that existing macros that use these APIs can be reformulated in
terms of completely local expansion or be built on top of orthogonal
language features (existing ones or new ones, e.g. something like
https://groups.google.com/forum/#!topic/scala-debate/f4CLmYShX6Q).
Please share your use cases, and I will be glad to help!
We have at least the entire 2.12 development cycle ahead of us, so I’m
sure we’ll figure this out. Let’s shape robust and scalable reflection
API together!
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
When an application of a blackbox macro is used as an implicit candidate,
no expansion is performed until the macro is selected as the result of
the implicit search.
This makes it impossible to dynamically calculate availability of
implicit macros.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 is a port of https://github.com/scala/scala/commit/8168f118c9 from 2.10.x,
with an additional change to the `enclosingImplicits` and `openImplicits` APIs,
which encapsulates tuples of `pt` and `tree` into `ImplicitCandidate`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Confusing, now-it-happens now-it-doesn't mysteries lurk
in the darkness. When scala packages are declared like this:
package scala.collection.mutable
Then paths relative to scala can easily be broken via the unlucky
presence of an empty (or nonempty) directory. Example:
// a.scala
package scala.foo
class Bar { new util.Random }
% scalac ./a.scala
% mkdir util
% scalac ./a.scala
./a.scala:4: error: type Random is not a member of package util
new util.Random
^
one error found
There are two ways to play defense against this:
- don't use relative paths; okay sometimes, less so others
- don't "opt out" of the scala package
This commit mostly pursues the latter, with occasional doses
of the former.
I created a scratch directory containing these empty directories:
actors annotation ant api asm beans cmd collection compat
concurrent control convert docutil dtd duration event factory
forkjoin generic hashing immutable impl include internal io
logging macros man1 matching math meta model mutable nsc parallel
parsing partest persistent process pull ref reflect reify remote
runtime scalap scheduler script swing sys text threadpool tools
transform unchecked util xml
I stopped when I could compile the main src directories
even with all those empties on my classpath.
|
| |
|
|
|
|
|
|
|
| |
No, this isn't busywork, how dare you suggest
such a thing. I intend my tombstone to say
HERE LIES EXTEMPORE,
WHO ELIMINATED A LOT OF SIP-18 WARNINGS
REST IN PEACE
|
| |
|
|
|
| |
Was: ``blah''
Now: `blah`
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently there's only one flavor of macros - def macros, and the plan
was to gradually introduce additional flavors, such as type macros and
macro annotations.
However as shown by the experience with type macros, it makes sense
to distinguish subflavors of macros that tell us in which context the
macro gets expanded. For def macros we have the only role - expansion
of an application. But for type macros there are multiple.
|
| | |
|
| |
|
|
|
| |
- Added the labels across scala.reflect and scala.reflect.macros
- Added the styling in template.css that is used by all labels
|
| | |
|
| |
|
|
|
|
| |
currentRun goes to Enclosures and becomes enclosingRun
currentClassPath gets integrated into Run
|
|
|
Builds a starr that uses stuff from scala.reflect.macros for macro activities.
Crucial makro thingies (such as makro.Context or makro.internal.macroImpl)
are temporarily left in place, because they are necessary for previous starr.
Macro tests will be fixed in a dedicated commit, so that they don't pollute
meaningful commits, making the life easy for reviewers and spelunkers.
|
