Skip to content
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

Remove unnecessary use of lazy in classes defined by compiler-interface #114

Closed
smarter opened this issue May 2, 2016 · 0 comments
Closed

Comments

@smarter
Copy link
Contributor

smarter commented May 2, 2016

In https://github.com/sbt/zinc/blob/1.0/internal/compiler-interface/src/main/contraband/type.json and https://github.com/sbt/zinc/blob/1.0/internal/compiler-interface/src/main/contraband/definition.json many types are declared lazy, but it seems that only Structure#inherited really needs to be lazy (because a class might contain itself as an inherited member: class A { class B extends A }. I think that ClassLike#selfType, ClassLike#structure, and Structure#declared can be made strict (or at least, I was able to compute them strictly in the dotty compiler bridge and not blow up anything).

ttreyer added a commit to ttreyer/zinc that referenced this issue May 17, 2017
As stated in sbt#114, some types don't need to be declared lazy and
had been strictly computed in the dotty bridge. Those commits are an
attempt at backporting those observations in Zinc itself.

This commit removes the laziness of ClassLike.selfType.
The new test `circular-self-type` should prevent regressions.
ttreyer added a commit to ttreyer/zinc that referenced this issue May 17, 2017
As stated in sbt#114, some types don't need to be declared lazy and
had been strictly computed in the dotty bridge. Those commits are an
attempt at backporting those observations in Zinc itself.

This commit removes the laziness of ClassLike.selfType.
The new test `circular-self-type` should prevent regressions.
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

No branches or pull requests

1 participant