constructors & getters-setters #187
Conversation
Use ref and appliedTo instead.
The idea to traverse with currently enclosing methid is also used in LambdaLift and could be used elsewhere.
…lled. Instead of requiring to be called a given phase, change the context if that is not the case.
Lifting an application `f(arg1).f(args)` requires lifting of the whole prefix `f(arg1)`, because `f` might have a side effect.
Advantage: Can rename typed as well as untyped trees.
Previously, we determined the default getters solely from the method TermRef type. This is wrong if the method is prefix is not a path -- the prefix of the term ref will be a TypeRef and the getter selection will be a SelectFromType tree, which makes no sense.
It changes meaning drastically so should always be visible.
Some transformations encounter applications where new arguments ahve to be supplied. The method type already accounts for these argument but the Application node passed into TreeTransform#transformApply is constructed with a cpy.Apply operation which does a type assignment. That type assignment fails with a parameter mismatch unless relaxedTyping is on.
Environment parameters do not count in th eresult type.
The current formulation of lambda lift is easier to do if that's the case.
Need to drop all non-class type declarations.
Params are already added by Desugar. No special treatment needed here. Besides primaryConstructor.typeParams is always empty, because term symbols do not have type parameters. The fix turns t2660.scala into an error. I believe the error is correct, hence the test was moved with a comment to neg.
Primary constructor was picking last constructor instead of first one. This is now fixed. Also, added paramAccessors utility method.
Needed to fix a problem in CapturedVars to make this work.
Like the corresponding parameters, these also need to be rewritten to function types.
1) Type parameters are now copied to accessors 2) Constructors also work for traits 2) makes it possible do to mixin after constructors.
TypeVars can appear as keys in baseType caches. The problem is that their base types depend on their instantiation, which is not always know yet when the test is performed. So results of baseType on type variables should never be cached. Todo: check whether there are any other caching problems involving typevars.
Typevars can be parts of larger types or underlying types of other types, which renders these other types uncacheable. The new logic takes account of that.
Private fields that are accessed only from the constructor, and are accessed only after they are properly initialized are now moved into the constructor. This avoids creating a redundant objetc field. Good example: gcd in Rationals (see constrs.scala).
TypeVar is a TypeProxy.
Allow to skip labels.
…ories. We better make this configurable. Because sometimes we want to compile only the files in the immediate directory.
1) Avoids unneccessary second adapt. 2) Avoids error when used in TreeChecking when we try to compare types in previous tree and new tree - if we used `typed`, the previous tree would not have a type!
Similar to Erasure, we do not check conformance wrt <:< to a FunProto. Nothing is lost, because we typecheck the arguments and result anyway. And this led to failing tests after GettersSetters was added.
Was lost in merge chaos between pattern macther and rest
And bring back two tests for typing of patterns
1) strip TypeVars where necessary before widening 2) allow the combination of widening and dealiasing, in any order.
... because Any is not an erasedType (this is now checked)
Avoids a stale symbol error when compiling all files in tools together.
Previously caused an illegal backwards timetravel in bringForward when compiling all files in tools together twice.
They are in SymUtils
Tests now always include erasure (before quite a few tests failed when erasure was enableed). By contrast lazy vals creates problems with erasure, disabled for now. Some other small polishings on integration of pattern matcher with rest of dotc. Deep recompilation of tools still fails, currently disabled.
|
This branch also includes clean history of #176. |
|
OK if you want to try to rebase using this branch as a basis, go ahead! It The ElimLocals and Flatten transforms had been added in the last commit of Thanks! On Sun, Oct 12, 2014 at 11:17 AM, Dmitry Petrashko <notifications@github.com
Martin Odersky |
@odersky I guess you mean fixes from #186 They are all in this branch. It's not the branch to rebase on, this is the branch that already includes everything in our pull requests.
They were introduced several times in different packages. The last but one commit that was indicating that it's cleaning up patmat acutally removed them once again. I've modified the commit to not remove them and didn't include the last commit that introduced them back in different package.
So it's better to base on this branch. I've already had a look on commits multiple times during rebasings, they look good. I would propose to merge this branch into master(which means constructors&getters and setters will be in). I would like to also propose to alter a bit the way how we made bugfixes: have the branch |
|
Sent from my phone On 12.10.2014, at 12:28, Dmitry Petrashko notifications@github.com wrote:
|
|
Can you put the PR on staging please? |
bugfix: Fix issues with releasing
This branch has the same code as in #186 but has a lot cleaner history.
Difference is several additional tests that were somehow lost in #186 and
ElimLocalsandFlattenbeing intransformpackage