| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Correct java source parser not to insert a constructor with the type
of its value method.
|
| |_|/
|/| |
| | |
| | | |
This reverts commit bb9adfbd76af0a0281912fcef4bcaca409a7c9a3.
|
| |/
|/|
| |
| |
| |
| | |
Even more trees (together with Apply nodes produced by templateParents
and New nodes produced by New in TreeBuilders) now distinguish nullary
argument list from empty argument list.
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this commit, the number of :: allocations logged in total
after individually compiling each scala file in src/compiler
drops from 190,766,642 to 170,679,925. Twenty million fewer
colon-colons in the world, it's a start.
For some heavily used lists like List(List()) I made vals so
we can reuse the same one every time, e.g.
val ListOfNil = List(Nil)
The modifications in this patch were informed by logging call
frequency to List.apply and examining the heaviest users.
>> Origins tag 'listApply' logged 3041128 calls from 318 distinguished sources.
1497759 scala.reflect.internal.Definitions$ValueClassDefinitions$class.ScalaValueClasses(Definitions.scala:149)
173737 scala.reflect.internal.Symbols$Symbol.alternatives(Symbols.scala:1525)
148642 scala.tools.nsc.typechecker.SuperAccessors$SuperAccTransformer.transform(SuperAccessors.scala:306)
141676 scala.tools.nsc.transform.SpecializeTypes$$anonfun$scala$tools$nsc$transform$SpecializeTypes$$specializedOn$3.apply(SpecializeTypes.scala:114)
69049 scala.tools.nsc.transform.LazyVals$LazyValues$$anonfun$1.apply(LazyVals.scala:79)
62854 scala.tools.nsc.transform.SpecializeTypes.specializedTypeVars(SpecializeTypes.scala:427)
54781 scala.tools.nsc.typechecker.SuperAccessors$SuperAccTransformer.transform(SuperAccessors.scala:293)
54486 scala.reflect.internal.Symbols$Symbol.newSyntheticValueParams(Symbols.scala:334)
53843 scala.tools.nsc.backend.icode.Opcodes$opcodes$CZJUMP.<init>(Opcodes.scala:562)
... etc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are the regexp replacements performed:
Sxcala
-> Scala
Copyright (\d*) LAMP/EPFL
-> Copyright $1-2012 LAMP/EPFL
Copyright (\d*)-(\d*)(,?) LAMP/EPFL
-> Copyright $1-2012 LAMP/EPFL
Copyright (\d*)-(\d*) Scala Solutions and LAMP/EPFL
-> Copyright $1-2012 Scala Solutions and LAMP/EPFL
\(C\) (\d*)-(\d*) LAMP/EPFL
-> (C) $1-2012 LAMP/EPFL
Copyright \(c\) (\d*)-(\d*)(.*?)EPFL
-> Copyright (c) $1-2012$3EPFL
The last one was needed for two HTML-ified copyright notices.
Here's the summarized diff:
Created using
```
git diff -w | grep ^- | sort | uniq | mate
git diff -w | grep ^+ | sort | uniq | mate
```
```
- <div id="footer">Scala programming documentation. Copyright (c) 2003-2011 <a href="http://www.epfl.ch" target="_top">EPFL</a>, with contributions from <a href="http://typesafe.com" target="_top">Typesafe</a>.</div>
- copyright.string=Copyright 2002-2011, LAMP/EPFL
- <meta name="Copyright" content="(C) 2002-2011 LAMP/EPFL"/>
- * Copyright 2002-2011 LAMP/EPFL
- * Copyright 2004-2011 LAMP/EPFL
- * Copyright 2005 LAMP/EPFL
- * Copyright 2005-2011 LAMP/EPFL
- * Copyright 2006-2011 LAMP/EPFL
- * Copyright 2007 LAMP/EPFL
- * Copyright 2007-2011 LAMP/EPFL
- * Copyright 2009-2011 Scala Solutions and LAMP/EPFL
- * Copyright 2009-2011 Scxala Solutions and LAMP/EPFL
- * Copyright 2010-2011 LAMP/EPFL
- * Copyright 2012 LAMP/EPFL
-# Copyright 2002-2011, LAMP/EPFL
-* Copyright 2005-2011 LAMP/EPFL
-/* NSC -- new Scala compiler -- Copyright 2007-2011 LAMP/EPFL */
-rem # Copyright 2002-2011, LAMP/EPFL
```
```
+ <div id="footer">Scala programming documentation. Copyright (c) 2003-2012 <a href="http://www.epfl.ch" target="_top">EPFL</a>, with contributions from <a href="http://typesafe.com" target="_top">Typesafe</a>.</div>
+ copyright.string=Copyright 2002-2012 LAMP/EPFL
+ <meta name="Copyright" content="(C) 2002-2012 LAMP/EPFL"/>
+ * Copyright 2002-2012 LAMP/EPFL
+ * Copyright 2004-2012 LAMP/EPFL
+ * Copyright 2005-2012 LAMP/EPFL
+ * Copyright 2006-2012 LAMP/EPFL
+ * Copyright 2007-2012 LAMP/EPFL
+ * Copyright 2009-2012 Scala Solutions and LAMP/EPFL
+ * Copyright 2010-2012 LAMP/EPFL
+ * Copyright 2011-2012 LAMP/EPFL
+# Copyright 2002-2012 LAMP/EPFL
+* Copyright 2005-2012 LAMP/EPFL
+/* NSC -- new Scala compiler -- Copyright 2007-2012 LAMP/EPFL */
+rem # Copyright 2002-2012 LAMP/EPFL
```
|
|
|
|
| |
This pretty much takes us down to deprecation and inliner warnings.
|
|
|
|
|
|
| |
This brought to light that Name extends (Int => Char), and
that small convenience was not paying for itself. I updated
the places taking advantage of it to use Name#charAt.
|
|
|
|
| |
Empty statements are A-OK. Closes SI-5910. Review by @dragos.
|
|
|
|
| |
This is the first step of factoring out scala-reflect.jar.
|
|
|
|
|
|
| |
Fixed up one of the mismatches between how java source is modeled
and how java bytecode is modeled. We should get the rest of them
too. Closes SI-2764.
|
|
|
|
|
| |
The ones which remain I'm not removing on purpose, as I know
from experience it's more trouble than it's yet worth.
|
|
|
|
| |
feature clean.
|
|
|
|
| |
From the extempore archive of already implemented things.
|
|
|
|
|
|
| |
ClassDefs, CaseDefs, and LabelDefs. Dotting eyes,
crossing tees. Point of diminishing returns is reached,
declare victory and withdraw.
|
|
|
|
|
|
| |
It's a lot like the last one. I also found trees being
duplicated before being sent to the tree copier. Looks like
xerox has gotten a mole in here. Trust no one.
|
|
|
|
| |
More trees created more uniformly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are too many potential optimizations unavailable to us due to the
lack of bright lines among different kinds of symbols. For instance the
difference between a TypeSymbol which represents a type alias and one
which represents an abstract type is only whether the DEFERRED flag
is set. This creates issues.
1) There are many (many) places where tests are performed on every symbol
which could be done more efficiently and (especially) more verifiably
correctly with polymorphism.
2) TypeRefs based on those symbols are also checking that flag
constantly, in perpetuity. A symbol created as an alias is never (to the
best of my knowledge) going to intentionally morph into one representing
an abstract type, nor vice versa.
3) One has no guarantees, because anyone can set or reset the DEFERRED
flag at any time.
So tackling more than one problem at once herein:
1) I created canonical symbol creation points which take the flags as
an argument, so that there can be a difference between initializing a
symbol's flags and setting/resetting them at arbitrary times.
2) I structured all the symbol creators to take arguments in the
same order, which is:
def newXXX(name: Name, ..., pos: Position = NoPosition, flags: Long = 0L)
(Where "..." is for those symbols which require something
beyond the name to create, such as a TypeSkolem's origin.)
The name is first because it's the only always required argument.
I left but deprecated the variations which take (pos, name).
3) I created subclasses of TypeRef based on the information which
should be stable from creation time onward:
- args or no args?
- abstract type, type alias, or class?
2x3 == 6 and that's how many subclasses of TypeRef there are now. So
now, for example, every TypeRef doesn't have to carry null symInfoCache
and thisInfoCache fields for the benefit of the minority which use them.
I still intend to realize the gain possible once we can evade the fields
for pre and args without losing pattern matcher efficiency.
|
|
|
|
|
|
|
|
| |
Several large helpings of tedium later, fewer strings are being
discarded like so much refuse. Some names now cache a String, but only
"named Names", so it's not very many and they pay for themselves pretty
quickly. Many fewer name-related implicit conversions now taking place.
A number of efficiency related measures.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1.+(2) - what is it? Is it 3 or 3.0? Come scala 2.11 you won't
have to not know (or even not know there's something you don't know.)
1.+(2) will then be safely considered equivalent to 1 + 2, because
any dot not followed by a digit is not part of a number.
Primarily, that's these forms: 3.f 3.d 3.
If you prefer an error to a warning, use -Xfuture.
Let's deprecate 012 == 10 too! (See comment.) References SI-5089, no
review.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit doesn't include the line which would change anything
interesting (that being making toString in Name a val), it is all
the changes elsewhere which one would have to make to do that. I
didn't want to waste them. A quirk of scala is that if you call an
empty-parameter-list method:
foo.bar() // e.g. x.toString()
foo.bar // where you could have called x.toString
then if you decide in the future to make it a val, every call site must
potentially be modified. This is a bit of a bummer. One can try to
defend against that future decision by eschewing parentheses, but it's
not very satisfying or effective. No review.
|
|
|
|
|
|
|
|
| |
LiftCode works again, now integrated with new reflection library.
Other changes: def Literal(x: Any) has been deprecated, and all its uses removed.
Modifiers has lost positions as fourth case class argument; is now a field, mirroring Tree.pos (this removes junk in patterns and makes reification simpler). Review by extempore.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Moved scala.reflect.Chars to scala.reflect.internal.Chars, un-splitting
the scala.reflect package. This is necessary for running in an OSGi
container, such as Eclipse. A package may not be contributed by two
different bundles (in this case the library and the compiler). It may
be moved back when 'scala.reflect' exists only in one place. review by
extempore.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch and the several to follow represent an attempt to break
up a very large patch from martin which moves much of the compiler's
typing infrastructure into the library so that we can utilize the same
machinery at runtime that we do at compile time.
Said attempt was not very successful, either at maintaining working
order while committing incrementally or at subdividing the patch into
distinct cohesive units. So let the record show that I tried.
-- some notes on the implementation --
This should not be judged as a finished work, but it's a necessary
opening step for implementing a reflection API without duplicating much
of the compiler.
The files in scala.reflect.common are destined for the library (not the
compiler, where they are now) but have not yet made the leap to manage
compatibility issues.
scala.reflect.generic is likely to be replaced by an alias to
scala.reflect.common.
The fate of scala.reflect.Code and its derived classes is yet to be
determined.
This first patch contains about the only delta against martin's patch,
which is to promote Chars into scala.reflect. Review by odersky.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I wrote a warning when nullary methods return Unit. I wimped out of
including it in this patch because we had about 200 of them, and that's
what is fixed in this patch. I will add the warning to some kind of
"-Xlint" feature after 2.9.
This is motivated at least partly by the resolution of #4506, which
indicates the distinction between "def foo()" and "def foo" will
continue to jab its pointy stick into our eyes, so I believe we have a
minimal duty of at least following our own advice about what they mean
and not making a semirandom choice as to whether a method has parens or
not. Review by community.
|
|
|
|
|
|
| |
Changed scala.io.Position into something other than a fixed object which
throws exceptions when the position overflows. Closes #4382, no review.
|
|
|
|
|
|
| |
Primarily a cleanup of the organization of keywords for the scala and
java parsers, and a few other Name-related items. No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Disentangled scaladoc and the presentation compiler. Now there are
different flags, forInteractive and forScaladoc, instead of the
overloaded onlyPresentation. While it is unfortunate to have these
flags, I know of no easy way to customize the typer (the behavior they
control is pretty deep into the analyzer). This shaves off around 100MB
of unnecessary docComments from the presentation compiler. review by
odersky, dubochet.
|
|
|
|
|
|
|
|
|
|
| |
questions start to arise as the ability to distinguish between type and
term names becomes more fully realized: particularly that the ability
to distinguish between TermSymbols and TypeSymbols has not come along
with the names. In any case, this is more tedious than I might have
anticipated but mostly because it's blazing a trail of typiness to ease
the path for others. No review.
|
|
|
|
|
|
|
|
|
| |
A foot in the door with Parsers/JavaParsers and Scanners/JavaScanners.
Recently clued in as to how this situation came to be, I now know
there's no reason not to start containing the damage. Also more work
on names: made a general method for transforming Trees into type-named
Trees and put it to work. No review.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TermName and TypeName are exposed throughout the compiler based on what
kind of name a given abstraction ought to have. (There remain places
where one needs to create a name without knowing yet what it will be,
and those will always be Names.)
The nme object in the compiler now holds only term names. To reference a
known type name, use tpnme:
nme.List == ("List": TermName)
tpnme.List == ("List": TypeName)
The contents of nme and tpname are defined in traits, many of which
are shared, so if a name should exist only as a Type and not a
Term, it should be defined in CompilerTypeNames, but otherwise in
CompilerTermNames or CompilerCommonNames. This is partially complete but
I'm sure there are still many shared which should pick a side.
Usage of .toTermName and .toTypeName is strongly discouraged. After the
dust has settled, there will be very few places where it will make sense
to hop between namespaces like that.
There are some implicits to smooth everything out, most of which should
be removable eventually.
// these two are in no hurry to go anywhere
String => TermName
String => TypeName
// but not String => Name: def view in the compiler is no longer implicit
// these two are temporary, and can log when they kick off to help us
flush // out remaining issues of "name migration" Name => TermName
Name => TypeName
There is more work to be done before we're properly protected from
naming errors, but I will not allow another eight hour tragedy to befall
lukas or anyone else!
Review by rytz. (Formality.)
|
|
|
|
|
|
|
|
|
|
|
| |
Determined that half a dozen ways of checking for varargs and
by-name-ness in param lists exceeded the legal limit. Also assessed that
names which are only used as type names would be a lot easier to deal
with if we created them as type names up front. Performed the changes
implied by the preceding along with a partial cleanup on TreeInfo which
one can see hasn't had a good look in a long time. (And still hasn't.)
No review.
|
|
|
|
|
|
|
|
|
|
| |
One of those annoying patches for which I apologize in advance. It's a
step toward a better world. Almost all the changes herein are simple
transformations of "x hasFlag FOO" to "x.isFoo", with the remainder
minor cleanups. It's too big to review, so let's say no review:
but I'm still all ears for input on the issues mostly outlined in
HasFlags.scala.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a fascinating tangle of name creation functions passing around
positions only to reach the end of the line and discard the position
since names don't have positions. I deleted all of it. The winner for
most creative use of parameters was the freshName function in etaExpand,
with this signature:
def freshName(pos: util.Position, n: Int)
And an implementation referencing neither pos nor n. "In a world beset
by attrition on all sides... a people defeated by entropy... one man
will show them the power of deletion." No review.
|
|
|
|
|
|
|
|
|
| |
This maps @native, @volatile, and @transient in java source to the
relevant annotations in scala, rather than discarding the modifiers
completely. I have no specific motivation for this other than it seems
better to do it than not. Also cleans up some old flailing of mine in
the dept. of mapping java access to scala. No review.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removes a bunch of private functions which are never called. While based
on the nature of "private" one can generally feel pretty good that such
a thing is safe, there is always a chance the author had some future use
in mind. On that note I draw your attention in particular to:
(martin) Typers#stabilizedType: it "sounds" important, but most of it
has been commented out since 2007 and the little stub part is a never
called private.
(iulian) SpecializeTypes#makeTypeArguments: similarly sounds like a
cornerstone of a transformation until one notices it isn't used.
Unused methods are "attractive nuisances" for anyone (like myself) who
has to figure out how the compiler works by studying the compiler, for
reasons which are no doubt obvious. No review except as noted.
|
|
|
|
|
| |
Scala IDE needs mutable files with changing content. review by odersky
|
|
|
|
|
|
|
| |
Revert 22605 change to JavaParsers.scala, which modified parsing
behavior and broke jvm test t3415. No longer create DocDef nodes for
Javadoc comments in Java source files. No review.
|
|
|
|
|
| |
[scaladoc] Make a DocDef node for javadoc comments in Java source files.
|
|
|
|
|
| |
Removed more than 3400 svn '$Id' keywords and related junk.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
You know Cutty McPastington is having a good time when you can find this
logic in two different files:
('A' <= c && c <= 'Z') ||
('a' <= c && c <= 'a') ||
How could that possibly work, you might ask. After a series of ||s, the
last condition subsumes most of the previous ones:
Character.isUnicodeIdentifierStart(c)
thereby saving us from a world where the only legal lower case
identifiers are a, aa, aaa, aaaa, and a few others. No review.
|
|
|
|
|
|
|
|
|
|
|
| |
A few yards short of the goal posts attempt at making our usage of
Throwable subclasses more consistent. This patch eliminates a lot of
ad hoc Exception/Error/etc. creation and various arbitrary choices are
rendered slightly less arbitrary. From now on let's try not to use the
word "Exception" or "Error" in the names of Throwable subclasses unless
they actually derive (and make sense to derive) from Exception or Error.
Review by community.
|
|
|
|
|
|
|
|
| |
The initial results of running a basic cut and paste detector over trunk
and trying to undo some of it. I can live with history but if I see
Cutty McPastington in new commits I will get all finger waggly. Don't
make me cross that ocean. No review.
|
| |
|
|
|
|
|
|
|
| |
refined doc comments generation; refactored code into new Chars,
DocStrings classes in util. Added some more doc comments to collection
classes.
|