| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
SI-6455 no longer rewrite .withFilter to .filter
|
| |
| |
| |
| |
| | |
This has been deprecated for two major releases now,
but `filter`'s still preferred over `withFilter` in the wild.
|
| | |
|
| | |
|
|/
|
|
|
|
| |
TypedTreesPrinter added
changes based on pull request comments:
print root packages flag; tests for syntactics; SyntacticEmptyTypeTree added to Printers
|
|
|
|
|
|
|
|
|
| |
As per Denys's request, renames methods in ReificationSupport that are
eponymous to methods in Universe, so that we don't get nasty name
intersections.
This change is not source/binary-compatible, because we don't make any
promises about the contents of the build API. Feedback welcome.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Such representation codifies the fact that type tree that doesn't have
embedded syntactic equivalent must have been inferred or otherwise
provided by the compiler rather than specified by the end user.
Additionally it also ensures that we can still match trees without
explicit types (e.g. vals without type) after typechecking. Otherwise
the same quote couldn't be used in situations like:
val q"val x = 42" = typecheck(q"val x = 42")
|
| |
|
| |
|
|
|
|
|
|
| |
1. q"for (..$enums) $body", q"for (..$enums) yield $body"
2. fq"..." quote to construct/deconstruct enumerators
|
|
Typecheck trees with toolbox and check that they are still matched
by corresponding quasiquote. Fix tuples and function types matchers
to account for different shape of trees after typing.
|