| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is less than ideal:
scala> class Bippy[T] extends annotation.StaticAnnotation
defined class Bippy
scala> def f: Int @Bippy = 5
f: Int @Bippy[T]
Turns out we can infer such types. Now it says:
scala> def f: Int @Bippy = 5
f: Int @Bippy[Nothing]
This should put to rest many an issue with parameterized
annotations.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change allows an additional notation of the @throws annotation:
Old-style: @throws(classOf[Exception])
New-style: @throws[Exception]
The optional String argument moves @throws in line with @deprecated,
@migration, etc. and prevents confusion caused by the default inheritance
of ScalaDoc comments and the non-inheritance of annotations.
Before: /** This method does ...
* @throws IllegalArgumentException if `a` is less than 0. */
@throws(classOf[IllegalArgumentException])
def foo(a: Int) = ...
Now: /** This method does ... */
@throws[IllegalArgumentException]("if `a` is less than 0")
def foo(a: Int) = ...
ScalaDoc @throws tags remain supported for cases where documentation of
thrown exceptions is needed, but are not supposed to be added to the
exception attribute of the class file.
In this commit the necessary compiler support is added.
The code to extract exceptions from annotations is now shared instead
of being duplicated all over the place.
The change is completely source and binary compatible, except that the code
is now enforcing that the type thrown is a subtype of Throwable as mandated
by the JVM spec instead of allowing something like @throws(classOf[String]).
Not in this commit:
- ScalaDoc support to add the String argument to ScalaDoc's exception list
- Adaption of the library
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Removed more than 3400 svn '$Id' keywords and related junk.
|
|
|
|
|
|
| |
Fixed a number of faulty Scaladoc comments in library and compiler
sources. No review.
|
| |
|
| |
|
|
|
|
|
| |
fixed doArgs (Settings.scala) and loadFrom (Plugin.scala)
|
|
|
|
|
| |
only for classes created after Scala 1.4
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The standard library will now be laid out approximately like this
library/scala
/jvm/scala
/jvm/jvm1.4/scala
/jvm/jvm1.5/scala
/jvm/android/scala
/jvm/cldc/scala
/dotnet/scala
To build the standard library for a given target you start by copying
the root library/scala tree to a staging area, then move down in the
hierarchy copying the nested "scala" trees on top in the staging area.
So if you wanted to build for cldc, for example, you would do something
like the following:
rsync -avz library/scala staging/
rsync -avz library/scala/jvm/scala staging/
rsync -avz library/scala/jvm/cldc/scala staging/
The ant build files will be updated to do this for you automagically,
and there will soon be shell script to do this if you want to compile
some parts of the standard library manually.
|
| |
|
|
|
|
|
| |
dual mode (generics or not) version of compiler and libraries
|
| |
|
| |
|
| |
|
|
|
|
|
| |
improved Scala comments in scala/concurrent/*.scala
|
|
Added scala.throws(java.lang.Class) attribute to specify the checked
exceptions thrown by a method
|