summaryrefslogtreecommitdiff
path: root/src/reflect/scala/reflect/macros
Commit message (Collapse)AuthorAgeFilesLines
* Fix typos in compiler and reflectJanek Bogucki2017-02-131-1/+1
| | | | | | | | | | | | Miscellania: Miscellania is a small island off the northernmost part of the Fremennik Isles - RunScape Wiki Miscellanea: A collection of miscellaneous objects or writings - Merriam-Webster
* Lower-case spelling of @deprecated messagesSimon Ochsenreither2016-05-285-42/+42
|
* General cleanups and less warnings during a Scala buildsoc2016-04-041-2/+0
|
* Apply some static code analysis recommendationsJanek Bogucki2015-11-261-1/+1
| | | | | | | | | | | | | | | | Fix a batch of code inspection recommendations generated by IntelliJ 14.1.5. Categories of fix, Unnecessary public modifier in interface Replace filter+size with count Replace filter+nonEmpty with exists Replace filter+headOption with find Replace `if (x != null) Some(x) else None` with Option(x) Replace getOrElse null with orNull Drop redundant semicolons Replace anon fun with PF Replace anon fun with method
* Update links to docs, codehaus and citeseerJanek Bogucki2015-09-043-4/+4
| | | | | | | | | | | | | | | | | docs.scala-lang.org - Align some links to new layout for docs.scala-lang.org - Include link to concrete parallel collection performance characteristics codehaus - Subsitute a link to a JIRA email for the 404 JRUBY-3576 JIRA link in Codec.scala. jira.codehaus.org is not redirecting this. citeseer - Replace the citeseer link with a direct link to a PDF which is not behind a login challenge.
* Fix 23 typos (m-o)Janek Bogucki2015-06-281-1/+1
|
* Fix many typos in docs and commentsmpociecha2014-12-142-2/+2
| | | | | | | | | | | | | 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.
* Merge pull request #4089 from gourlaysama/wip/t6626-scaladoc-throws-linksVlad Ureche2014-11-052-4/+4
|\ | | | | SI-6626 make @throws tags create links to exceptions
| * cleanup @throws tags in library and reflectAntoine Gourlay2014-11-052-4/+4
| | | | | | | | | | - there is no need for explicit links with [[ and ]] - there is no need for explicit backquoting
* | SI-8916 Fix -Ywarn-unused-import warningsSimon Ochsenreither2014-10-241-2/+0
|/
* relaxes attachment-matching rulesEugene Burmako2014-07-101-1/+1
| | | | | | It came as a surprise recently, but attachments.contains/get/update/remove require the class of the payload to match the provided tag exactly, not taking subclassing into account. This commit fixes the oversight.
* reverses SI-6484Eugene Burmako2014-02-181-11/+1
| | | | | Unfortunately I have to revert b017629 because of SI-8303. There are projects (e.g. slick) that use typeOf in annotations, which effectively means bye-bye.
* updates deprecation hints in compatEugene Burmako2014-02-151-18/+18
| | | | | Now when we have internal.decorators, it is reasonable to advertise them to the users.
* some extension methods that I forgot to exposeEugene Burmako2014-02-151-0/+12
| | | | | Thanks, sbt. Once I'm done with sbt, I'll write up tests that ensure that I haven't forgotten anything.
* exposes scope mutation APIsEugene Burmako2014-02-151-0/+23
| | | | Also needed for async.
* SI-6785 exposes Symbol.flags, setFlag and resetFlagEugene Burmako2014-02-151-0/+12
| | | | | | | My first feeling was not to expose Symbol.flags, because that would inevitably lead to exposing more methods on FlagSet. However we do need flag manipulation in async, which is representative of advanced macros, so I'm caving in.
* exposes Symbol.setOwnerEugene Burmako2014-02-151-0/+6
| | | | Used by async.
* makes internal.decorators signatures workEugene Burmako2014-02-151-16/+17
| | | | | | After fighting with path-dependent types to express wrappee.type, I decided to take a different approach and replaced wrappee.type with parametric polymorphism.
* upgrades typingTransformEugene Burmako2014-02-151-0/+9
| | | | | typingTransform and typingTransform's atOwner now work both with solitary trees and Tree+Symbol couples.
* exposes additional TreeGen methodsEugene Burmako2014-02-151-0/+10
| | | | Agains, this is something that's needed for async.
* provides extension methods for internalEugene Burmako2014-02-151-1/+64
| | | | | | | Based on my scala/async migration experiences, I can say that having to write `setType(tree, tpe)` instead of `tree.setType(tpe)` is a major pain. That's why I think it makes sense to expose some functions in internal as extension methods.
* moves Symbol.pos to public APIEugene Burmako2014-02-151-7/+0
| | | | Seems to be useful to people, so why not expose it more widely?
* addresses pull request feedbackEugene Burmako2014-02-154-8/+12
|
* some renamingsEugene Burmako2014-02-151-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* adds internal.subpatternsEugene Burmako2014-02-141-0/+5
| | | | | | As per Denys’s request, this commit exposes the hack that we use to obtain subpatterns of UnApply nodes. This is useful when writing quasiquoting macros that do pattern matching.
* adds internal.typingTransformEugene Burmako2014-02-141-0/+47
| | | | | | | | | | | | | | | | | | | 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.
* introduces c.internalEugene Burmako2014-02-142-1/+20
| | | | | | | | | | 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!
* adds internal.changeOwnerEugene Burmako2014-02-141-0/+16
| | | | | | | | | | | | | As per Jason’s and Mark’s request, this commit introduces `changeOwner`, a facility to fixup symbol owner chains to prevent owner chain corruption in macro expansions leading to crashes in LambdaLift and GenICode. This is quite a low-level API that should only be used by expert users to get their job done. In the meanwhile we’ll be working on fixing the macro engine to automatically prevent owner chain corruption in the first place: https://groups.google.com/forum/#!topic/scala-internals/TtCTPlj_qcQ.
* adds Context.enclosingOwnerEugene Burmako2014-02-141-1/+7
| | | | | | | | | | | | | | | | | | | | 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 compatibility with 2.10.xEugene Burmako2014-02-141-0/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is just one of the possible strategies for compatibility with reflection API of 2.10.x family. Here’s the discussion: 1) Do nothing. Document the fact that we’ve organized internal APIs in a separate module and let people figure out themselves. Pros: no boilerplate on our side. Cons: potential for confusion, major upfront migration effort. 2) (This commit). Introduce a compatibility pack with a manual import. Compatibility pack lives in a separate module that has to be manually imported. People will get compilation errors when trying to compile macros using internal APIs against 2.11, but those will be quenched by a single `import compat._` import. Compatibility stubs would still produce deprecation warnings, but people can choose to ignore them to alleviate migration costs. Pros: brings attention of the users to the fact that they are using internal APIs by providing a more powerful nudge than just deprecation. Cons: even though migration effort is trivial, it is still non-zero. 3) Deprecate internal APIs in-place. Pros: zero migration effort required. Cons: those who ignore deprecations will be unaware about using internal APIs, there will be some naming conflicts between Universe.xxxType and internal.xxxType type factories.
* establishes scala.reflect.api#internalEugene Burmako2014-02-143-221/+113
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* SI-6814 adds typechecker modes to c.typecheckEugene Burmako2014-02-141-3/+31
| | | | | | | | | | | | | 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.
* SI-8194 adds Universe.symbolOf[T]Eugene Burmako2014-02-141-0/+5
| | | | | | | | | | | | | | | | A very frequent use for a result of typeOf is obtaining an underlying type symbol. Another thing that comes up occasionally at stack overflow is a request to add facilities for reification of symbols. This naturally suggests that our reflection API would benefit from a method called symbolOf that can take a term or type argument and return an underlying symbol. While an API to extract a term symbol from an expression needs some time to be designed and then implemented robustly (we don’t have untyped macros so we’ll have to account for various desugarings), meaning that we probably won’t have time for that in 2.11, a type symbol extractor seems to be a very low-hanging fruit.
* SI-6484 adds Universe.typeOf[T](x: T)Eugene Burmako2014-02-141-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a nice addition to Universe.typeOf[T], quite frequently useful for inspecting ad-hoc types. As promised by https://github.com/scala/scala/pull/1741, which represented my previous stab at adding this API, I ran into problems when trying to introduce the API naively. def typeOf[T](implicit ttag: TypeTag[T]): Type def typeOf[T: TypeTag](x: T): Type The first problem came from the fact that even though they don't look ambiguous, under certain circumstances, the couple of typeOf overloads can become ambiguous. Concretely, ambiguity happens when T <: TypeTag[T], which makes the compiler uncapable to choose an overload to typecheck `typeOf[T](<materialized>: TypeTag[T])`. Luckily, defining x as a by-name parameter fixes the problem. def typeOf[T](implicit ttag: TypeTag[T]): Type def typeOf[T: TypeTag](x: => T): Type The second problem manifested itself in reification of snippets that contained calls to typeOf. Apparently, materialized tags get rolled back by reify as products of macro expansion, becoming replaced with `implicitly[TypeTag[T]]`. Afterwards, subsequent rollback of TypeTree's strips the replacement of its type argument, producing bare `implicitly`. Back then when typeOf wasn't overloaded, this abomination typechecked and worked correctly, but now, due to some weird reason, it stopped. I have worked around this by performing the rollback on a larger scale - instead of hunting down materialized tags, this commit detects calls to typeOf and removes their implicit argument lists altogether.
* renames resetLocalAttrs to resetAttrsEugene Burmako2014-02-071-1/+1
| | | | | Now when resetAllAttrs is gone, we can use a shorter name for the one and only resetLocalAttrs.
* further limits discoverability of resetAttrsEugene Burmako2014-02-073-11/+6
| | | | | | | | | | | | | | 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.
* Optimize lookup of tree/symbol attachment search.Jason Zaugg2014-02-011-1/+4
| | | | Use `hasAttachment` rather than `getAttachment.exists`
* SI-6879 improves Context.freshNameEugene Burmako2014-01-221-11/+29
| | | | | | | | | | | 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.
* Merge pull request #3392 from xeno-by/topic/untypecheckEugene Burmako2014-01-211-6/+20
|\ | | | | deprecates resetAllAttrs and resetLocalAttrs in favor of the new API
| * deprecates resetAllAttrs and resetLocalAttrs in favor of the new APIEugene Burmako2014-01-211-6/+20
| | | | | | | | | | | | | | | | | | | | 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.
* | deprecates c.enclosingTree-style APIsEugene Burmako2014-01-163-5/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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!
* | changes bundles to be classes, not traits extending MacroEugene Burmako2014-01-122-80/+0
| | | | | | | | | | | | Adjusts bundle notation to read `class Bundle(val c: Context)` instead of `class Bundle extends Macro`. This avoids calling compileLate in the macro compiler and associated tooling problems.
* | *boxContext => *box.Context , *boxMacro => *box.MacroEugene Burmako2014-01-1215-62/+72
|/ | | | | | | | | | 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
* Removes unnecessary generality in the macro engineEugene Burmako2014-01-081-13/+0
| | | | | | | | | | 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 => typecheckEugene Burmako2013-12-101-3/+9
| | | | | 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.
* undeprecates c.parseEugene Burmako2013-12-061-3/+0
| | | | | | | | | We never thought that c.parse is going to be completely subsumed by quasiquotes, but hoped that the use cases that are going to be lost aren’t going to be noticed by anyone. Unfortunately, this isn’t the case, so I’m undeprecating c.parse until we get a better story for those for whom quasiquotes are not enough.
* Merge pull request #3129 from adriaanm/pr-rebase-3001Adriaan Moors2013-11-1315-83/+175
|\ | | | | [rebase] blackbox and whitebox macros
| * blackbox restriction #3: can't affect implicit searchEugene Burmako2013-11-123-33/+33
| | | | | | | | | | | | | | | | | | 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.
| * blackbox and whitebox macrosEugene Burmako2013-11-1215-50/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/...
* | re-implement hasAttachment directly in raw attachmentsDen Shabalin2013-11-121-0/+4
|/
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-05 03:45:52 +0000