| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit contains model changes required for adding class diagrams
to scaladoc. It also contains an improved implicit shadowing
computation, which hides the shadowed implicitly inherited members
from the main view and gives instructions on how to access them.
This is joint work with Damien Obrist (@damienobrist) on supporting
diagram generation in scaladoc, as part of Damien's semester project
in the LAMP laborarory at EPFL.
The full history is located at:
https://github.com/damienobrist/scala/tree/feature/diagrams-dev
Commit summary:
- diagrams model
- diagram settings (Settings.scala, ScalaDoc.scala)
- diagram model object (Entity.scala, Diagram.scala)
- model: tracking direct superclasses and subclasses,
implicit conversions from and to (ModelFactory.scala)
- diagram object computation (DiagramFactory.scala, DocFactory.scala)
- capacity to filter diagrams (CommentFactory.scala,
DiagramDirectiveParser.scala)
- diagram statistics object (DiagramStats.scala)
- delayed link evaluation (Body.scala, Comment.scala)
- tests
- improved implicits shadowing information
- model shadowing computation (ModelFactoryImplicitSupport.scala,
Entity.scala)
- html generation for shadowing information (Template.scala)
- tests
Also fixes an issue reported by @dragos, where single-line comment
expansion would lead to the comment disappearing.
Review by @kzys, @pedrofurla.
|
|\
| |
| | |
A tribute to https://github.com/scala/scala/pull/414
|
|/ |
|
|\
| |
| | |
Suppress non-local return unchecked warnings.
|
| |
| |
| |
| |
| | |
There doesn't seem to be any way to do that by adding
a synthetic annotation.
|
|\ \
| | |
| | | |
Breaks.break should return Nothing, not Unit
|
| |/ |
|
|\ \
| |/
|/| |
Fix for reflection. Review/Use by @adriaanm
|
|/ |
|
|\
| |
| | |
Fix libs in build
|
| |
| |
| |
| |
| |
| | |
* MSIL is now compiled/embedded with compiler
* Tested building new STARR, everything groovy
* Can probably remove msil/forkjoin/fjbg from STARR now that they're properly embedded/built.
|
|/
|
|
|
| |
* forkjoin.done/forkjoine.clean can test forkjoin source
* fjbg.done/fjbg.clean can test fjbg source.
|
|\
| |
| | |
SI-5696 Detect excess constructor argument lists.
|
| |
| |
| |
| | |
An apply method fooled the usual mechanism.
|
|\ \
| |/
|/| |
SI-5162 Exclude super.foo from the erasure cast of SI-4283
|
|/
|
|
|
|
|
|
|
| |
If the target method is defined in Java, treat the super reference
as an error, otherwise allow it in the knowledge that Scala loosens
the access restrictions on its generated classes.
Moves the test for that bug out of pending-ville. It's sufficient
to place Test in the empty package to exercise the right code paths.
|
|\
| |
| | |
SI-4831 Fix ambiguous import detection for renamed imports.
|
| | |
|
|\ \
| | |
| | | |
An IntelliJ module for reflect.
|
| |/ |
|
|\ \
| | |
| | | |
better unreachability for selections
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Consts are hashconsed modulo static-approximation-for-dynamic-value-equality
thus, two value-equality tests in patterns should reuse the same ValueConst
if and only if the tested values are guaranteed to be equal in all possible executions
the implementation uses unique types to track unique consts
for an Ident with a stable symbol, we simply use the corresponding singleton type
for a Select, we have to indirect some more: we store all the unique trees we've encountered and a unique type for each of them
this unique type is then used to find the uniqut const that approximates the run-time value
this may seem roundabout, but we need to standardize on types for representing "value" tests,
as a type test against a singleton type must give rise to the same ValueConst
as a value test using a tree that refers to the same symbol as the singleton type test
|
|\ \
| |/
|/| |
tests for fixed bugs
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|\
| |
| | |
A quickfix for 09bf95675b
|
|/ |
|
|\
| |
| | |
A remedy for Illegal class modifiers in locker
|
| |
| |
| |
| |
| | |
More details here:
http://groups.google.com/group/scala-internals/browse_thread/thread/fbd6d9f923f1cc89
|
|\ \
| | |
| | | |
fixes a bug with bat files invocation from ant
|
| |/
| |
| |
| |
| |
| | |
http://ant.apache.org/manual/Tasks/exec.html
Note that .bat files cannot in general by executed directly.
One needs to execute the command shell executable cmd using the /c switch.
|
|\ \
| |/
|/| |
SI-5167 An impl class method should refer to its own parameter symbols.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Rather than those of the original method in the trait.
If they are shared, parameter renaming in the implementaion class
is visible in the original method. This led to a crash in the resident
compiler when looking up the default argument getter.
|
|\ \
| | |
| | | |
SI-5652 Mangle names of potentially public lambda lifted methods.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This can happen if they are accessed from an inner class. If a
subclass is happens to lift a public method to the same name,
a VerifyError ensues.
The enclosed tests:
- demonstrate the absense of the VerifyError
- show the names generated for the lifted methods (which are
unchanged if not called from an inner class, or if lifted
into a trait implementation class.)
- ensure that the callers are rewritten to call the correct
method when multiple with the same name are lifted.
It's not ideal that this phase needs a priori knowledge of the
later phases to perform this mangling. A better fix would defer
this until the point when the methods are publicised, and leave
the unmangled private method in place and install an public,
mangled forwarder.
|
|\ \ \
| | | |
| | | | |
Fix SI-5853.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This solves two issues.
First, up to now the newly generated symbols for normalized
members were not being added to the declaration list of the
owner during `specialize`. Now they are.
Second, during `extmethods`, the extension methods generated
get an additional curried parameter list for `$this`.
Trouble was, after that, during `uncurry` and before `specialize`,
these curried parameter lists were merged into one list.
Specialization afterwards treats extension methods just
like normal methods and generates new symbols without the
curried parameter list.
The `extensionMethod` now takes this into account by checking
if the first parameter of a potential extension method has
the name `$this`.
Review by @dragos.
Review by @odersky.
|
|\ \ \ \
| | | | |
| | | | | |
The new reflection
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Compile Global or Typers twice in resident mode yielded a CyclicReference error, in phase erasure. The error was due to a cyclic call of isDerivedValue class. Checking I noted that isDerivedValue class is called very often, and mostly unneccessesarily. I tightened teh condition to not force the type of the class if it is a trait or package. This made the CyclicReference go away.
Widened criterion that enables validation of derived value classes. Previous version made two neg tests slip through.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Reduce time spent in lubs by making depth more adaptive. It now takes into account separately the depth of the lub types and the maximal depth of theior base type sequences. It cuts depth more aggressively if it is the base types instead of the types themselves that grow deep.
The old truncation behavior is retained under option -Xfull-lubs
Another change is that we now track depth more precisely, which should also help or at least allow better statistics.
Also added statistics that measure #lubs and time spent in them.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
the pattern `(_: T)` is made checkable using (ct: ClassTag[T]).unapply
by rewriting it to `ct(_: T)` (if there's a ClassTag[T] available)
similarly for extractors: if the formal type of the unapply method
is an uncheckable type, wrap in the corresponding classtag extractor (if available)
don't trigger rewrite on non-toplevel unchecked types
(i.e., only look at type constructor part of T when looking for unchecked types)
TODO: find outer match to figure out if we're supposed to be unchecked
would like to give users a chance to opt-out from the wrapping,
but finding the match to which this pattern belongs turned out to be tricky...
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
before, an unapply call would be derived from a case SomeClass(_, ..., _) pattern,
where SomeClass is a valid constructor reference, and thus also a reference to an
unapply-bearing companion object
this assumption is going to be violated once we start using class tags to make
uncheckable type tests checkable, since we could encounter unapply calls like
{<method calls that construct classTag>}.unapply(<arg>)
|
| | | | | |
|