summaryrefslogtreecommitdiff
path: root/src/reflect/scala/reflect/api/Symbols.scala
Commit message (Collapse)AuthorAgeFilesLines
* Lower-case spelling of @deprecated messagesSimon Ochsenreither2016-05-281-6/+6
|
* Remove references to trait impl classes, mostly in doc commentsLukas Rytz2016-04-071-5/+1
|
* Query methods in api.Symbols for Java flagsLukas Rytz2015-07-221-0/+12
| | | | | | | | | | | | | | | | | | | Adds query methods to the public reflection API for querying the JAVA_ENUM and JAVA_ANNOTATION flags. Didn't include JAVA_DEFAULTMETHOD because it does not correspond to a real java classfile flag (just a non-abstract method in an interface), and we want to clean the usage of this flag before adding it to a public API. The flags themselfs are not added to the reflection API. A comment in api/FlagSets.scala says: Q: I have a pretty flag. Can I put it here? A: Only if there's a tree that cannot be built without it. If you want to put a flag here so that it can be tested against, introduce an `isXXX` method in one of the api.Symbols classes instead.
* Move a Scaladoc sentence to the correct methodAlexey Romanov2015-05-161-11/+12
| | | `paramLists` name doesn't end in `ss`, so that sentence belongs to `paramss`. Also a few punctuation fixes.
* Fix many typos in docs and commentsmpociecha2014-12-141-1/+1
| | | | | | | | | | | | | 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.
* Update ScalaDoc code examples not to use deprecated constructsLukasz Piepiora2014-11-261-1/+1
| | | | | - Replace newTermName in favour of TermName - Replace newTypeName in favour of TypeName
* Documentation for isModuleClassLukas Rytz2014-07-081-0/+3
|
* SI-8367 revert SI-8192's change to primaryConstructor when isJavaDefinedAdriaan Moors2014-03-071-0/+8
| | | | this is some weird stuff
* 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.
* better deprecation message for Symbol.companionSymbolEugene Burmako2014-02-161-1/+1
|
* SI-7044 deprecates Symbol.associatedFileEugene Burmako2014-02-151-0/+1
| | | | | | | | | | | | | | | | | | | | 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-151-0/+3
| | | | Seems to be useful to people, so why not expose it more widely?
* some renamingsEugene Burmako2014-02-151-16/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 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.
* establishes scala.reflect.api#internalEugene Burmako2014-02-141-108/+6
| | | | | | | | | | | | | | | | | | | | | | | | | 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-6732 deprecates internal#Symbol.isPackageEugene Burmako2014-02-141-1/+1
| | | | | | | | 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).
* SI-6441 removes Symbol.isOverrideEugene Burmako2014-02-141-6/+0
| | | | | | | | | | | | | | | | `Symbol.isOverride` joins `Symbol.isLocal` in the unfortunate family of methods for which we had to break source compatibility because of their utter brokenness. Apparently, `isOverride` only returns true for those symbols that have the OVERRIDE flag set (i.e. the ones that are derived from source definitions that have the `override` modifier specified next to them). Of course, this is very confusing, and that’s exacerbated by the fact that we can’t fix this behavior, because there’s `internal#Symbol.isOverride` that someone might rely on. Given that there’s perfectly working `Symbol.allOverriddenSymbols`, this commit removes the `Symbol.isOverride` API altogether.
* sane semantics for Symbols.companionSymbolEugene Burmako2014-02-141-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While playing with tests for Type.companionType, I figured out that companionSymbol isn’t what it seems to be: scala> ScalaPackage.companionSymbol res5: $r.intp.global.Symbol = <none> scala> ScalaPackageClass.companionSymbol res6: $r.intp.global.Symbol = package scala Or even funnier observation: scala> class C; object C defined class C defined object C scala> val classC = typeOf[C].typeSymbol classC: $r.intp.global.Symbol = class C scala> val moduleC = classC.companionSymbol moduleC: $r.intp.global.Symbol = object C scala> classC.companionSymbol == moduleC res0: Boolean = true scala> moduleC.companionSymbol == classC res1: Boolean = true scala> moduleC.moduleClass.companionSymbol == moduleC res2: Boolean = true Of course, I rushed to clean this up, so that `companionSymbol` only returns something other than NoSymbol if the target has a companion in the common sense, not wrt the internal “class with the same name in the same package” convention of scalac, and that `companionSymbol` for module classes is a class, not a source module. Unfortunately it’s not that easy, because api.Symbol#companionSymbol has the same name as internal.Symbol#companionSymbol, so we can’t change the behavior of the former without changing the behavior of the latter. Therefore I deprecated api.Symbol#companionSymbol and introduced a replacement called api.Symbol#companion with sane semantics.
* SI-8192 adds ClassSymbol.isPrimaryConstructorEugene Burmako2014-02-141-0/+13
| | | | | | | | | | | | | | | | | | | | | Exposes a popular code pattern in macros as a dedicated reflection API. This simple commit, however, ended up being not so simple, as it often happens with our compiler. When writing a test for the new API, I realized that our (pre-existing) MethodSymbol.isPrimaryConstructor API returns nonsensical results for implementation artifacts (trait mixin ctors, module class ctors). What’s even more funny is that according to our reflection internals, even Java classes have primary constructors. Well, that’s not surprising, because `primaryConstructor` is just `decl(ctorName).alternatives.head`. Good thing that package classes don’t have constructors or that would elevate the situation to three fries short of a happy meal. At the moment, I’m too scared to fiddle with internal#Symbol.primaryConstructor, because that could easily break someone right before RC1, so I simply documented the findings in SI-8193 and postponed the actual work, except for one thing - isJavaDefined symbols no longer have primary constructors.
* SI-6379 adds MethodSymbol.exceptionEugene Burmako2014-02-141-0/+8
| | | | | | Following Simon’s request, this commit introduces a dedicated API that can be used to acquire the list of exceptions thrown by a method, abstracting away from whether it’s a Java or a Scala artifact.
* SI-8190 erasure identities for types in reflection APIEugene Burmako2014-02-141-8/+8
| | | | | | | | | | | Makes sure that almost every abstract type declared in reflection API erases to a unique class, so that they can be adequately used for method overloading to the same extent that tags allow them to be used in pattern matching. The only two exceptions from this rule are the types whose implementations we do not control: FlagSet that is implemented as Long and RuntimeClass that is implemented as java.lang.Class[_].
* SI-8187 api#Symbol.name now has precise typeEugene Burmako2014-02-141-1/+1
| | | | | | | I don’t remember why we didn’t have written it as `def name: NameType` in the first place (probably because of path-dependent bugs that were popping up every now and then when we were developing the first version of reflection API), but now there are definitely no obstacles to that.
* SI-6733 LOCAL, isLocal, and private[this]Eugene Burmako2014-02-121-8/+13
| | | | | | | | | | | | | | | | Due to an unfortunate name collision, internal.Symbols#Symbol.isLocal means something different from Flag.LOCAL. Therefore api.Symbols#Symbol.isLocal was directly violating its documentation. Since we can’t give api#isLocal an implementation different from internal#isLocal, we have to rename, and for that occasion I have come up with names api#isPrivateThis and api#isProtectedThis, which in my opinion suits the public API better than internal#isPrivateLocal and internal#isProtectedLocal. Given the extraordinary circumstances of having no way for api#isLocal to work correctly, I’m forced to remove api#isLocal without a deprecation notice, exercising our right to break experimental APIs, something that we have never done before for reflection or macros. This is sad.
* SI-7533 Adds Symbol.isAbstractEugene Burmako2014-02-121-0/+8
| | | | | | | Amazingly enough, we've missed the fact that non-type symbols can also be abstract. Having been enlightened by this, I'm exposing isDeferred and merging it along with isAbstractType and isAbstractClass into the unified Symbol.isAbstract method.
* Absolutized paths involving the scala package.Paul Phillips2013-05-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Confusing, now-it-happens now-it-doesn't mysteries lurk in the darkness. When scala packages are declared like this: package scala.collection.mutable Then paths relative to scala can easily be broken via the unlucky presence of an empty (or nonempty) directory. Example: // a.scala package scala.foo class Bar { new util.Random } % scalac ./a.scala % mkdir util % scalac ./a.scala ./a.scala:4: error: type Random is not a member of package util new util.Random ^ one error found There are two ways to play defense against this: - don't use relative paths; okay sometimes, less so others - don't "opt out" of the scala package This commit mostly pursues the latter, with occasional doses of the former. I created a scratch directory containing these empty directories: actors annotation ant api asm beans cmd collection compat concurrent control convert docutil dtd duration event factory forkjoin generic hashing immutable impl include internal io logging macros man1 matching math meta model mutable nsc parallel parsing partest persistent process pull ref reflect reify remote runtime scalap scheduler script swing sys text threadpool tools transform unchecked util xml I stopped when I could compile the main src directories even with all those empties on my classpath.
* Reduce visibility of implicit class tags.Paul Phillips2013-04-081-48/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | 500 lines of generated boilerplate is *impossible to maintain*. Generated code of this kind should never be allowed. Three lines of documentation, duplicated 100 times, cannot masquerade as three hundred lines of documentation. If someone knows to look at the documentation of implicit ClassTags, they *already know* about implicit ClassTags. It is wherever "match" is documented which needs this information (and I am sure we can express it more clearly, given the luxury of only saying it once.) Documenting each ClassTag with the same boilerplate is comparable in utility to attaching such text to every Int. "An Int is a whole number within the range -2147483648 to 2147483647 inclusive. It's usually used to represent how many of something there are, such as '5 bunnies' or '3 witty commit messages', but you can store about anything in an Int if you can fit it into 32 bits." We don't do that, because you're expected to discover what an Int is in a manner which generalizes to all the Ints you may encounter. The situation with implicit ClassTags is immediately analogous.
* Merge remote-tracking branch 'origin/2.10.x' into masterPaul Phillips2013-02-231-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | * origin/2.10.x: SI-7171 Consider prefix when assessing type finality. please ant with filenames, add comments Fixed error in reflection API docs about linearization order on method baseClasses Shadowed Implict typo (fixes no issue) remove unused imports Conflicts: src/reflect/scala/reflect/internal/Types.scala
| * Fixed error in reflection API docs about linearization order on method ↵Heather Miller2013-02-191-1/+1
| | | | | | | | baseClasses
* | Fix scaladoc typo for isTerm methodDmitry Bushev2012-12-201-1/+1
|/
* SI-6132 Revisited, cleaned-up, links fixed, spelling errors fixed, rewordingsHeather Miller2012-11-021-3/+32
|
* Labeling scala.reflect and scala.reflect.macros experimental in the API docsHeather Miller2012-11-021-1/+4
| | | | | - Added the labels across scala.reflect and scala.reflect.macros - Added the styling in template.css that is used by all labels
* Moved @contentDiagram in SymbolsVlad Ureche2012-10-111-2/+2
|
* Diagram tweakingVlad Ureche2012-10-111-1/+3
| | | | blocked by SI-6511
* fixes a typoEugene Burmako2012-10-111-1/+1
|
* scala.reflect.api.Symbols documentationVlad Ureche2012-10-111-50/+330
| | | | Oh those pretty groups, u gotta luv'em...
* Symbols docs cleanup, mostly moved to guideingoem2012-10-111-198/+32
|
* Rearranged some reflection docs, moving things to the guideingoem2012-10-111-5/+6
|
* docs for reflection and macrosEugene Burmako2012-10-111-14/+229
|
* MethodSymbol.params => MethodSymbol.paramssEugene Burmako2012-10-071-1/+2
| | | | | | | | This matter was discussed at scala-internals: http://groups.google.com/group/scala-internals/browse_thread/thread/6414d200cf31c357 And I am convinced with Paul's argument: consistency of the convention is very important.
* MirrorOf => MirrorEugene Burmako2012-09-271-3/+3
| | | | | The name looks weird in the scaladoc overview panel, so I decided to do a last-minute rename.
* no longer docs scala.reflect.ioEugene Burmako2012-09-271-0/+4
| | | | | | | | | The only place we use something from scala.reflect.io in the public API is Symbol.associatedFile, so I've excluded scala.reflect.io from scaladoc and added a "warning: experimental" comment to associatedFile instead. I'd argue that this greatly simplifies the surface of reflection API (typing scala.reflect in the search bar now yields 3 packages instead of 4).
* SI-6277 fixes flags, annotations & privateWithinEugene Burmako2012-09-261-16/+1
| | | | | | | | | | | | | | | | | | `Symbol.getFlag`, 'Symbol.hasFlag`, `Symbol.hasAllFlags`, `Symbol.annotations` and `Symbol.privateWithin` now trigger automatic initialization of symbols if they are used in a runtime reflection universe and some other conditions are met (see `Symbol.needsInitialize` for details). As the performance testing in https://github.com/scala/scala/pull/1380 shows, this commit introduces a ~2% performance regression of compilation speed. Unfortunately all known solutions to the bug at hand (A, B & C - all of those) introduce perf regressions (see the pull request linked above for details). However we're under severe time pressure, so there's no more time to explore. Therefore I suggest this is reasonable to accept this performance hit, because we've just gained 6% from removing scala.reflect.base, and even before that we were well within our performance goal for 2.10.0-final.
* Merge pull request #1344 from jsuereth/wip/osgi-supportEugene Burmako2012-09-201-1/+1
|\ | | | | Fixes SI-5822 & SI-6305 - OSGi tests + fixes
| * Fixes SI-6305 scala.tools.nsc.io split between jars.Josh Suereth2012-09-181-1/+1
| | | | | | | | | | | | | | * migrates scala.tools.nsc.io portions into scala.reflect.io * marks all classes in scala.reflect.io experimental/internal * rewires src/reflect to use new io locations * creates forwarders in scala.tools.nsci.io package object.
* | SI-6363 removes scala.reflect.baseEugene Burmako2012-09-191-18/+272
|/ | | | | As the experience has shown, there's no need for a separate layer of reflection in scala-library.jar. Therefore I'm putting an end to it.
* moves isImplicit from TermSymbol to SymbolEugene Burmako2012-09-161-4/+4
| | | | Because classes can also be implicit.
* SI-6360 revises naming of AnnotationInfo and its membersEugene Burmako2012-09-151-2/+2
| | | | | | | | | Internal face of AnnotationInfos is bound by backward compatibility with compiler plugins and possibly SBT, but the public face can be shaped in whatever fashion we like. Hence I cleaned up the names: AnnotationInfo itself got renamed to just Annotation, AnnotArgs got renamed to just Arguments and so on.
* SI-6365 removes Symbol.hasAnnotation from the APIEugene Burmako2012-09-141-5/+0
| | | | It's clearly redundant and also is susceptible to initialize-based bugs.
* removes isLocatable from the public APIEugene Burmako2012-09-061-12/+0
| | | | | | Hard to come up with a good name, would need extensive documentation to justify its purpose => no go. If necessary we can always reintroduce it later in 2.10.1.
* Merge pull request #1202 from scalamacros/topic/reflectionPaul Phillips2012-09-021-6/+30
|\ | | | | further polishing of reflection
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-19 00:51:07 +0000