summaryrefslogtreecommitdiff
path: root/src/library/scala/annotation
Commit message (Collapse)AuthorAgeFilesLines
* Remove unused imports and other minor cleanupsSimon Ochsenreither2015-12-182-6/+2
| | | | | | | | | | - Language imports are preceding other imports - Deleted empty file: InlineErasure - Removed some unused private[parallel] methods in scala/collection/parallel/package.scala This removes hundreds of warnings when compiling with "-Xlint -Ywarn-dead-code -Ywarn-unused -Ywarn-unused-import".
* Minor fixes to Scaladoc of implicitAmbiguousLukas Rytz2015-10-061-7/+7
|
* SI-6806 Add an @implicitAmbiguous annotationBrian McKenna2015-08-111-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Example usage: trait =!=[C, D] implicit def neq[E, F] : E =!= F = null @annotation.implicitAmbiguous("Could not prove ${J} =!= ${J}") implicit def neqAmbig1[G, H, J] : J =!= J = null implicit def neqAmbig2[I] : I =!= I = null implicitly[Int =!= Int] Which gives the following error: implicit-ambiguous.scala:9: error: Could not prove Int =!= Int implicitly[Int =!= Int] ^ Better than what was previously given: implicit-ambiguous.scala:9: error: ambiguous implicit values: both method neqAmbig1 in object Test of type [G, H, J]=> Main.$anon.Test.=!=[J,J] and method neqAmbig2 in object Test of type [I]=> Main.$anon.Test.=!=[I,I] match expected type Main.$anon.Test.=!=[Int,Int] implicitly[Int =!= Int] ^
* SI-8731 don't issue a @switch warning for two-case matchesLukas Rytz2015-03-311-0/+3
| | | | | | This allows annotating small pattern matches with `@switch` without getting any warnings. There's no reason to warn, the performance of the generated bytecode is good.
* Remove deprecated constructor from the migration annotationJames Iry2013-11-181-4/+1
| | | | | | | The migration annotation had a deprecated 2 arg constructor that was deprecated in 2.10.0. This commit removes that constructor. Because migration is private to the scala package this change shouldn’t affect the rest of the community.
* Describe type parameter interpolation in @implicitNotFound documentationCody Allen2013-10-031-2/+5
| | | | | | Using this feature is necessary for helpful error messages, so it should be documented. Thank you to @adriaanm for recommending the this description.
* Cull extraneous whitespace.Paul Phillips2013-09-181-1/+1
| | | | | | | | | | | | | | | | | | | | | One last flurry with the broom before I leave you slobs to code in your own filth. Eliminated all the trailing whitespace I could manage, with special prejudice reserved for the test cases which depended on the preservation of trailing whitespace. Was reminded I cannot figure out how to eliminate the trailing space on the "scala> " prompt in repl transcripts. At least reduced the number of such empty prompts by trimming transcript code on the way in. Routed ConsoleReporter's "printMessage" through a trailing whitespace stripping method which might help futureproof against the future of whitespace diseases. Deleted the up-to-40 lines of trailing whitespace found in various library files. It seems like only yesterday we performed whitespace surgery on the whole repo. Clearly it doesn't stick very well. I suggest it would work better to enforce a few requirements on the way in.
* moves compileTimeOnly to scala-libraryEugene Burmako2013-08-141-0/+22
| | | | | | | | | This is the notion that's come to be universally useful, so I suggest we promote it to be universally accessible. Note that the attached test incorrectly fails to report errors for definitions coming from the empty package and for annotations. These are bugs, and they are fixed in subsequent commits of this pull request.
* SI-6811 Remove scala.annotation.cloneableSimon Ochsenreither2013-06-071-15/+0
|
* Merge commit 'b403234a27' into wip/fresh-merge2Paul Phillips2013-02-011-1/+2
|\ | | | | | | | | | | | | | | Conflicts: src/compiler/scala/tools/nsc/matching/ParallelMatching.scala src/compiler/scala/tools/nsc/transform/ExplicitOuter.scala src/compiler/scala/tools/nsc/typechecker/NamesDefaults.scala test/files/neg/t6963.check
| * SI-6963 Add version to -XmigrationJames Iry2013-01-291-1/+2
| | | | | | | | | | | | | | | | | | Adds an optional version parameter to the -Xmigration compiler setting. Doing -Xmigration without version number behaves as it used to by dumping every possible migration warning. This commit adds a ScalaVersion class (plus ancillary stuff), and a ScalaVersionSetting.
* | SI-6811 Remove the scala.annotation.target packageSimon Ochsenreither2013-01-171-29/+0
| |
* | SI-6811 Remove scala.annotation.serializableSimon Ochsenreither2013-01-171-15/+0
|/ | | | | Every usage of it has been eliminated in earlier commits, so the source file can finally be removed, too.
* Brings all copyrights (in comments) up-to-date, from 2011/12 to 2013Heather Miller2012-11-0228-28/+28
|
* SI-6453 Documentation links for @switch are brokenHeather Miller2012-10-101-2/+1
|
* Fix incomplete version strings (2.10 -> 2.10.0)Simon Ochsenreither2012-09-291-1/+1
|
* Remove `@static` annotation from the library.Grzegorz Kossakowski2012-09-181-20/+0
| | | | It's a follow-up commit on 4bfcadabae7663e4329f5a4b21a9368477a7e3e3.
* Eliminate breaking relative names in source.Paul Phillips2012-09-1423-29/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These things are killing me. Constructions like package scala.foo.bar.baz import foo.Other DO NOT WORK in general. Such files are not really in the "scala" package, because it is not declared package scala package foo.bar.baz And there is a second problem: using a relative path name means compilation will fail in the presence of a directory of the same name, e.g. % mkdir reflect % scalac src/reflect/scala/reflect/internal/util/Position.scala src/reflect/scala/reflect/internal/util/Position.scala:9: error: object ClassTag is not a member of package reflect import reflect.ClassTag ^ src/reflect/scala/reflect/internal/util/Position.scala:10: error: object base is not a member of package reflect import reflect.base.Attachments ^ As a rule, do not use relative package paths unless you have explicitly imported the path to which you think you are relative. Better yet, don't use them at all. Unfortunately they mostly work because scala variously thinks everything scala.* is in the scala package and/or because you usually aren't bootstrapping and it falls through to an existing version of the class already on the classpath. Making the paths explicit is not a complete solution - in particular, we remain enormously vulnerable to any directory or package called "scala" which isn't ours - but it greatly limts the severity of the problem.
* Implement @static annotation on singleton object fields.Aleksandar Prokopec2012-07-181-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit introduces the `@static` annotation on fields of static singleton objects. A static singleton object is a top-level singleton object or an object nested within a static singleton object. The field annotated with `@static` is generated as a true static field in the companion class of the object. The initialization of the field is done in the static initializer of the companion class, instead of the object itself. Here's an example. This: object Foo { @static val FIELD = 123 } class Foo generates : object Foo { def FIELD(): Int = Foo.FIELD } class Foo { <static> val FIELD = 123 } The accessor in `object Foo` is changed to return the static field in `class Foo` (the companion class is generated if it is not already present, and the same is done for getters if `FIELD` is a `var`). Furthermore, all the callsites to accessor `Foo.FIELD` are rewritten to access the static field directly. It is illegal to annotate a field in the singleton object as `@static` if there is already a member of the same name in `class Foo`. This allows better Java interoperability with frameworks which rely on static fields being present in the class. The `AtomicReferenceFieldUpdater`s are one such example. Instead of having a Java base class holding the `volatile` mutable field `f` and a static field containing a reference to the `AtomicReferenceFieldUpdater` that mutates `f` atomically, and extending this Java base class from Scala, we can now simply do: object Foo { @static val arfu = AtomicReferenceUpdater.newUpdater( classOf[Foo], classOf[String], "f" ) } class Foo { @volatile var f = null import Foo._ def CAS(ov: String, nv: String) = arfu.compareAndSet(this, null, "") } In summary, this commit introduces the following: - adds the `@static` annotation - for objects without a companion class and `@static` members, creates a companion class (this is done in `CleanUp`) - checks for conflicting names and if `@static` is used on static singleton object member - creates the `static` field in the companion class for `@static` members - moves the field initialization from the companion object to the static initializer of the class (the initialization of `@static` members is bypassed in the `Constructors` phase, and added to static ctors in `CleanUp`) - all callsites to the accessors of `@static` are rewritten to access the static fields directly (this is done in `GenICode`) - getters and setters to `@static` fields access the static field directly, and the field in the singleton object is not emitted (this is done in `GenICode`) - changes in `GenJVM`, `GenASM` - now computing local var indices in static initializers as well - this was an oversight before, now is necessary Future work: allow the `@static` annotation on methods as well - this will be added in a future commit. Review by @odersky, @dragos, @paulp, @heathermiller.
* SI-4763 Deprecated the `cloneable` annotationLukas Rytz2012-07-111-2/+1
|
* starr sources to move cloneable class to package `annotation`Lukas Rytz2012-07-111-0/+16
|
* Address doc comment rot in the standard library.Jason Zaugg2012-05-131-2/+6
| | | | | | | | | | | | | | | | | | | | | - Match @param/@tparam names to the actual parameter name - Use @tparam for type parameters - Whitespace is required between `*` and `@` - Fix incorrect references to @define macros. - Use of monospace `` and {{{}}} (much more needed) - Remove `@param p1 ...` stubs, which appear in the generated docss. - But, retainsed `@param p1` stubs, assuming they will be filtered from the generated docs by SI-5795. - Avoid use of the shorthand `@param doc for the solitary param` (which works, but isn't recognized by the code inspection in IntelliJ I used to sweep through the problems) The remaining warnings from `ant docs` seem spurious, I suspect they are an unintended consequence of documenting extension methods. [scaladoc] /Users/jason/code/scala/src/library/scala/collection/TraversableOnce.scala:181: warning: Variable coll undefined in comment for method reduceOption in class Tuple2Zipped [scaladoc] def reduceOption[A1 >: A](op: (A1, A1) => A1): Option[A1] = reduceLeftOption(op) [scaladoc] ^
* Removed all the imports of the bridge annotation.Paul Phillips2012-04-281-0/+1
| | | | Now that nothing uses it.
* @unspecialized annotation.Paul Phillips2012-04-281-0/+17
| | | | | | | | | Suppresses specialization on a per-method basis. I would have preferred to call it @nospecialize, but seeing as the positive form of the annotation is @specialized, that would have sown unnecessary grammatical confusion. @nospecialized sounds a bit too caveman for my tastes. "Grog no specialized! Grog generic!"
* Added languageFeature annotation (was missing before). Resolved problem with ↵Martin Odersky2012-04-131-0/+13
| | | | late loading of nested classes in Definitions. Resolved handling of deprecated idents `then` and `macro`. Massaged test flags.
* new annotation targets for companion classes/objects/factory methods.Martin Odersky2012-04-113-0/+48
|
* Fixed broken links in sources of scala/annotationDominik Gruntz2012-04-052-3/+3
|
* Whitespace commit.Paul Phillips2012-02-291-2/+2
| | | | | | | Removed all the trailing whitespace to make eugene happier. Will try to keep it that way by protecting at the merge level. Left the tabs in place because they can't be uniformly changed to spaces, some are 2, some are 4, some are 8, whee.
* Reworking synchronized patch.Paul Phillips2012-02-281-15/+0
| | | | Eliminated annotation and custom phase. Kept SYNCHRONIZED flag.
* Merge remote-tracking branch 'szabolcsberecz/SI-64' into SI-64-freshPaul Phillips2012-02-281-0/+15
|\
| * replace methods containing a synchronized body with synchronized methodsSzabolcs Berecz2012-02-161-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following: def f = synchronized { ... } will be rewritten to: <synchronized> def f = ... which is then emitted to the classfile with the synchronized flag set. Inlining of such transformed methods are disabled for now This transformation is not done on methods defined in a trait.
* | Fleshed out the @elidable documentation.Paul Phillips2012-02-231-15/+43
| |
* | update api docs for @elidable to match the behaviour more closely.Szabolcs Berecz2012-02-231-4/+7
|/
* Migration message and version cleanupSimon Ochsenreither2011-12-071-8/+10
| | | | | | | | | | The @migration annotation can now be used like @deprecation. Old syntax is still supported, but deprecated. Improve wording and consistency of migration messages, migration warnings also print the version in which the change occurred now. Partially fixes SI-4990.
* Moved meta annotations to annotation.meta, plus.Paul Phillips2011-10-108-12/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It took me a long time to find a trivial error while adjusting the annotation packages, so I spent even longer trying to make sure next time it would take me less time. It's the usual business of eliminating duplication and unnecessary indirection. Behavioral note: there was no consistency or deducible reasoning regarding when annotation checks would be performed against the typeSymbol directly (thus excluding annotation subclasses) or when they would do a subclass check. I saw no reason it shouldn't always be a subclass check; if the annotation isn't supposed to be subclassed it should be final, and if it is, then the subclasses had probably better not stop exhibiting the behavior of the base class. Example: this now draws deprecated warnings, but did not before. class bippy extends deprecated("hi mom", "burma shave") @bippy def f = 5 (The deprecation message isn't printed so we're not there yet, but closer.) There is some new internal documentation on annotations, sadly lacking in my famous ascii diagrams, and some new conveniences. Review by rytz.
* Shuffling classes around.Paul Phillips2011-10-017-144/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Old Man Reflection is coming home and he's not going to like finding out a bunch of beans have moved into his reflecting room. We had better evict those guys before he blows his stack. scala.reflect.*Bean* --> scala.beans.* scala.beans, that's kind of a fancy package name for some beans. I figure it's time to start fishing or cutting bait on this kind of thing. I don't even know what beans are, but if we're going to have them in the mainline, the least surprising place to find them is scala.beans. If we don't want to put them in scala.beans for whatever reason, then I say they don't belong in trunk at all. Bonus round: scala.annotation.target --> scala.beans.meta I don't know if there is any more unfortunate name for a package possible than "target". Maybe ".svn" or ".git" if you could have dots in package names. Package CVS wouldn't hit too hard these days. Package lib_managed? I'll try to come up with something. In any case this golden opportunity could not be squandered. There is a new starr included, because GenJVM contains all kinds of shooting-from-the-hip Bean-related name hardcoding. (Yes, still. I ran out of stones. So a few birds escape with their lives... this time.)
* 2nd round of clean ups (see r25285)michelou2011-07-157-51/+45
|
* Cleaned up some hopelessly atrophied documentat...Paul Phillips2011-04-271-26/+17
| | | | | Cleaned up some hopelessly atrophied documentation, no review.
* Added bridge method capability to compiler.Martin Odersky2011-04-211-0/+13
|
* Various addenda to soc's patch: regenerating Pr...Paul Phillips2011-04-141-1/+1
| | | | | | | Various addenda to soc's patch: regenerating Product/Tuple/Function classes and AnyVal sources, making versioning consistent, etc. Closes #4477, no review.
* Adds "since" field to @deprecated.Paul Phillips2011-04-141-1/+1
| | | | | | for the patch, as it's a change I've always wanted. Moving up in the glamorous world of scala commits! No review.
* Removed uniqueness annotations. Review by rytz.Philipp Haller2011-03-174-95/+0
|
* improved documentation for annotations in scala...Lukas Rytz2011-03-157-234/+74
| | | | | | improved documentation for annotations in scala.annotation.target. closes #4250, no review.
* Added documentation in annotation.unique packag...Philipp Haller2011-03-081-0/+10
| | | | | Added documentation in annotation.unique package object. No review.
* Updated copyright notices to 2011Antonio Cunei2011-01-2024-24/+24
|
* Some modifications to @elidable: for reasons lo...Paul Phillips2011-01-121-12/+27
| | | | | | | | Some modifications to @elidable: for reasons lost to me now it had a default value such that annotated methods might be elided even if the option wasn't given. It now does nothing in that situation. Closes #4051, #4151, no review.
* Added uniqueness annotations. Review by rytz.Philipp Haller2010-12-074-0/+85
|
* Moved ClassfileAnnotation/StaticAnnotation/Anno...Paul Phillips2010-12-0620-16/+109
| | | | | | | Moved ClassfileAnnotation/StaticAnnotation/Annotation/TypeConstraint into scala.annotation and enabled the deprecated type aliases in scala.* to point there. Also enclosed is a new starr to bootstrap. No review.
* Deprecated the @serializable annotation, introd...Lukas Rytz2010-11-301-0/+15
| | | | | | | | | | | | | | | | | | | Deprecated the @serializable annotation, introduce a new trait "scala.Serializable" which has to be extended instead (cross-platform). Known issues: - Companion objects of serializable classes (including case classes) are automatically made serializable. However, they don't extend "Serializable" statically because of the known difficulty (should be done before typing, but hard). - Writing "case class C() extends Serializable" gives "error: trait Serializable is inherited twice" - Functions are serializable, but don't extend Serializable dynamically (could be fixed by making FunctionN Serializable - shouldn't we?) Note that @SerialVersionUID continues to be an annotation; it generates a static field, which is not possible otherwise in scala. Review by dragos, extempore. Question to dragos: in JavaPlatform.isMaybeBoxed, why is there a test for "JavaSerializableClass"? Is that correct?
* Fix for #3621.Aleksandar Pokopec2010-11-241-0/+18
| | | | | | | Added varargs annotation. Review by Rytz.