| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Introduces a dedicated facility to go from a type to a type of its companion.
Previously we had to do something really horrible for that, something like:
tp.typeSymbol.companionSymbol.typeSignature.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per Jason’s request, Type now features such important convenience
methods as typeArgs, typeParams, paramss, resultType and finalResultType
without requiring to perform any casts.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It’s very probable that this is the single most requested method in the
entire reflection API of Scala 2.10.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
normalize is a highly overloaded name and it also conflates two distinct
operators, so how about we give our users self-explaning atomic tools instead.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per Paul’s request, this commit exposes Symbol.defString, although
in a different way to ensure consistency with our other prettyprinting
facilities provided in the reflection API.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
A very frequent use for a result of typeOf is obtaining an underlying
type symbol. Another thing that comes up occasionally at stack overflow
is a request to add facilities for reification of symbols.
This naturally suggests that our reflection API would benefit from a method
called symbolOf that can take a term or type argument and return an underlying
symbol.
While an API to extract a term symbol from an expression needs some time
to be designed and then implemented robustly (we don’t have untyped macros
so we’ll have to account for various desugarings), meaning that we probably
won’t have time for that in 2.11, a type symbol extractor seems to be
a very low-hanging fruit.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is a nice addition to Universe.typeOf[T], quite frequently useful
for inspecting ad-hoc types.
As promised by https://github.com/scala/scala/pull/1741, which represented
my previous stab at adding this API, I ran into problems when trying to
introduce the API naively.
def typeOf[T](implicit ttag: TypeTag[T]): Type
def typeOf[T: TypeTag](x: T): Type
The first problem came from the fact that even though they don't look
ambiguous, under certain circumstances, the couple of typeOf overloads
can become ambiguous. Concretely, ambiguity happens when T <: TypeTag[T],
which makes the compiler uncapable to choose an overload to typecheck
`typeOf[T](<materialized>: TypeTag[T])`. Luckily, defining x as a by-name
parameter fixes the problem.
def typeOf[T](implicit ttag: TypeTag[T]): Type
def typeOf[T: TypeTag](x: => T): Type
The second problem manifested itself in reification of snippets that
contained calls to typeOf. Apparently, materialized tags get rolled back
by reify as products of macro expansion, becoming replaced with
`implicitly[TypeTag[T]]`. Afterwards, subsequent rollback of TypeTree's
strips the replacement of its type argument, producing bare `implicitly`.
Back then when typeOf wasn't overloaded, this abomination typechecked
and worked correctly, but now, due to some weird reason, it stopped.
I have worked around this by performing the rollback on a larger scale -
instead of hunting down materialized tags, this commit detects calls
to typeOf and removes their implicit argument lists altogether.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Introduces a test that iterates all abstract types in reflection API
and makes sure that every one of them has an associated class tag.
After being introduced, the test has immediately failed exposing
the lack of tags for TreeCopier, Mirror and RuntimeClass, which has been
subsequently fixed in this commit.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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[_].
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Less magic - less opportunities for mystification.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Continuing in the direction set by the parent commit, this commit
rephrases some more usages of `local` in names and comments in typer.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
There’s been a conflation of two distinct meanings of the word “local”
in the internal symbol API: the first meaning being “local to this”
(as in has the LOCAL flag set), the second meaning being “local to block”
(as in declared in a block, i.e. having owner being a term symbol).
Especially confusing is the fact that sym.isLocal isn’t the same as
sym.hasFlag(LOCAL), which has led to now fixed SI-6733.
This commit fixes the semantic mess by deprecating both Symbol.isLocal and
Symbol.hasLocalFlag (that we were forced to use, because Symbol.isLocal
had already been taken), and replacing them with Symbol.isLocalToThis
and Symbol.isLocalToBlock. Unfortunately, we can’t remove the deprecated
methods right away, because they are used in SBT, so I had to take small
steps.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Among the flags requested by our users, the most popular are definitely
PARAMACCESSOR and CASEACCESSOR. Among other things that are missing in
2.10.x are SYNTHETIC and its close friend ARTIFACT. Apparently, SYNTHETIC
was was added somewhen during the 2.11.0-M* development cycle, so I only
has to introduce ARTIFACT.
There was also METHOD as requested by Paul in https://github.com/xeno-by/declosurify/blob/ce6c55b04086c755102227dd8124b0bf0dac46e1/src/main/scala/macros.scala#L102,
but the absence of that one is compensated by the fact that it’s only needed
when manually creating symbols, and for that we already have Symbol.newMethodSymbol.
This doesn't remove the necessity to see SI-6267 through (read the recently
updated issue description for more information!), but that'd be a significant
change, so let's delay it until better times.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-7475 Private members aren't inheritable, findMember overhaul
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
- comment the cases in `isNewMember`
- check both sides for privacy (doesn't influence behaviour of
any tests, but it means that method can be understood without
understanding the order of traversal of members.)
- hoist `findAll`
- break out of the loop in `FindMembers` as soon as we determine
that the candidate member is matched by an already-found member
and can be discarded.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It turns out `findMembers` has been a bit sloppy in recent
years and has returned private members from *anywhere* up the
base class sequence. Access checks usually pick up the slack
and eliminate the unwanted privates.
But, in concert with the "concrete beats abstract" rule in
`findMember`, the following mishap appeared:
scala> :paste
// Entering paste mode (ctrl-D to finish)
trait T { def a: Int }
trait B { private def a: Int = 0 }
trait C extends T with B { a }
// Exiting paste mode, now interpreting.
<console>:9: error: method a in trait B cannot be accessed in C
trait C extends T with B { a }
^
I noticed this when compiling Akka against JDK 8; a new private method
in the bowels of the JDK was enough to break the build!
It turns out that some finesse in needed to interpret SLS 5.2:
> The private modifier can be used with any definition or declaration
> in a template. They are not inherited by subclasses [...]
So, can we simply exclude privates from all but the first base class?
No, as that might be a refinement class! The following must be
allowed:
trait A { private def foo = 0; trait T { self: A => this.foo } }
This commit:
- tracks when the walk up the base class sequence passes the
first non-refinement class, and excludes private members
- ... except, if we are at a direct parent of a refinement
class itself
- Makes a corresponding change to OverridingPairs, to only consider
private members if they are owned by the `base` Symbol under
consideration. We don't need to deal with the subtleties of
refinements there as that code is only used for bona-fide classes.
- replaces use of `hasTransOwner` when considering whether a
private[this] symbol is a member.
The last condition was not grounded in the spec at all. The change
is visible in cases like:
// Old
scala> trait A { private[this] val x = 0; class B extends A { this.x } }
<console>:7: error: value x in trait A cannot be accessed in A.this.B
trait A { private[this] val x = 0; class B extends A { this.x } }
^
// New
scala> trait A { private[this] val x = 0; class B extends A { this.x } }
<console>:8: error: value x is not a member of A.this.B
trait A { private[this] val x = 0; class B extends A { this.x } }
^
Furthermore, we no longer give a `private[this]` member a free pass
if it is sourced from the very first base class.
trait Cake extends Slice {
private[this] val bippy = ()
}
trait Slice { self: Cake =>
bippy // BCS: Cake, Slice, AnyRef, Any
}
The different handling between `private` and `private[this]`
still seems a bit dubious.
The spec says:
> An different form of qualification is private[this]. A member M
> marked with this modifier can be accessed only from within the
> object in which it is defined. That is, a selection p.M is only
> legal if the prefix is this or O.this, for some class O enclosing
> the reference. In addition, the restrictions for unqualified
> private apply.
This sounds like a question of access, not membership. If so, we
should admit `private[this]` members from parents of refined types
in `FindMember`.
AFAICT, not too much rests on the distinction: do we get a
"no such member", or "member foo inaccessible" error? I welcome
scrutinee of the checkfile of `neg/t7475f.scala` to help put
this last piece into the puzzle.
One more thing: findMember does not have *any* code the corresponds
to the last sentence of:
> SLS 5.2 The modifier can be qualified with an identifier C
> (e.g. private[C]) that must denote a class or package enclosing
> the definition. Members labeled with such a modifier are accessible
> respectively only from code inside the package C or only from code
> inside the class C and its companion module (§5.4).
> Such members are also inherited only from templates inside C.
When I showed Martin this, he suggested it was an error in the
spec, and we should leave the access checking to callers of
that inherited qualified-private member.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Swathes of important logic are duplicated between `findMember`
and `findMembers` after they separated on grounds of irreconcilable
differences about how fast they should run:
d905558 Variation #10 to optimze findMember
fcb0c01 Attempt #9 to opimize findMember.
71d2ceb Attempt #8 to opimize findMember.
77e5692 Attempty #7 to optimize findMember
275115e Fixing problem that caused fingerprints to fail in
e94252e Attemmpt #6 to optimize findMember
73e61b8 Attempt #5 to optimize findMember.
04f0b65 Attempt #4 to optimize findMember
0e3c70f Attempt #3 to optimize findMember
41f4497 Attempt #2 to optimize findMember
1a73aa0 Attempt #1 to optimize findMember
This didn't actually bear fruit, and the intervening years have
seen the implementations drift.
Now is the time to reunite them under the banner of `FindMemberBase`.
Each has a separate subclass to customise the behaviour. This is
primarily used by `findMember` to cache member types and to assemble
the resulting list of symbols in an low-allocation manner.
While there I have introduced some polymorphic calls, the call sites
are only bi-morphic, and our typical pattern of compilation involves
far more `findMember` calls, so I expect that JIT will keep the
virtual call cost to an absolute minimum.
Test results have been updated now that `findMembers` correctly
excludes constructors and doesn't inherit privates.
Coming up next: we can actually fix SI-7475!
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This affords us:
- a better chance to share code with `findMembers` again
- the ability to break up the logic into smaller methods for
scrutability and JIT-tability.
The cost is the use of the heap rather than the stack for the
working area of the computation. But I didn't notice a difference
between `locker.lib` and `quick.lib` after this change.
I've left the old implementation in place with an assertion to
verify identical results. In the next commit, this stepping stone
will be removed, and we'll update `findMembers` to share the code.
Some problem areas have been highlighted and will be addressed
after the refactoring phase is complete.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Revert "SI-1786 incorporate defined bounds in inference"
|
| | | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Have to revert because the stricter bounds that it inferred break e.g., slick.
(Backstop for that added as pos/t1786-counter.scala, as minimized by Jason)
Worse, the fix was compilation order-dependent.
There's a less invasive fix (SI-6169) that could be generalized
in `sharpenQuantifierBounds` (used in `skolemizeExistential`),
but I'd rather not mess with existentials at this point.
This reverts commit e28c3edda4dd405ed382227d2a688b799bf33c72.
Conflicts:
src/compiler/scala/tools/nsc/typechecker/Typers.scala
test/files/pos/t1786.scala
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-5994 battling implicits for String.lines
|
| | | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Deprecated ProcessBuilder's lines method and renamed it lineStream.
stream was another possibility, but that seemed more likely to cause conflicts.
streaming was also tried, but feedback was in favor of lineStream.
Also updated tutorial in ProcessBuilder.
I am sure this will break some tests, but because of the name conflict it's hard to be sure where they are. So Jenkins gets to find the problems for me.
Changed name to lineStream.
|
| |\ \ \ \ \
| |_|/ / /
|/| | | | |
Add a great test case for SI-764, which hopefully one day will compile.
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | | |
Created to convince moors that certain code should compile, it
wound up flushing out some quite nutty behavior. Some day this
will compile rather than having an 11-failure checkfile.
|
| |\ \ \ \
| | | | |
| | | | | |
changes the order of whitebox typechecks. yes, again.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
My first attempt at SI-6992 was about having whitebox expansions first
typecheck against outerPt and only then verify that the result is compatible
with innerPt.
That was a nice try, but soon after it went live in 2.11.0-M8, we've got
multiple reports with problems - both shapeless and then in a week specs2
started having issues with their whitebox macros.
In shapeless, typecheck against outerPt screwed up type inference, which
was more or less fixable by explicit type annotations, so I decided to
wait a bit before jumping to conclusions.
However, in specs2 the problem was more insidious. After being typechecked
against outerPt, expansions were being implicitly converted to a type
that became incompatible with innerPt. This revealed a fatal flaw of the
implemented approach - if allowed to typecheck against outerPt first,
whitebox macros could never be robust.
Now realizing that "outerPt > innerPt" doesn't work, I nevertheless wasn't
looking forward to rolling that back to "innerPt > outerPt", because that
would revive SI-6992 and SI-8048 that are highly unintuitive, especially
the latter one.
Therefore, this commit combines the permissiveness of "... > innerPt"
approaches with the robustness of "innerPt > outerPt", introducing
"WildcardType > innerPt > outerPt".
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Tweak parser entry point for pq""
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Previously pq used pattern1 which required parens to be used in
alternative pattern. This commit tweaks it to allow pq"a | b"
syntax. Also adds some tests for alternative syntax.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-8226 Deduplicate JavaTokens/ScalaTokens
|
| | | | | | | |
|
| |\ \ \ \ \ \
| |_|_|/ / /
|/| | | | | |
readLine shold flush output before reading input
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As reported on scala-user:
> Using `scala.Predef.readLine(text: String, args: Any*)`
> on Windows causes strange behavior. If I am leaving some
> part of `text` unforced to be flushed (say, "---\nEnter new
> expression >") then "Enter new expression >" flushed only
> after Enter press. Still, it works fine on Ubuntu and (seems like)
> on MacOS.
>
> My workaround is to force `java.lang.System.out` (that readLine
> depends on to write welcome string) to flush output like
> "---\nEnter new expression >\n".
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Make Object#== override Any#==
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
- Typer is created with Context.
- Typer creates an Inferencer with said Context.
- Typer mutates Typer#context after each import statement
- Typer mutates its current Context (e.g to disable implicits.)
- Typer asks a question of Inferencer
- Inferencer, looking at the old context, thinks that implicits
are allowed
- Inferencer saves implicit ambiguities into the wrong Context.
Because of this bug, overload resolution in blocks or template
bodies for applications that follow an import have been
considering implicit coercions in the first try at static overload
resolution, and, in the rare case that it encounters an ambigous
implicit in the process, leaking an unpositioned ambiguout error.
This commit ensures coherency between `typer.context` and
`typer.infer.context` by making the latter delegate to the former.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
And the same for !=
If we tried to declare these signatures in non-fictional classes,
we would be chastised about collapsing into the "same signature after
erasure".
This will have an influence of typing, as the typechecking of
arguments is sensitive to overloading: if multiple variants are
feasible, the argument will be typechecked with a wildcard expected
type. So people inspecting the types of the arguments to `==` before
this change might have seen an interesting type for
`if (true) x else y`, but now the `If` will have type `Any`, as we
don't need to calculate the LUB.
I've left a TODO to note that we should really make `Any#{==, !=}`
non-final and include a final override in `AnyVal`. But I don't think
that is particularly urgent.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
% scalac-hash v2.11.0-M7 test/pending/neg/t8219-any-any-ref-equals.scala
test/pending/neg/t8219-any-any-ref-equals.scala:5: error: overloaded method value == with alternatives:
(x$1: AnyRef)Boolean <and>
(x$1: Any)Boolean
does not take type parameters
"".==[Int]
^
one error found
Usually for Java-originated methods, we are allow Object and Any
to unify pre-erasure in method signatures. This is handled in
`matchesParams`, and is predicated on whether the method type is
an instance of `JavaMethodType`
For instance, we are allowed to:
scala> class C { override def equals(a: Any) = false }
defined class C
On account of:
scala> typeOf[Object].decl(nme.equals_).info.getClass
res7: Class[_ <: $r.intp.global.Type] = class scala.reflect.internal.Types$JavaMethodType
But:
scala> typeOf[Object].decl(nme.EQ).defString
res8: String = final def ==(x$1: AnyRef): Boolean
scala> typeOf[Object].decl(nme.EQ).info.getClass
res9: Class[_ <: $r.intp.global.Type] = class scala.reflect.internal.Types$MethodType
More special casing is probably needed.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Extracted with tweezers from ScalaTest and Scalacheck implicits.
% scalac-hash v2.11.0-M7 test/pending/pos/t8219.scala
error: type mismatch;
found : Any
required: AnyRef
Note: Any is not implicitly converted to AnyRef. You can safely
pattern match `x: AnyRef` or cast `x.asInstanceOf[AnyRef]` to do so.
error: type mismatch;
found : Any
required: AnyRef
Note: Any is not implicitly converted to AnyRef. You can safely
pattern match `x: AnyRef` or cast `x.asInstanceOf[AnyRef]` to do so.
two errors found
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | | |
Fix regression for using Scala IDE on scala-library
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
If the class path is incomplete, the presentation compiler might crash during construction.
If the PC thread was already started, it will never get the chance to shutdown, and the
thread leaks. In the IDE, where the PC is started when needed, this can lead to a very
quick depletion of JVM threads.
See Scala IDE #1002016.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This reverts commit 66904556ef34dc81cbb7c09257b013b3ddb76f78.
Conflicts:
src/reflect/scala/reflect/internal/TreeInfo.scala
As evidenced by the highlights of the stack trace in Scala IDE,
my assertion in the 66904556e wasn't universally true.
The change was only motivated by removing a special case, not in
order to fix some other problem. So the revert is the most straight
forward course of action for now.
I haven't pinned this down with a test outside of Eclipse, and
given the lateness of the hour wrt 2.11.0, I'll have to submit
without one.
2013-03-10 08:38:04,690 ERROR [main] - org.scala-ide.sdt.core - org.scala-ide.sdt.core - org.scala-ide.sdt.core - 0 - Error during askOption
scala.reflect.internal.Symbols$CyclicReference: illegal cyclic reference involving object Predef
...
at scala.reflect.internal.Symbols$Symbol.lock(Symbols.scala:482)
at scala.reflect.internal.Symbols$Symbol.info(Symbols.scala:1216)
at scala.reflect.internal.Symbols$Symbol.tpe(Symbols.scala:1200)
at scala.reflect.internal.Symbols$Symbol.tpeHK(Symbols.scala:1201)
at scala.reflect.internal.Types$Type.computeMemberType(Types.scala:784)
at scala.reflect.internal.Types$Type.memberType(Types.scala:781)
at scala.reflect.internal.TreeGen.mkAttributedSelect(TreeGen.scala:203)
...
at scala.reflect.internal.TreeGen.mkAttributedStableRef(TreeGen.scala:162)
at scala.tools.nsc.ast.TreeGen.mkWildcardImport(TreeGen.scala:39)
at scala.tools.nsc.typechecker.Contexts$Context.makeNewImport(Contexts.scala:308)
at scala.tools.nsc.typechecker.Contexts$class.rootContext(Contexts.scala:69)
at scala.tools.nsc.Global$$anon$1.rootContext(Global.scala:492)
at scala.tools.nsc.typechecker.Contexts$class.rootContext(Contexts.scala:64)
at scala.tools.nsc.Global$$anon$1.rootContext(Global.scala:492)
at scala.tools.nsc.typechecker.Analyzer$namerFactory$$anon$1.apply(Analyzer.scala:43)
at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:463)
...
at scala.tools.nsc.Global$Run.compileLate(Global.scala:1681)
at scala.tools.nsc.Global$Run.compileLate(Global.scala:1671)
at scala.tools.nsc.symtab.SymbolLoaders$SourcefileLoader.doComplete(SymbolLoaders.scala:284)
at scala.tools.nsc.symtab.SymbolLoaders$SymbolLoader.complete(SymbolLoaders.scala:187)
at scala.reflect.internal.Symbols$Symbol.info(Symbols.scala:1229)
at scala.reflect.internal.Symbols$Symbol.tpe(Symbols.scala:1200)
at scala.reflect.internal.Symbols$Symbol.tpeHK(Symbols.scala:1201)
at scala.reflect.internal.Types$Type.computeMemberType(Types.scala:784)
at scala.reflect.internal.Types$Type.memberType(Types.scala:781)
at scala.reflect.internal.TreeGen.mkAttributedSelect(TreeGen.scala:203)
at scala.reflect.internal.TreeGen.mkAttributedRef(TreeGen.scala:124)
at scala.reflect.internal.TreeGen.mkAttributedRef(TreeGen.scala:130)
at scala.reflect.internal.TreeGen.mkAttributedStableRef(TreeGen.scala:162)
at scala.tools.nsc.ast.TreeGen.mkWildcardImport(TreeGen.scala:39)
...
at scala.tools.nsc.Global$$anon$1.rootContext(Global.scala:492)
at scala.tools.nsc.typechecker.Analyzer$namerFactory$$anon$1.apply(Analyzer.scala:43)
at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:463)
...
at scala.tools.nsc.Global$Run.compileLate(Global.scala:1671)
at scala.tools.nsc.symtab.SymbolLoaders$SourcefileLoader.doComplete(SymbolLoaders.scala:284)
at scala.tools.nsc.symtab.SymbolLoaders$SymbolLoader.complete(SymbolLoaders.scala:187)
at scala.reflect.internal.Symbols$Symbol.info(Symbols.scala:1229)
at scala.reflect.internal.Symbols$Symbol.initialize(Symbols.scala:1365)
...
at scala.collection.immutable.HashSet$HashSet1.foreach(HashSet.scala:153)
at scala.collection.immutable.HashSet$HashTrieSet.foreach(HashSet.scala:306)
at scala.tools.eclipse.javaelements.ScalaJavaMapper$class.initializeRequiredSymbols(ScalaJavaMapper.scala:29)
...
at scala.tools.nsc.util.InterruptReq.execute(InterruptReq.scala:26)
at scala.tools.nsc.interactive.Global.pollForWork(Global.scala:340)
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Make the Abstract* classes public.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Several weaknesses in the implementation converge and force multiply.
1) Type constructor inference is not persistent. During implicit search
it will give up after the first seen parent even if some deeper base type
(even another direct parent) would satisfy the search.
2) Type inference is not aware of access restrictions. Inferred types are
calculated with disregard for whether the inferred type is visible at
the point of inference. That means that package-private types - which may be
private for any number of good reasons, such as not wanting them to appear in
bytecode thus creating binary compatibility obligations - are not private.
There is no such thing as a qualified private type.
package p {
trait PublicInterface[T] { def foo(): Int }
private[p] trait ImplementationOnly[T] extends PublicInterface[T] { def foo(): Int = 1 }
class PublicClass extends ImplementationOnly[PublicClass]
}
package q {
object Test {
def f[A, CC[X]](xs: CC[A]): CC[A] = xs
def g = f(new p.PublicClass) // inferred type: p.ImplementationOnly[p.PublicClass]
def h = g.foo()
// Bytecode contains:
// public p.ImplementationOnly<p.PublicClass> g();
// public int h();
// 0: aload_0
// 1: invokevirtual #30 // Method g:()Lp/ImplementationOnly;
// 4: invokeinterface #33, 1 // InterfaceMethod p/ImplementationOnly.foo:()I
// 9: ireturn
}
}
3) The trait encoding leads to a proliferation of forwarder methods, so much so that
1.5 Mb of bytecode was taken off of the standard library size by creating abstract classes
which act as central mixin points so that leaf classes can inherit some methods the
old fashioned way rather than each receiving their own copy of every trait defined method.
This was done for 2.10 through the creation of the Abstract* classes, all of which were
given reduced visibility to keep them out of the API.
private[collection] class AbstractSeq extends ...
This achieved its intended goal very nicely, but also some unintended ones.
In combination with 1) above:
scala> val rand = new scala.util.Random()
rand: scala.util.Random = scala.util.Random@7f85a53b
// this works
scala> rand.shuffle(0 to 5)
res1: scala.collection.immutable.IndexedSeq[Int] = Vector(4, 0, 1, 2, 5, 3)
// and this doesn't! good luck reasoning that one out
scala> rand.shuffle(0 until 5)
<console>:9: error: Cannot construct a collection of type scala.collection.AbstractSeq[Int]
with elements of type Int based on a collection of type scala.collection.AbstractSeq[Int].
rand.shuffle(0 until 5)
^
// Somewhat comically, in scala 2.9 it was flipped: to failed (differently), until worked.
scala> scala.util.Random.shuffle(0 to 5)
<console>:8: error: type mismatch;
found : scala.collection.immutable.Range.Inclusive
required: ?CC[?T]
scala> scala.util.Random.shuffle(0 until 5)
res2: scala.collection.immutable.IndexedSeq[Int] = Vector(4, 3, 1, 2, 0)
In combination with 2) above:
scala> def f[A, CC[X]](xs: CC[A]): CC[A] = xs
f: [A, CC[X]](xs: CC[A])CC[A]
scala> var x = f(1 until 10)
x: scala.collection.AbstractSeq[Int] = Range(1, 2, 3, 4, 5, 6, 7, 8, 9)
// It has inferred a type for our value which it will not allow us to use or even to reference.
scala> var y: scala.collection.AbstractSeq[Int] = x
<console>:10: error: class AbstractSeq in package collection cannot be accessed in package collection
var y: scala.collection.AbstractSeq[Int] = x
^
// This one is a straight regression - in scala 2.9,
scala> var x = f(1 until 10)
x: scala.collection.immutable.IndexedSeq[Int] = Range(1, 2, 3, 4, 5, 6, 7, 8, 9)
Since 1) and 2) are essentially unfixable - at least by me - I propose
to ameliorate these regressions by attacking the symptoms at the leaves.
That means making all the Abstract* classes public - keeping in mind that
they must already be assumed to be in the binary compatibility footprint,
since they have been leaking throughout their existence. This only impacts
the inference of inaccessible collections types - it doesn't help with the
more serious issue with type inference.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-6169 TODO: consolidate with fix for SI-1786 (#2518)
|
| | | | | | | | | |
|
