| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Implements SIP 16: Self-cleaning macros: http://bit.ly/wjjXTZ
Features:
* Macro defs
* Reification
* Type tags
* Manifests aliased to type tags
* Extended reflection API
* Several hundred tests
* 1111 changed files
Not yet implemented:
* Reification of refined types
* Expr.value splicing
* Named and default macro expansions
* Intricacies of interaction between macros and implicits
* Emission of debug information for macros (compliant with JSR-45)
Dedicated to Yuri Alekseyevich Gagarin
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I turn them over to the responsible parties. Iulian knows about
the deadlock test; for philipp I presume,
07:10:29 [partest] concurrent-future.scala:97: error: not found: type FutureTimeoutException
07:10:29 [partest] throw new FutureTimeoutException(null)
07:10:29 [partest] ^
07:10:29 [partest] one error found
|
| | | | |
| | \ | |
| |\ \ \ |
|
| | | |/ |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | | |
| | \ \ | |
| |\ \ \ \
| | | | |
| | | | |
| | | | | |
'refs/pull/370/head'; commit 'refs/pull/371/head'
|
| | | |/ / |
|
| | |\ \ \
| | | |/
| | |/| |
|
| | | |\ \
| | | |/
| | |/| |
fix for get-scala-commit-* on Windows (tested with Windows 7)
|
| | | |/ |
|
| | |/ |
|
| |/
|
|
|
|
|
|
|
|
|
| |
This bug exists for a long time, but was triggered / discovered only lately
by the default argument of mkParams in 118aef558f.
This reverts the workaroud commit 19b6ad5ee4.
The fix is tested by test/files/presentation/memory-leaks which runs the
presentation compiler several times on Typers.scala. I could not reproduce
the memory leak in a smaller test case.
|
| |\ \ |
|
| | | | |
|
| | |/ |
|
| |/
|
|
| |
More care in warning about bad comparisons.
|
| | |
|
| |
|
|
|
| |
And eliminating redundancy. Reduced gratuitous usage of typeConstructor
on symbols which don't have type parameters.
|
| |\ |
|
| | |
| |
| |
| | |
make it much more resilient against spikes. Also removed usedmem file dumps.
|
| |/
|
|
|
|
|
|
|
|
|
| |
Profiler said checking hasAnnotation thousands of times
is expensive. I always wondered why some things used the
SPECIALIZED flag and others looked for the annotation.
No reason emerges which is apparent from the tests. So:
- mark an annotated symbol specialized at a convenient time
- always look for the flag
- create Symbol#isSpecialized to be consistent with all others
|
| |
|
|
|
|
|
|
|
|
| |
This commit fixes test cases mentioned in comment 03/Apr/12 to SI-4540.
Methods are fixed in leaf classes RichDouble|RichFloat|RichLong.
Their superclasses are not modified.
File is-valid-num.scala contains commented tests of
isValidLong|isValidFloat|isValidLong,
but they are not added anywhere now.
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | | |
eqTypeCode(Number) is equivalent to typeCode(Number).
CHAR code is impossible because java.lang.Character is not subclass of java.lang.Number.
|
| | |/ |
|
| |/
|
|
|
| |
Another "three yards and a cloud of dust" in my ongoing
battle against flag uncertainty.
|
| |
|
|
|
|
|
|
| |
One leads to the other.
Easing some more specific typing into Symbols.
Getting a handle on when where and how people rename
symbols to suit their fancies.
|
| |\ |
|
| | |
| |
| |
| | |
Also trimmed some cruft which had accrued in recent work.
|
| |\ \ |
|
| | |\ \ |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
We don't use Option[Symbol].
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The example from the ticket is committed as a neg test.
The problem is that a super.m on an abstract override
member m has no concrete implementation, that is, the
trait T is not mixed in after a class C with a concrete m.
The error is noticed at phase mixin when the super accessor
is added to the concrete mixer. (Pun alert?) When super.m
is rebound, no concrete matching symbol is found up the
linearization.
Previously, it was asserted that such a symbol should
be found, but since this is our first opportunity to
detect that there is none, an error should be emitted
instead. The new message is of the form:
Member method f of mixin trait T2 is missing a concrete super implementation.
Additionally, a couple of flag tests were changed to use isAbstractOverride.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It makes me a bit nervous that NumericRange[Int] will
get different wrong values in overflow situations compared
to Range due to the missing toLong though.
It could probably need some investigation if reordering the
operations can rule out wrong values, e. g. only fail when
the fold also fails.
Apart from that, it might make sense to just throw an exception
if an overflow happens instead of silent overflow.
|
| | |_|/
|/| |
| | |
| | | |
And test case for SI-5591.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Don't let OverloadedTypes reach the backend. When you want a
method from a particular symbol, avoid getMember, which may inflict
upon you an OverloadedType if an inherited member has the same
name. Instead, use the (just now appearing) definitions.getDecl.
|
| | | |
| | |
| | |
| | | |
That's why we have those nice test cases.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Reusing small, simple methods rather than lots of cut and paste.
|
| |\ \ \ |
|
| | | | | |
|
