| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a window of danger when multiple related elements are
being typed where something which is conceptually one thing can
slip into two things, and those two things can be incompatible
with one another. Less mysteriously, c478eb770d fixed this:
def f = { object Bob ; Bob } ; val g = f
But, it did not fix this:
def f = { case class Bob() ; Bob } ; val g = f
See test case pos/existentials-harmful.scala for an "in the wild"
code example fixed by this commit.
The root of the problem was that the getter and the field would each
independently derive the same existential type to describe Bob, but
those existentials were not the same as one another.
This has been the most elusive bug I have ever fixed. I want to cry when
I think of how much time I've put into it over the past half decade or
so. Unfortunately the way the repl works it is particularly good at
eliciting those grotesque found/required error messages and so I was
never able to let the thing go.
There is still a cosmetic issue (from the last commit really) where
compound types wind up with repeated parents.
Closes SI-1195, SI-1201.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Major cleanup of reification:
* LiftCode phase has been removed
* Code has been deprecated and will be removed as we roll a new starr
* Logic related to type-directed lifting has been purged
scala.reflect.macro.Context#reify now provides the same services
as LiftCode provided (except that it returns Tree, not Code).
For testing purposes, I've retained the oh-so-convenient automagic lift.
test/files/codelib/code.jar now hosts Code.lift reimplemented in a macro,
so that the tests can continue working as if nothing has happened.
|
|
|
|
| |
Some of the type params might already be instantiated if explicit type application is done. Review by @adriaanm
|
| |
|
|
|
|
|
|
| |
"Induced" but not in my estimation "caused". Would like to understand
why the enclosed test case crashes under -optimise without this change
to AddInterfaces.
|
|\
| |
| |
| | |
'odersky/topic/t5120' into develop
|
| |
| |
| |
| | |
soundness problem t5120.
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
| |
A short recap:
* Macro expansion now works finely for instance macro invocations
* Macros are now hidden behind -Xmacros
* Bodies of macros now have "import _context._" in their preamble
* Macros are now loaded from classpath, much like regular libraries
* Macros can now override methods (in that case macro expansion
does not crash if macro is not found, it just falls back to super)
Review by @odersky.
|
|
|
|
|
|
| |
This reverts commit 2820770bffe2e7d180bccbcd7a3d83944b1dd8d6.
Last minute change had unintended consequences.
|
|
|
|
|
|
|
| |
Changes motivated by ICodeReader neglecting to utilize logic
which exists in its superclass. Now you can enjoy empty package
classes being inlined into other empty package classes.
Closes SI-4925.
|
|
|
|
| |
At least I think so.
|
| |
|
|
|
|
| |
A small dose of packedType closes SI-4869.
|
|
|
|
| |
Closes SI-3999. Review by @odersky.
|
|
|
|
|
|
|
| |
Misters hkarg and hkparam have to work harder to see
things from the same perspective, so they don't end up
in a huff over bounds which were the same all along.
Closes SI-5020, review by @moors.
|
|
|
|
|
| |
Well, "fix" is pretty generous, how about "workaround".
It does seem to do the job. Closes SI-4070, review by @moors.
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think I found an issue underlying more than one bit of sketchy
behavior amongst CC[_] and friends.
Plus, I managed to initialize TypeConstraints with the bounds of the
originating type parameter. I feel like that should cause something
nifty to happen somewhere, but I have seen neither confetti nor lasers
in greater quantities than I usually do. Will keep my remaining eye out.
Closes SI-5359, review by @moors.
|
|
|
|
| |
Making the inherited java vararg check cheaper.
|
|
|
|
| |
Closes SI-5175.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changing NullaryMethodType to be a SimpleTypeProxy because nearly all
its operations forward to its result type was it seems not such a good
idea, because it also meant that calling .underlying returned the result
type rather than the method type. The way this materialized was in
subtype checks of refinement types. A lub is calculated for two nullary
method types in the course of calculating a refinement, and then the
input types are checked against the calculated lub.
However in the lub refinement, the nullary method type has become a bare
typeref, and so the subtype check failed. Closes SI-5317.
This does give me confidence that all the malformed lubs one sees
logged under -Ydebug (and there are still many, especially with type
constructors) are alerting us to real bugs elsewhere in Types.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) introduce BodyTreeMaker to get rid of special casing for body
now each case is a list of TreeMakers rather than a pair of such a list and a tree
needed to do this since emitting switches requires access to the untranslated body
2) emitting switches
- alternatives are flattened: each alternative block ends with a jump to the next alternative (if there is one)
- to avoid stack overflow in typedMatch: detect when translateMatch returns a Match
the patch to uncurry would be nicer with an extractor, but that breaks due to a bug in old patmat
made trees into dags again -- NPE in erasure
tree.duplicate seems to break lambdalift because it
does not give fresh symbols (or trees?) to the valdefs
for the arguments of duplicated functions
duplicate enclosing tree, not subtrees
improved propagateSubstitution for AlternativesTreeMaker
- it now propagates to all its alternatives, so we don't have to do that in chainBefore
- by making propagation more regular, a bug in substitution in AlternativesTreeMaker manifested itself
it introduced a new binder, unnecessarily, which then was unbound -- now reusing binder of outer pattern
having removeSubstOnly in propagateSubstitution unveiled a bug: guard treemaker should substitute
move fixerUpper closer to what it fixes up
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
I messed up my trip to the future the first time around; now in the
future 5.f is not an error but an attempt to call method "f" on 5 like
nature intended. (Thank you simon for catching this.) And deprecated
leading 0 for octal. Closes SI-5205.
|
|
|
|
|
|
| |
Added the check against UnitClass in freeLocalsTraverser. Closes
SI-5245. Review by odersky.
|
| |
|
|
|
|
|
| |
no review
|
|
|
|
|
|
|
| |
Had AnnotationInfo extend Product3 since it's no longer a case class.
Tried to make reflection a little more robust. Closes SI-5223, review by
vogt.
|
|
|
|
|
|
|
| |
"According to the spec this code should not be legal. Disabling for
now." Need to come back and either make it work or (more likely) make
nsc reject the test)
|
|
|
|
|
| |
Looks like we will need blood, toil, tears, and sweat. No review.
|
| |
|
|
|
|
|
|
| |
A comment answering one of adriaan's philosophical musings on why
programs fail, and a test case informed by the comment. Review by moors.
|
|
|
|
|
|
|
| |
I should know better than to behave as if usable inferences can be drawn
from a comment like "SYNTHETIC because of DEVIRTUALIZE". Maybe it was
even true when it was written, but no more. Closes SI-5178, no review.
|
| |
|
|
|
|
|
|
|
| |
Another page in the storied history of "check the normalized type, then
act on the unnormalized type", in this case leading to a tight loop of
foreverness. Closes SI-5156, review by moors.
|
| |
|
|
|
|
|
| |
NullaryMethodType was escaping. Closes SI-5099, review by moors.
|
| |
|
|
|
|
|
| |
Closes SI-4970, review by moors.
|
|
|
|
|
| |
No review.
|
|
|
|
|
| |
Suppresses ProductN parent for case classes. No review.
|
| |
|
|
|
|
|
|
|
|
|
| |
at least one imminent TODO: undo hardwired generation of if/then/else,
and decide based on type whether to call flatMap/orElse or inline those
methods from Option
review by extempore
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a type var's constraint now also tracks whether the type var was
compared to a stable type
if it was, we probably shouldn't widen the type argument that's inferred
for this var, as the result will surely fail to type check
NOTE: must be enabled using -Xexperimental
review by extempore
|