summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* adds missing signature of appliedTypeEugene Burmako2014-02-152-0/+6
| | | | Again, thanks to sbt.
* adds more tests for enclosingOwnersEugene Burmako2014-02-156-0/+106
| | | | | Makes sure that it's possible to cover sbt's use cases, and also checks that we can distinguish vals from vars (should anyone ever need that).
* 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-156-225/+175
| | | | | | | | | | | | | | | | | | | | | 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-152-0/+15
| | | | | typingTransform and typingTransform's atOwner now work both with solitary trees and Tree+Symbol couples.
* exposes additional TreeGen methodsEugene Burmako2014-02-154-1/+19
| | | | 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-153-11/+11
| | | | | 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-1510-28/+32
| | | | | | | | | 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.
* SI-7044 deprecates Symbol.associatedFileEugene Burmako2014-02-158-2/+145
| | | | | | | | | | | | | | | | | | | | Before this commit, Symbol.associatedFile used to be broken in two ways. Firstly, it was never autoloaded (just like we used to have flags, privateWithin and annotations). Secondly, it was never filled in by runtime reflection. My first attempt at fixing those problems was, well, just fixing them. However, its runtime implementation was based on a hacky function that we were not very much excited about supported (see comments), whereas its compile-time usefulness was somewhat questionable. Therefore the second attempt at fixing this bug is deprecating the API altogether, replacing it with `Symbol.pos.source`. Since `Symbol.pos` isn't retained for runtime consumption, `Symbol.pos.source` is still going to return `NoAbstractFile` as before this commit, but that's left for future work, and suggested approach is documented in SI-8259.
* moves Symbol.pos to public APIEugene Burmako2014-02-153-8/+3
| | | | Seems to be useful to people, so why not expose it more widely?
* addresses pull request feedbackEugene Burmako2014-02-1514-21/+30
|
* some renamingsEugene Burmako2014-02-15148-362/+413
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-144-3/+9
| | | | | | 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-142-1/+78
| | | | | | | | | | | | | | | | | | | 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-144-2/+31
| | | | | | | | | | 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-142-0/+30
| | | | | | | | | | | | | 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-144-9/+24
| | | | | | | | | | | | | | | | | | | | 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.
* adds initialize and fullyInitializeEugene Burmako2014-02-142-0/+21
| | | | | | | | | As per Paul’s request, this commit introduces facilities to force initialization of reflection artifacts. Sure, initialize (actually, even fullyInitialize) is silently performed by Symbol.typeSignature for runtime reflection, but people don’t have to know about that.
* adds Symbol.alternativesEugene Burmako2014-02-141-6/+6
| | | | | As per Jason’s additional request, this commit exposes alternatives in the base Symbol type, rather than only in TermSymbol.
* reflection API compatibility with 2.10.xEugene Burmako2014-02-145-1/+396
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1476-2094/+2254
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* cleans up Trees a little bitEugene Burmako2014-02-142-7/+25
| | | | | Adds some clarifications to docs, introduces personally long-awaited treeCopy.RefTree that lets us deal with RefTrees in a fully uniform fashion.
* deprecates api#Name.decoded and api#Name.encodedEugene Burmako2014-02-142-1/+3
| | | | | | | | | | | Presence of both decoded/encoded and decodedName/encodedName has always baffled me, as one of those method groups is clearly redundant, and this pull request presents a great opportunity to address this by deprecating one of the groups. After some deliberation, I’ve chosen decoded/encoded as the deprecation target, because its derivation from decodedName/encodedName is easier than the other way around.
* deprecates String => Name implicit conversionsEugene Burmako2014-02-149-14/+16
| | | | | | | Given that in 2.11 we have upgraded our name construction facility from `newTxxxName` to `TxxxName`, I think it’s time we retire these implicit conversions, as they no longer save keystrokes, but continue to present ambient danger associated with implicit conversions.
* SI-6732 deprecates internal#Symbol.isPackageEugene Burmako2014-02-1421-41/+57
| | | | | | | | This is the first step in disentangling api#Symbol.isPackage, which is supposed to return false for package classes, and internal#Symbol.isPackage, which has traditionally being used as a synonym for hasPackageFlag and hence returned true for package classes (unlike isModule which is false for module classes).
* Merge remote-tracking branch 'origin/master' into topic/palladium0Eugene Burmako2014-02-1499-327/+1057
|\
| * Merge pull request #3531 from Ichoran/issue/8188Adriaan Moors2014-02-142-2/+27
| |\ | | | | | | SI-8188 NPE during deserialization of TrieMap
| | * SI-8188 NPE during deserialization of TrieMapRex Kerr2014-02-142-2/+27
| | | | | | | | | | | | The writer was using the constructor headf and ef instead of the internal vars hashingobj and equalityobj.
| * | Merge pull request #3530 from Ichoran/issue/6632Adriaan Moors2014-02-143-19/+17
| |\ \ | | | | | | | | SI-6632 ListBuffer's updated accepts negative positions
| | * | SI-6632 ListBuffer's updated accepts negative positionsRex Kerr2014-02-133-19/+17
| | |/ | | | | | | | | | | | | | | | Changed the behavior in SeqLike.updated (which would silently accept negatives and throw on empty.tail) to throw IndexOutOfBoundException. Updated tests to verify the behavior in ListBuffer. Everything else SeqLike will come along for the ride.
| * | Merge pull request #3525 from adriaanm/t8177bAdriaan Moors2014-02-1415-50/+168
| |\ \ | | | | | | | | SI-8177 specializeSym must use memberInfo on high side
| | * | SI-8177 tidy up in type reificationEugene Burmako2014-02-147-8/+13
| | | |
| | * | SI-8177 specializeSym must use memberInfo on high sideAdriaan Moors2014-02-1312-47/+160
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When determining whether member `symLo` of `tpLo` has a stronger type than member `symHi` of `tpHi`, should we use memberType or memberInfo? Well, memberType transforms (using `asSeenFrom`) `sym.tpe`, whereas memberInfo performs the same transform on `sym.info`. For term symbols, this ends up being the same thing (`sym.tpe == sym.info`). For type symbols, however, the `.info` of an abstract type member is defined by its bounds, whereas its `.tpe` is a `TypeRef` to that type symbol, so that `sym.tpe <:< sym.info`, but not the other way around. Thus, for the strongest (correct) result, we should use `memberType` on the low side. On the high side, we should use the result appropriate for the right side of the `<:<` above (`memberInfo`). I also optimized the method a little bit by avoiding calling memberType if the symbol on the high side isn't eligble (e.g., it's a class). PS: I had to add a workaround to reifyType, because we now dealias a little less eagerly, which means a type selection on refinement class symbols makes it to reify this broke the t8104 tests. I also had to update the run/t6992 test, which should now test the right thing. Tests should be commented and/or use sensible names. What is it testing? What is the expected outcome? We should not be left guessing.
| * | Merge pull request #3376 from Ichoran/issue/8153Adriaan Moors2014-02-144-21/+51
| |\ \ | | | | | | | | SI-8153 Mutation is hard, let's go shopping with an empty list
| | * | SI-8153 Mutation is hard, let's go shopping with an empty listRex Kerr2014-02-124-21/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Changed the implementation of iterator to be more robust to mutation of the underlying ListBuffer. Added a test to make sure bug is gone. Fixed an "unsafe" usage of ListBuffer.iterator in the compiler, and added a comment explaining the (new) policy for iterating over a changing ListBuffer. The compiler now uses a synchronized-wrapped ArrayBuffer instead of ListBuffer, as that makes the (custom) units Iterator more natural to write (and avoids O(n) lookups).
| * | | Merge pull request #3526 from retronym/ticket/1786-cycleGrzegorz Kossakowski2014-02-141-0/+57
| |\ \ \ | | | | | | | | | | SI-8276 Test for cyclic error caused by (reverted) SI-1786 fix
| | * | | SI-8276 Test for cyclic error caused by (reverted) SI-1786 fixJason Zaugg2014-02-131-0/+57
| | | |/ | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We reverted SI-1786 recently on the grounds that its means of avoiding cycles (not sharpening bounds of T[_] when T is uninitialized) caused unacceptable non-determinism (well: compilation order dependency) to type inference. Nary a day later, @gkossakowski hit a regression in scala-io. Bisection revealed that it stopped working in 2dbd17a2 and started working agiain after the revert. How's that for prescience! I've distilled the cyclic error in scala-io in this test case. I'm yet to pinpoint this, followon error, which didn't survive the shrink ray, and only appeared in the original code: error: java.lang.IndexOutOfBoundsException: 0 at scala.collection.LinearSeqOptimized$class.apply(LinearSeqOptimized.scala:51) at scala.collection.immutable.List.apply(List.scala:83) at scala.reflect.internal.tpe.TypeMaps$AsSeenFromMap.correspondingTypeArgument(TypeMaps.scala:5
| * | | Merge pull request #3524 from paulp/pr/8280Adriaan Moors2014-02-133-1/+95
| |\ \ \ | | |/ / | |/| | SI-8280 regression in implicit selection.
| | * | SI-8280 regression in implicit selection.Paul Phillips2014-02-133-1/+95
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 2fa2db7840 I fixed a bug where applicable implicit conversions would not be found for numeric types if one introduced any aliasing or singleton types, for the usual reasons involving the absence of uniform type normalization. See pos/t7228 for examples - that test case has 20 errors in 2.10.3 but compiles in master. An unintended side effect was making implicit search less oblivious. It turns out that in so doing I had created ambiguity where there was none before. Not because it was any more ambiguous, but because the compiler now had the wits to notice the ambiguity at an earlier time. The fix for this is not intuitive. The way the internal logic is, we need to keep the wool over implicit search's eyes, which leads to those unrecognized types being passed to adapt, where they are recognized and weak subtyping suffices to be more specific. It is sufficient for SI-7228 that weak subtyping be done correctly - the other change, which is reverted here, was exposing the type arguments of Function1 when a view exists as a subtype of Function1. It is also possible this could be remedied by calling weak_<:< somewhere which is presently <:<, but I don't know where and it has a far greater chance of affecting something else than does this, which is a straight reversion of a post-2.10.3 change.
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-20 04:42:19 +0000