Skip to content

More stdlib #995

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 50 commits into from
Closed

More stdlib #995

wants to merge 50 commits into from

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Dec 7, 2015

Based on #994. Just a few failing tests remain in scala-collections.-whitelist.

It seems to complciate things with no real purpose.
Done in order to keep the basics as simple as possible.
Treating existentially bound parameters as still instantiatable type
parameters does not seem to add anything fundamental, and makes the
type system less regular.
Also: fix adaptArgs and LambdaTrait to make it work.
Also: fix EtaExpansion.
Also: Add some debug code to Applications, awaiting further fixes.
typeSymbols always have empty type parameter list.
Previous implementation died because
TermRef had no denotation.
Printing bounds omits the "<:" otherwise.
Arg bounds do not count is bindings.
Arg bounds do not count is bindings.
Also: TypeLambda's $Apply binding should be covariant,
because the parameter is (not sure it matters though).
Taking typeAlias is illegal in that case.
This prevents propagation changes leading to long
recompiles when a printer is changed.
All Lambda abstractions, not just eta expansions, should
use actual parameter bounds, not the one retrieved from
the parameter symbols.
by bringing homogenization of # $Apply projections back.
Seems to be a hk-type inference issue. Needs further investigation but
is not high priority right now.
Describes its meaning more accurately.
It's unclear what the prupose of the previous restriction to Local only was.
And we need it to be set for all arg bindings so that immutable.Set does not
fail with a variance error.
When following an alias type, go directly to aliased type.
Going via the TypeAlias link causes the current variance ot be
narrowed to 0.
After changes to variance checker and fixes to stdlib.
If a partial application of a function has an error type,
make sure the whole tree also has an error type. Before,
sometimes the type was missing which led to a partial application error.
…ftype

Analogous to the previous situation where we do not report a data race
if the previous symbol comes from a superclass, we now do the same if
the previous symbol comes from a given self type. Makes overrideDataRace.scala pass,
and finally enables stdlib test with TraverableViewLike.scala added.
(1) Also allow symbols to switch between a member of a class
    and a member of its selftype. Seen in the wild in TraversableViewLike.scala.
    Test case in pickling/selfSym.scala

(2) Tidy up the error message.
ParamForwarding converts some parameters to nullary methods, yet
it does not update the references to these parameters. Their signature
is still NotAMethod, which is wrong. Causes subtle differences in
peckle tests: a param accessor get type T before pickling (which is
wrong), gets => T when reading back (which is right). Test case in
pickling/selfSym.scala.
This is needed to ensure that the type of a definition node
(ValDef, TypeDef, or DefDef) always refers to the symbol of
that definition.

Caused a spurious error in selfReq to go away (so error count was
updated).
We do not allow same-named class members in supertraits
of a mixin composition anymore. This commit gives a
better error message and avoids a crash in RefChecks.
`super` has no meaning for type membes. Harmonizing the
prefix to `this` avoids spurious incompatibilities.
A SuperType should behave just as the underlying ThisType in asSeenFrom.
Without this patch, compiling the ...ViewLike hierarachy crashes with
a YCheck error in resolveSuper. The underlying issue is that the very
complicated tangle of supercalls does not type check because an asSeenFrom
with a SuperType prefix does not compute the right type.
We now get a cyclic reference when inheriting from an inner class
with the same name in an outer supertype. Since this was legal
in Scala2 it's good to explain that particular case. Test case
in overrideClass.scala
@odersky
Copy link
Contributor Author

odersky commented Dec 11, 2015

/rebuild

@smarter
Copy link
Member

smarter commented Dec 18, 2015

Closing, rebased and merged as part of #1000.

@smarter smarter closed this Dec 18, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants