resetallattrs | missing compatibility library for reflection in Scala | Reflection library
kandi X-RAY | resetallattrs Summary
kandi X-RAY | resetallattrs Summary
In Scala 2.10, when macros were first introduced, our public API exposed two low-level methods: Context.resetLocalAttrs and Context.resetAllAttrs. While these methods wouldn't be needed at all if our internal implementation of the macro API were more advanced, at our past level of technology we needed them (and we still do) to deal with possible inconsistencies in partially synthetic trees. Without going into details, experience has shown that resetLocalAttrs can deal with a majority of possible inconsistencies having a mild chance of corrupting trees as a side-effect of its operation, whereas resetAllAttrs can deal with some additional inconsistencies, but it's almost always guaranteed to corrupt trees. Go through our Macrology 201 tutorial to learn more about this topic. Anyway, based on what we've learned about resetAttrs methods, in Scala 2.11.0 we removed resetAllAttrs and renamed resetLocalAttrs to untypecheck, branding resetLocalAttrs as the one and only public way of fixing inconsistencies in trees. When doing that, we expected that resetLocalAttrs should be enough for virtually everyone who previously used resetAllAttrs. Unfortunately, that ended up being not the case and due to binary compatibility constraints we can't just reintroduce resetAllAttrs in 2.11.x (or even in 2.12.x, for that matter). So here we go, reinstating resetAllAttrs in a separate library for the cases when it's really necessary. Let's hope the necessity for resetAllAttrs won't last for long.
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of resetallattrs
resetallattrs Key Features
resetallattrs Examples and Code Snippets
Community Discussions
Trending Discussions on resetallattrs
QUESTION
I need to really untypecheck the trees that are emitted by my macro. That means not only removing inferred types and all that, but also removing the implicit arguments that are inferred by the compiler. Not even resetAllAttrs
seems to take care of that.
Symbol
s appear to have a method isSynthetic
that indicates whether code was generated by the compiler, but apparently that flag is only set for things like autogenerated getters and setters, not for implicit values that the compiler inserts.
I could of course manually look for all implicit argument lists and remove them, but then I will also remove the ones that were explicitly provided by the user of my macro.
So ideally for the following code
...ANSWER
Answered 2017-Jan-14 at 05:55They have internal API to detect the implicitly supplied args, but it is commented as unstable. (They'll use a tree attachment instead of a subtype of Apply.)
QUESTION
I am having trouble writing a macro that transforms a given partial function and creates a new partial function. For instance, I want to be able to decompose the given partial function into its elements - pattern binder, guard condition, and body; then I want to decompose the pattern binder and the guard condition into smaller pieces and reassemble new partial functions out of these pieces. However, I am getting strange errors at macro expansion that I can't debug.
The simplest problem that gives the same error is the code that decomposes the given partial function into the binder, the guard, and the body, and reassembles it back into the same partial function.
I can do this with a simple type PartialFunction[Int,Any]
but not with types that involve case classes, PartialFunction[MyCaseClass,Any]
.
Here is the code that works and the code that doesn't.
Working code: take a partial function, destructure it using quasiquotes, assemble the same function again, and return it.
...ANSWER
Answered 2017-Jan-09 at 13:05I believe you're hitting a long standing issue in the Scala compiler. Typechecking is not idempotent in several cases, specifically extractors using unapply
: SI-5465. There is no easy solution for this, but I can suggest two workarounds. Let me first explain the problem briefly.
Def macros are expanded during the typechecking phase. As a consequence arguments to def macros are typed trees. Returning a well-typed or untyped tree is acceptable. However, returning a partially typed (your case) or ill-typed tree is very likely to trip the compiler, causing a typechecking error at best or an error in a subsequent phase. Note that quasiquotes generate untyped trees. How can these bad trees occur?
- Partially typed trees - usually by wrapping untyped code around the typed arguments or replacing parts of them with untyped code. In many cases you can get away with those, but not always.
- Ill-typed trees - by rearranging the typed arguments in a way that invalidates the original type information, e.g. splicing one argument into another. These will surely cause a problem.
Hopefully you can see that the problem is conceptual and deeply rooted. But you can take one of two approaches to solve the problem:
The hacky solution - do a roundtrip through a String representation of the final result:
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install resetallattrs
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page