| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Fixes SI-6170: issue with dragging scaladoc splitter over central iframe
|
| | |
|
|\ \
| | |
| | | |
Changes Tree and Type members from vals to defs.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Explanatory email:
The reflection API defines a great many abstract vals. I would
like these all to be defs. I'm sending a pull request to that end.
Reasons: for starters, they should default to being defs. It's a
decision to use vals for which one should have to supply reasons.
The reason for THAT is that defs can be implemented with vals, but
not vice versa.
Why does this matter? I can't find my long writing on the subject
of TypeRef. In short, we waste a huge amount of memory on its
fields, because given the way TypeRef is defined, each one demands
a pre, a sym, and an args. Except that somewhere between 1/3 and
1/2 have prefix "NoPrefix", and somewhere between 1/3 and 1/2 have
args "Nil". We know it at creation time, but we give every typeref
the whole field anyway.
At present there's no way to fix this which has acceptable
performance - i.e. custom subclasses save us lots of memory, but
are too much slower for having to use an extractor - but there's
no reason we should have to choose, and I fully expect to fix it
eventually. Let's not make that fix into a breaking change by
abstractly defining "pre" and "args" as field-requiring vals.
|
|\ \
| | |
| | | |
Pullrequest/reflection docs
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Additionally includes improvements, formatting fixes, and link
additions and fixes.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
blocked by SI-6511
|
| | |
| | |
| | |
| | | |
and warning cleanup
|
| | | |
|
| | |
| | |
| | |
| | | |
Oh those pretty groups, u gotta luv'em...
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| |/ /
|/| | |
SI-6453 Documentation links for @switch are broken
|
| | | |
|
|\ \ \
| | | |
| | | | |
Scaladoc bugfixes for reflection
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
members
|
| | | | |
|
|/ / / |
|
|\ \ \
| | | |
| | | | |
Fixed SI-6505. Respond to ask calls by immediate failure after compiler shutdown.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
shutdown.
When the compiler is asked to shutdown, it may still have items on the working queue, and more can be added by clients in other thread that don't *know* the compiler is down yet. These requests were never serviced, leading to deadlocks or timeouts.
review by @odersky, @hubertp
|
|\ \ \ \
| | | | |
| | | | | |
Fix for SI-6499, regression in type inference.
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I can't do any better than a reproduced comment:
For some reason which is still a bit fuzzy, we must let Nothing
through as a lower bound despite the fact that Nothing is always
a lower bound. My current supposition is that the side-effecting
type constraint accumulation mechanism depends on these subtype
tests being performed to make forward progress when there are
mutally recursive type vars. See pos/t6367 and pos/t6499 for the
competing test cases.
|
|\ \ \ \
| |_|/ /
|/| | | |
SI-6099 - Scaladoc for scala.concurrent incomplete
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is a rebase and resubmission of @phaller's pull
https://github.com/scala/scala/pull/1485
With the reviewers' comments additionally addressed
|
|\ \ \ \
| |/ / /
|/| | | |
Deprecated instrumentation API
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The instrumentation logic needed by the Scala IDE Worksheet is currently part
of the Scala project, but it doesn't need to be. I already have a PR ready for
completely removing the instrumentation logic, but I considered it too risky at
this point for 2.10.0 release (an oversight can lead to the impossibility of
running the worksheet with Scala 2.10.0).
For the moment, I believe it's better to deprecate the whole instrumentation
API in 2.10.0, and the PR for removing the instrumentation logic will target
2.10.1 or 2.11.0.
Besides deprecating the instrumentation API, this commit also raised visibility
of `interruptsEnabled` member in `Global`. This change alone is sufficient for
moving the instrumentation logic outside of the compiler, and it is needed
because the Presentation Compiler thread should never be interrupted while
instrumenting a source.
This commit is related to SI-6458
|
|\ \ \ \
| |/ / /
|/| | | |
SI-6440: Revert change to `TraversableLike.filterNot`
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Commit df9f470f14262b9b1002f022c2620d8c38835805 introduced
a change to `TraversableLike.filterNot` which broke Stream
implementation that does override `filter` implementation
but does not override `filterNot` implementation. This shows
clearly that reusing code for strict and non-strict collections
is very problematic.
Added a test-case covering this problem.
Closes SI-6440.
Review by @retronym.
|
|\ \ \
| | | |
| | | | |
SI-6483 Prohibit super[T] references in value classes.
|
| | | |
| | | |
| | | |
| | | | |
This seems the safest course of action for 2.10.0.
|
|\ \ \ \
| | | | |
| | | | | |
Proposed fix for SI-6490.
|
|/ / / /
| | | |
| | | |
| | | | |
Issues a "companions must be in same file" error only if both class and module exist. This can certainly do no harm. I believe it should adress SI-6490, but, lacking a test case, I don't have evidence for that.
|
|\ \ \ \
| |_|/ /
|/| | | |
Another reflection bomb
|
| | | |
| | | |
| | | |
| | | | |
These are surely not necessary. Thanks Vlad!
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fixes the stuff that was irritating, when I was preparing examples
for reflection documentation.
Has zero impact at stability of scalac, because showRaw isn't used anywhere
in the compiler unless invoked explicitly.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This trait carries mirror-related changes of the API that happen
when api.Universe transforms into api.JavaUniverse.
From a coding standpoint this is a mere rehashing of the code, but
from a documentation standpoint this provides additional insights
into what's going on in reflection.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Because they are only available in macros.Universe, not in api.Universe,
therefore I'd argue that the confusion factor is stronger than the weirdness
of scala.reflect.api.Position extending scala.reflect.macros.Attachments.
|