| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
compilation setups by refining the logic what it means to be after a phase.
|
| |
|
|
|
|
| |
commits ago were a mistake).
|
|
|
|
| |
new STARR!
|
|
|
|
| |
generic value classes.
|
|
|
|
| |
They are too useful to ban.
|
|
|
|
| |
substitutres do.
|
| |
|
| |
|
|
|
|
| |
reference classes.
|
| |
|
| |
|
|
|
|
| |
tools.nsc.ast.TreeGen. Made mkCast generate the "right" version of casts according to current phase.
|
|
|
|
| |
if OK and remove commented code if that's the case.
|
| |
|
| |
|
|
|
|
| |
classes in the Scala library.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Conflicts:
test/files/run/Meter.scala
|
|
|
|
| |
just the erasure phase and its actions.
|
| |
|
| |
|
| |
|
|
|
|
| |
enforced. Super calls and specialized still missing.
|
| |
|
| |
|
|
|
|
| |
runs correctly (but no erasure yet).
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...since it works from source. The parser must be forcibly restrained
from adding a bogus constructor, but other than that it's pretty much
smooth sailing. To give an idea how smooth, if I change scala.Short like so:
trait Bippy extends Any
final class Short extends AnyVal with Bippy
Then it just works, at least until the fiction is revealed.
scala> def f(x: Bippy) = x
f: (x: Bippy)Bippy
scala> f(5)
<console>:9: error: type mismatch;
found : Int(5)
required: Bippy
f(5)
^
scala> f(5: Short)
java.lang.ClassCastException: java.lang.Short cannot be cast to scala.Bippy
at .<init>(<console>:9)
at .<clinit>(<console>)
at .<init>(<console>:11)
|
|\
| |
| |
| |
| |
| | |
Conflicts:
src/compiler/scala/tools/nsc/Global.scala
test/files/run/programmatic-main.check
|
| |\ \ \ \
| | | | | |
| | | | | |
| | | | | | |
'greedy/auto-fetch-jars', 'scalamacros/pullrequest/assorted' and 'VladUreche/feature/scaladoc-nofail' into develop
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
To use it, we need to update starr and then add nofail="yes" to the
build.xml scaladoc tasks.
|
| | | | |/
| | | | |
| | | | |
| | | | |
| | | | | |
Multiple fixes that have been accumulated during my investigations of 5273.
Too heterogeneous to describe here, too minor to split into changesets.
|
| | | |/
| | | |
| | | |
| | | |
| | | | |
Use mappers with uptodate and touch tasks to detect if any jars need to
be downloaded based on the modification time of the desired.sha1 files
|
| | |\| |
|
| | | |
| | | |
| | | |
| | | | |
This reverts commit e34098b7f6e37420198fa5c7c2820d0443b46cc4.
|
| | | |
| | | |
| | | |
| | | | |
This reverts commit 7946ac410ad74894cd0eb6dfd29447f173911b99.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In the pursuit of simplicity and consistency.
- Method names like getType, getClass, and getValue are far too ambiguous,
both internally and especially with java reflection names. Methods which
accept or return scala symbols should not refer to them as "classes" in
the reflection library. (We can live with the FooClass convention for naming
the well-known symbols, it's names like "getClass" and "classToType" which
are needlessly conflationary.)
- Meaningless names like "subst" have to be expanded.
- We should hew closely to the terms which are used by scala programmers
wherever possible, thus using "thisType" to mean "C.this" can only beget confusion,
given that "thisType" doesn't mean "this.type" but what is normally called
the "self type."
- It's either "enclosing" or "encl", not both, and similar consistency issues.
- Eliminated getAnnotations.
- Removed what I could get away with from the API; would like to push
those which are presently justified as being "required for LiftCode" out of the core.
- Changed a number of AnyRefs to Any both on general principles and because
before long it may actually matter.
- There are !!!s scattered all over this commit, mostly where I think
the name could be better.
- I think we should standardize on method names like "vmSignature, vmClass" etc.
when we are talking about jvm (and ostensibly other vm) things.
There are a bunch more places to make this distinction clear (e.g.
Symbol's javaBinaryName, etc.)
- There is a lot more I want to do on this and I don't know where the
time will come from to do it.
Review by @odersky, @scalamacros.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Couldn't live with a scala.Enumeration being a permanent
fixture in the reflection library. Rolled it by hand.
|
| | | |\ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | | |
'scalamacros/pullrequest/5334', 'scalamacros/pullrequest/5272' and 'VladUreche/issue/5287-cleanup' into develop
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
From now on, the usecases inherit the comments from their parents, such
as the explanation and the annotations: @param, @tparam, @return, etc.
An example of usecase comment inheritance is:
/**
* The test function tests the parameter param for ...
*
* @param theParam the implicit parameter to be tested for ...
* @return the result of the test
*
*
*
* @usecase def test(): Bool
*
* The test function tests the parameter taken implicitly from scope.
* Example: `test()`
*
* @return the result of the test for the current scope
*
*
*
* @usecase def test(theParam: SomeType): Bool
*
* This takes the explicit value passed.
* Example: `test(3)`
*
* @param theParam the explicit parameter to be tested for ...
*/
def test(implicit theParam: SomeType): Bool
Notice both usecases override the explanation with their own examples.
The first usecase also overrides the "@return" annotation while the 2nd
usecase overrides the "@param theParam" annotation. If they didn't
override the explanations and annotations, they would inherit the
values from the actual implementation, def test(implicit ...)
This will be followed by @inheritdoc, which enables more fine-grained
control over comment inheritance. The full explanation of using comment
inheritance and @inheritdoc and their interaction with variables is
given at https://wiki.scala-lang.org/display/SW/Tags+and+Annotations
in the "Comment inheritance" and "Inheritance Example" sections.
|