| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Warn when Any or AnyVal is inferred.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the very small price of annotating types as Any/AnyVal in those
cases where we wish to use them, we can obtain useful warnings.
I made trunk clean against this warning and found several bugs
or at least suboptimalities in the process.
I put the warning behind -Xlint for the moment, but I think this
belongs on by default, even for this alone:
scala> List(1, 2, 3) contains "a"
<console>:8: warning: a type was inferred to be `Any`; this may indicate a programming error.
List(1, 2, 3) contains "a"
^
res0: Boolean = false
Or this punishment meted out by SI-4042:
scala> 1l to 5l contains 5
<console>:8: warning: a type was inferred to be `AnyVal`; this may indicate a programming error.
1l to 5l contains 5
^
res0: Boolean = false
A different situation where this arises, which I have seen variations
of many times:
scala> class A[T](default: T) {
def get(x: => Option[T]) = x getOrElse Some(default)
}
<console>:7: warning: a type was inferred to be `Any`; this may indicate a programming error.
class A[T](default: T) { def get(x: => Option[T]) = x getOrElse Some(default) }
^
// Oops, this was what I meant
scala> class A[T](default: T) {
def get(x: => Option[T]) = x getOrElse default
}
defined class A
Harder to avoid spurious warnings when "Object" is inferred.
|
|\
| |
| | |
merge 2.10.x into master
|
| |\
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/compiler/scala/tools/nsc/ast/TreeGen.scala
src/compiler/scala/tools/nsc/settings/AestheticSettings.scala
|
| | |\
| | | |
| | | | |
Enable inlining in constructors.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Inlining in constructors has been disabled a long
time ago due to some VerifyErrors. Unfortunately,
@dragos cannot recall what exactly was the problem.
I tried to enable inlining in constructors and I
didn't see any problem.
`Predef.assert` calls in class constructors are one
of the biggest contributors to closure allocation
in a compiler so we better off get rid of it.
Added a test-case that checks if inlining in
constructors works properly.
Review by @magarciaEPFL and @paulp.
|
| | |\ \
| | | | |
| | | | | |
SI-6186 TypeTags no longer supported in macros
|
| | | |/
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The original idea was to support both both TypeTags and ConcreteTypeTags as
context bounds on macro implementations.
Back then TypeTags were the implied default flavor of type tags. Basically
because "TypeTag" is shorter than "ConcreteTypeTag" everyone jumped onto
them and used them everywhere.
That led to problems, because at that time TypeTags could reify unresolved type
parameters ("unresolved" = not having TypeTag annotations for them). This
led to a series of creepy errors, when one forgets to add a context bound
in the middle of a chain of methods that all pass a type tag around, and then
suddenly all the tags turn into pumpkins (because that unlucky method just
reifies TypeRef(NoPrefix, <type parameter symbol>, Nil and passes it down
the chain).
Hence we decided to rename ConcreteTypeTag => TypeTag & TypeTag => AbsTypeTag,
which makes a lot of sense from a reflection point of view.
Unfortunately this broke macros (in a sense), because now everyone writes
TypeTag context bounds on macro implementations, which breaks in trivial
situations like: "def foo[T](x: T) = identity_macro(x)" (the type of x
is not concrete, so macro expansion will emit an error when trying to
materialize the corresponding TypeTag).
Now we restore the broken balance by banning TypeTag from macro impls.
This forces anyone to use AbsTypeTags, and if someone wants to check the input
for presence of abstract types, it's possible to do that manually.
|
| | |\ \
| | | |/
| | |/| |
Removes AnyRef specialization from library
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As discussed in #999, #1025 and
https://groups.google.com/forum/?hl=en&fromgroups#!topic/scala-internals/5P5TS9ZWe_w
instrumented.jar is generated from the current source, there's no need
for a bootstrap commit.
Review by @paulp.
|
| | |\ \
| | | | |
| | | | | |
Makes all private variables accessed from an @inline method non-private.
|
| | | | |
| | | | |
| | | | |
| | | | | |
inlining across classes requires that accessed variables from @inline methods are not private.
|
| | |\ \ \
| | | | | |
| | | | | | |
Ultimate reflection pull request #2
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Since Scala reflection relies on Java reflection to perform member invocations,
it inherits some of the quirks of the underlying platform.
One of such quirks is returning null when invoking a void-returning method.
This is now fixed by introducing a check after calling invoke.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Previously `checkMemberOf` was blocking base fields and methods
that are overriden in receiver.getClass. Now this is fixed.
The fix also uncovered an issue with field mirrors. Currently
their `get` and `set` methods don't respect overriding and always
return field values from a base class.
After discussing this on a reflection meeting, we decided that this
behavior is desirable and that for overriding people should use
reflectMethod and then apply on getters/setters. See the discussion at:
https://github.com/scala/scala/pull/1054.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In 911bbc4 I've completely overlooked the fact that
reflectConstructor exists and that is also needs sanity checks.
Now reflectConstructor checks that the incoming symbol is actually a ctor,
and that it is actually a ctor of the class reflected by the current mirror.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Arguments provided in by-name positions are now automatically wrapped
in Function0 instances by method mirrors.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
mirrors now carry a class tag of the receiver, so that they can detect
value classes being reflected upon and adjust accordingly (e.g. allow
Int_+ for ints, but disallow it for Integers).
Surprisingly enough derived value classes (SIP-15 guys that inherit from AnyVal)
have been working all along, so no modification were required to fix them.
|
| | | |/ /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In Scala there are some methods that only exist in symbol tables,
but don't have corresponding method entries in Java class files.
To the best of my knowledge, these methods can be subdivided into five groups:
1) stuff weaved onto Any, AnyVal and AnyRef (aka Object),
2) magic methods that Scala exposes to fix Java arrays,
3) magic methods declared on Scala primitive value classes,
4) compile-time methods (such as classOf and all kinds of macros),
5) miscellaneous stuff (currently only String_+).
To support these magic symbols, I've modified the `checkMemberOf` validator
to special case Any/AnyVal/AnyRef methods and adjusted MethodMirror and
ConstructorMirror classes to use special invokers for those instead of
relying on Java reflection.
Support for value classes will arrive in the subsequent commit, because
it requires some unrelated changes to the mirror API (currently mirrors
only support AnyRefs as their targets).
|
| | |\ \ \
| | | | | |
| | | | | | |
update and normalize copyright notice
|
| | | |/ /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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
```
|
| | |\ \ \
| | | | | |
| | | | | | |
SI-5788 Tailcalls LabelDefs correctly duplicated
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
... in specialization.
This is a quick hack to get SI-5788 fixed in 2.10.x. The full patch,
which fixes the tailcalls LabelDefs will be merged into trunk, as it's
too late for big changes.
For reference, the complete fix is: e86afe65c8
|
| | |\ \ \ \
| | | |_|_|/
| | |/| | | |
SBT compiler interface now compiled in ant build. Ensures those still u...
|
| | | |/ /
| | | | |
| | | | |
| | | | | |
ant don't break the interface.
|
| | |\ \ \
| | | | | |
| | | | | | |
SI-6063, SI-4945 and restore :warnings in the REPL
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
As seen here.
scala> class A { @deprecated("foo") def a = 1 }
warning: there were 1 deprecation warnings; re-run with -deprecation for details
defined class A
scala> :warnings
<console>:7: warning: @deprecated now takes two arguments; see the scaladoc.
class A { @deprecated("foo") def a = 1 }
^
scala> val x = 5 toString
warning: there were 1 feature warnings; re-run with -feature for details
x: String = 5
scala> :warnings
<console>:7: warning: postfix operator toString should be enabled
by making the implicit value language.postfixOps visible.
This can be achieved by adding the import clause 'import language.postfixOps'
or by setting the compiler option -language:postfixOps.
See the Scala docs for value scala.language.postfixOps for a discussion
why the feature should be explicitly enabled.
val x = 5 toString
^
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Other breakage had accumulated among Settings. I determined
that once upon a time, "MultiStringSetting" accepted arguments
like this:
scala -foo bip bop bar
Somewhere this was changed to force a : argument, like
scala -foo:bip,bop,bar
This incurs breakage. The repl has always advertised its -i
option without a colon and it has always been a MultiStringSetting.
Forcing everything into the : seemed like the wrong thing,
especially because it will stomp on any whitespace containing
arguments, whereas in the original form
scala -foo bip "bop bar" baz
will yield its arguments as given.
So lacking any good ideas and knowing something probably depends
on each way already, I made it work both ways.
|
| | | | |/
| | | |/|
| | | | |
| | | | | |
Have to rule out access boundaries as well as private/protected.
|
| | |\ \ \
| | | |/ /
| | |/| | |
SI-6102 Wrong bytecode in lazyval + no-op finally clause
|
| | | | | |
|
| | | | | |
|
| | |\ \ \
| | | | | |
| | | | | | |
better error messages for Symbol.asXXX methods
|
| | | | | | |
|
| | |\ \ \ \
| | | |_|/ /
| | |/| | | |
SI-6188
|
| | | | | | |
|
| | | | | | |
|
| | |\ \ \ \
| | | | | | |
| | | | | | | |
compatibility stub for SBT 0.12.0
|
| | | | |_|/
| | | |/| |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
As discussed in http://groups.google.com/group/scala-internals/browse_thread/thread/9ee8df2ae9d43169,
recent change of return type for Type.members (from List[Symbol] to Scope)
broke compiler-interface for SBT 0.12.0-final.
This stub (courtesy of Jason Zaugg) keeps reflection API untouched and
also fixes SBT. Win-win.
|
| | |\ \ \ \
| | | | | | |
| | | | | | | |
adds deprecation annotations on manifest incantations
|
| | | | |_|/
| | | |/| | |
|
| | |\ \ \ \
| | | |_|/ /
| | |/| | | |
adds more tests for api.Symbols
|
| | | |/ /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I overlooked some of the tests that should be added to the public API.
This commit fixes my mistake. Also see 027b00171c.
To reiterate the reasoning behind introduction of test methods into the API.
I'd argue that the API duplication w.r.t flags is trumped by unified interface
to tests and better encapsulation (especially since some of the flags have
different meaning depending on whether the flaggee is a term or a type).
|
| | |\ \ \
| | | |_|/
| | |/| | |
SI-6175 reflect over classes with symbolic names
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Top-level classes with symbolic names (having binary names like $colon$colon)
have previously been incorrectly treated as local classes by Scala reflection.
As a result they were loaded as if they weren't pickled (i.e. as Java classes).
Moreover this bug also had a more subtle, but more dangerous manifestation.
If such a class has already been loaded indirectly by unpickling another class
(which refers to it in its pickle) and then someone tried to load it explicitly
via classToScala, then it would be loaded twice (once as a Scala artifact and
once as a Java artifact). This is a short route to ambiguities and crashes.
The fix first checks whether a class with a suspicious name (having dollars)
can be loaded as a Scala artifact (by looking it up in a symbol table).
If this fails, the class is then loaded in Java style (as it was done before).
Ambiguous names that can be interpreted both ways (e.g. foo_$colon$colon)
are first resolved as Scala and then as Java. This prioritization cannot lead
to errors, because Scala and Java artifacts with the same name cannot coexist,
therefore loading a Scala artifact won't shadow a homonymous Java artifact.
|
| | |\ \ \
| | | | | |
| | | | | | |
Clear uniques via perRunCaches.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
That lets this huge cache be cleared eagerly after a run
is over rather than lazily when another run begins. This
arrives pre-LGTMed by Important People.
|
| | |\ \ \ \
| | | | | | |
| | | | | | | |
SI-6074 disallow implicit enrichment with constructor
|
| | | | |_|/
| | | |/| |
| | | | | |
| | | | | |
| | | | | | |
When selecting a non-accessible constructor, don't infer a view to
something with an accessible constructor.
|