summaryrefslogtreecommitdiff
path: root/src/reflect
Commit message (Collapse)AuthorAgeFilesLines
* Address pull request feedbackDenys Shabalin2014-02-242-3/+3
|
* Add ScalaDoc to Quasiquotes and Liftables parts of apiDenys Shabalin2014-02-242-7/+58
|
* Merge pull request #3571 from xeno-by/ticket/8321Adriaan Moors2014-02-231-4/+9
|\ | | | | SI-8321 bundles can't be whitebox
| * more helpful bundle error messagesEugene Burmako2014-02-211-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | At the moment, bundle selection mechanism is pretty picky. If a candidate bundle's parameter isn't either blackbox.Context, whitebox.Context or PrefixType refinement thereof, then it's not a bundle and the user will get a generic error. However we can be a bit more helpful and admit classes that are almost like bundles (looksLikeMacroBundleType), have them fail isMacroBundleType, and then emit a much prettier error message to the user that would tell them that bundles must be monomorphic and their sole parameter should not just be any subtype of blackbox.Context or whitebox.Context.
| * prohibits polymorphic bundlesEugene Burmako2014-02-211-1/+2
| | | | | | | | | | | | It's not like they were inducing bugs, but I can't see how polymorphism can be useful for macro bundles, hence imho it's better to reduce the number of degrees of freedom of the system.
| * bundles now reject invalid context typesEugene Burmako2014-02-211-9/+5
| | | | | | | | | | Vanilla macros only allow blackbox.Context, whitebox.Context and PrefixType refinements thereof. Bundles should behave in the same way.
| * SI-8321 whitebox bundles are now recognized as suchEugene Burmako2014-02-211-2/+6
| | | | | | | | | | whitebox.Context <: blackbox.Context, so in order to check for blackboxity it's not enough to check whether the context used is <: blackbox.Context.
* | SI-8324 Fix regression in override checks for sealed classesJason Zaugg2014-02-221-1/+2
|/ | | | | | | | | | | | adeffda25 changed `Symbol#isEffectivelyFinal` to help the optimizer by inferring finality within sealed class hierarchies. However, this change wasn't neccesarily welcome for other clients of that method. In the enclosed test case, we see that overriding checks in `RefChecks` regressed. This commit moves the enhanced version into a new method and selectively uses it in the optimizer (and the tail call optimizer).
* Merge pull request #3557 from adriaanm/t8224Jason Zaugg2014-02-213-37/+34
|\ | | | | SI-8224 Fix regression in f-bound aware LUBs
| * SI-8224 Fix regression in f-bound aware LUBsJason Zaugg2014-02-183-37/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Disable the heuristic approach to recursive bounds unless the compiler is running under `-Xstrict-inference`. [the above was not authored by the original author] In db46c71e88, steps were taken to avoid blowing up in the pathological LUB calculation needed for: def trav = List(List(), Stream()) This skipped a level in the base class sequence when f-bounds were detected at the current level. In that example, when `lublist` was about to: mergePrefixAndArgs( typeOf[LinearSeqOptimized[A, List[A]]], typeOf[LinearSeqOptimized[A, Stream[A]]], ) If it proceeded (as in 2.10.3), the LUB is invalid: error: type arguments [B[_ >: D with C <: B[_ >: D with C <: A]],s.c.immutable.LinearSeq[B[_ >: D with C <: A]] with s.c.AbstractSeq[B[_ >: D with C <: A]] with s.c.LinearSeqOptimized[B[_ >: D with C <: A],s.c.immutable.LinearSeq[A] with s.c.AbstractSeq[A] with s.c.LinearSeqOptimized[A,Immutable with Equals with java.io.Serializable] with java.io.Serializable] with java.io.Serializable] do not conform to trait LinearSeqOptimized's type parameter bounds [+A,+Repr <: s.c.LinearSeqOptimized[A,Repr]] To avoid this, the added code would skip to the first non-F-bounded base type of the same arity of each element in the list. This would get to: LinearSeqLike[D, Stream[D]] LinearSeqLike[C, List[C]] which are lubbable without violating the type constraints. I don't think this was the right remedy. For starters, as seen in this bug report, SI-8224, if the list of types are identical we have let a perfectly good lub slip through our fingers, and end up calculating too general a type. More generally, if the type arguments in f-bounded positions coincide, we don't risk calculating a ill-bounded LUB. Furthermore, the code was widening each of the types separately; this isn't something we want to do within `if (isUniformFrontier)`. AFAICT this was just wasteful and as all `ts0` start with the same type symbol, so `typeConstructorList` should be uniform. This commit restricts this base-class skipping to situations where the argument inferred for an type argument that is used as an f-bound is not: a) an existential (as created by `mergePrefixAndArgs` in invariant positions.), or b) equivalent to one of the corresponding input type arguments (this is the case that fixes the regression in pos/8224.scala)
* | Merge pull request #3546 from VladimirNik/typedTreesPrinter-2.11.0Jason Zaugg2014-02-215-58/+217
|\ \ | | | | | | CodePrinter added to Printers 2.11.0
| * | fixes for wrappingIntoTermVladimirNik2014-02-201-1/+0
| | |
| * | block wrapping for trees modifiedVladimirNik2014-02-201-5/+7
| | |
| * | block processing fixed for syntactics in typechecked treesVladimirNik2014-02-203-4/+5
| | |
| * | printOwners support added to Printers; whitespaces removedVladimirNik2014-02-204-29/+32
| | |
| * | move methods for typechecked trees processing to TreeInfoVladimirNik2014-02-203-62/+65
| | |
| * | CodePrinter: TypedTreePrinter merged with ParsedTreePrinterVladimirNik2014-02-201-123/+89
| | |
| * | lazy vals printing fixed for typechecked treesVladimirNik2014-02-202-14/+20
| | |
| * | printers flag processing improvements: printRootPkg flag fixed, comments to ↵VladimirNik2014-02-201-12/+23
| | | | | | | | | | | | flags metadata printing added
| * | Attributed val/var processing for syntactics (SI-8180)VladimirNik2014-02-203-33/+201
| | | | | | | | | | | | | | | | | | TypedTreesPrinter added changes based on pull request comments: print root packages flag; tests for syntactics; SyntacticEmptyTypeTree added to Printers
* | | Merge pull request #3555 from adriaanm/rebase-3553Jason Zaugg2014-02-212-2/+3
|\ \ \ | | | | | | | | Small Predef cleanup
| * | | SI-7788 Avoid accidental shadowing of Predef.conformsAdriaan Moors2014-02-182-2/+3
| | |/ | |/| | | | | | | | | | | | | | | | Rename `conforms` to `$conforms` and put in a minimal backstop: pos/t7788.scala TODO: predicate the backwards compatibility shim for `Predef_conforms` on `-Xsource:2.10`
* | | Tweak signature for quasiquote's applyDenys Shabalin2014-02-201-1/+1
| |/ |/| | | | | | | | | Even though quasiquotes are whitebox macros their return values are in fact always trees. This might help IDEs with macro expansions turned off.
* | Merge pull request #3452 from xeno-by/topic/palladium0Jason Zaugg2014-02-1960-1648/+3248
|\ \ | |/ |/| SI-8063 and its seventy friends
| * undeprecates typeSignature and typeSignatureInEugene Burmako2014-02-181-2/+0
| | | | | | | | | | | | | | As per Jason's feedback, these are now undeprecated, being aliases for info and infoIn. I haven't touched the newly introduced setInfo family of methods, because I think that on internal level we don't need setTypeSignature anyway.
| * improves situation with auto-initEugene Burmako2014-02-182-9/+26
| | | | | | | | | | | | | | Symbol.typeSignature and Symbol.typeSignatureIn no longer auto-init. Neither does Symbol.toString (something that I introduced a few commits ago). However Type.toString still does, and that should be enough to get robust prettyprinting with minimal risk. Details are in comments.
| * makes sure compat._ provides full compatibility with 2.10.xEugene Burmako2014-02-183-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is extremely important to enable cross-versioning Scala 2.10 codebases against Scala 2.11 using Jason's trick with: // TODO 2.11 Remove this after dropping 2.10.x support. private object HasCompat { val compat = ??? }; import HasCompat._ def impl(c: Context)(...): ... = { import c.universe._ import compat._ ... }
| * reverses SI-6484Eugene Burmako2014-02-183-27/+3
| | | | | | | | | | 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.
| * Merge remote-tracking branch 'retronym/topic/8301' into topic/palladium0Eugene Burmako2014-02-182-5/+5
| |\
| * \ Merge remote-tracking branch 'origin/master' into topic/palladium0Eugene Burmako2014-02-172-4/+9
| |\ \
| * | | better deprecation message for Symbol.companionSymbolEugene Burmako2014-02-161-1/+1
| | | |
| * | | Merge remote-tracking branch 'origin/master' into topic/palladium0Eugene Burmako2014-02-1613-103/+210
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | | | adds missing signature of appliedTypeEugene Burmako2014-02-152-0/+6
| | | | | | | | | | | | | | | | | | | | Again, thanks to sbt.
| * | | | updates deprecation hints in compatEugene Burmako2014-02-152-35/+35
| | | | | | | | | | | | | | | | | | | | | | | | | 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-153-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | Thanks, sbt. Once I'm done with sbt, I'll write up tests that ensure that I haven't forgotten anything.
| * | | | fixes compat for tree and type extractorsEugene Burmako2014-02-154-219/+169
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When I removed XXXDef(...) and XXXType(...) methods from the public API, I put compatibility stubs in compat via implicit classes enriching XXXExtractor traits with apply methods. Unfortunately, this doesn't work, because if XXXDef or XXXType have any kind of an apply method left in the public API, then implicit classes won't even be considered when resolving calls to XXXDef(...) or XXXType(...). Therefore I had to put those removed methods back and adorn them with an implicit parameter that can only be resolved when "import compat._" is in place. Quite extravagant, yes, but goes along the lines with the design goals of the refactoring, which are: 1) Break source compatibility for users who are using methods that are now moved to internal in order to attract attention. 2) Provide an easy way to fix the breakage by importing compat._, which will pimp back all the missing APIs with deprecation warnings that are going to guide migration.
| * | | | exposes scope mutation APIsEugene Burmako2014-02-153-1/+27
| | | | | | | | | | | | | | | | | | | | Also needed for async.
| * | | | SI-6785 exposes Symbol.flags, setFlag and resetFlagEugene Burmako2014-02-153-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-152-0/+7
| | | | | | | | | | | | | | | | | | | | Used by async.
| * | | | better appliedType signaturesEugene Burmako2014-02-152-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | Our users deserve better than this mouthful: `appliedType(sym.asType.toTypeConstructor, List(targ1, ...))`
| * | | | makes internal.decorators signatures workEugene Burmako2014-02-153-34/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-153-0/+18
| | | | | | | | | | | | | | | | | | | | Agains, this is something that's needed for async.
| * | | | introduces Flag.STABLEEugene Burmako2014-02-152-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Used in async when lifting definitions used in multiple states of the async state machine. These definitions need to be lifted to class members of the state machine.
| * | | | staticXXX now throw ScalaReflectionExceptionEugene Burmako2014-02-155-16/+15
| | | | | | | | | | | | | | | | | | | | | | | | | Previously this was scala.reflect.internal.MissingRequirementError, but that's not good enough for the public API.
| * | | | provides extension methods for internalEugene Burmako2014-02-153-2/+171
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | addresses pull request feedbackEugene Burmako2014-02-151-6/+6
| | | | |
| * | | | Type.companionType => Type.companionEugene Burmako2014-02-152-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | I think that the "type" suffix here is redundant, so let's rename this API to reduce the annoyance potential.
| * | | | addresses pull request feedbackEugene Burmako2014-02-152-34/+57
| | | | |
| * | | | renames some methods in ReificationSupportEugene Burmako2014-02-153-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.