Simplify value class API handling and fix sbt/sbt#2497#95
Merged
gkossakowski merged 2 commits intosbt:1.0from Apr 14, 2016
Merged
Simplify value class API handling and fix sbt/sbt#2497#95gkossakowski merged 2 commits intosbt:1.0from
gkossakowski merged 2 commits intosbt:1.0from
Conversation
When `B2.scala` replaces `B.scala` in the new test `types-in-used-names-a`, the name hash of `listb` does not change because the signature of `C.listb` is still `List[B]`, however users of `C.listb` have to be recompiled since the subtyping relationships of its type have changed. This commit does this by extending the definition of "used names" to also include the names of the types of trees, even if these types do not appear in the source like `List[B]` in `D.scala` (since `B` has been invalidated, this will force the recompilation of `D.scala`). This commit does not fix every issue with used types as illustrated by the pending test `types-in-used-names-b`, `B.scala` is not recompiled because it uses the type `T` whose hash has not changed, but `T` is bounded by `S` and `S` has changed, so it should be recompiled. This should be fixable by including the type bounds underlying a `TypeRef` in `symbolsInType`. The test `as-seen-from-a` that did not work before shows that we may not have to worry about tracking prefixes in `ExtractAPI` anymore, see the discussion in sbt#87 for more information.
The previous approach to value class API (introduced by sbt/sbt#2261 and refined by sbt/sbt#2413 and sbt/sbt#2414) was to store both unerased and erased signatures so that changes to value classes forced recompilations. This is no longer necessary thanks to sbt#87: if a class type is used, then it becomes a dependency of the current class and its name is part of the used names of the current class. Since the name hash of a class changes if it stops or start extending AnyVal, this is enough to force recompilation of anything that uses a value class type. If the underlying type of a value class change, its name hash doesn't change, but the name hash of <init> change and since every class uses the name <init>, we don't need to do anything special to trigger recompilations either.
Contributor
Author
|
This PR depends on #87, only the last commit is new. |
Member
|
@Duhemm Could you review this? |
Contributor
|
👍 LGTM and makes perfect sense! |
smarter
added a commit
to smarter/sbt
that referenced
this pull request
Apr 14, 2016
This is a backport of sbt/zinc#95 The previous approach to value class API (introduced by sbt#2261 and refined by sbt#2413 and sbt#2414) was to store both unerased and erased signatures so that changes to value classes forced recompilations. This is no longer necessary thanks to sbt#2523: if a class type is used, then it becomes a dependency of the current class and its name is part of the used names of the current class. Since the name hash of a class changes if it stops or start extending AnyVal, this is enough to force recompilation of anything that uses a value class type. If the underlying type of a value class change, its name hash doesn't change, but the name hash of `<init>` changes and since every class uses the name `<init>`, we don't need to do anything special to trigger recompilations either.
smarter
added a commit
to smarter/sbt
that referenced
this pull request
Apr 14, 2016
This is a backport of sbt/zinc#95 The previous approach to value class API (introduced by sbt#2261 and refined by sbt#2413 and sbt#2414) was to store both unerased and erased signatures so that changes to value classes forced recompilations. This is no longer necessary thanks to sbt#2523: if a class type is used, then it becomes a dependency of the current class and its name is part of the used names of the current class. Since the name hash of a class changes if it stops or start extending AnyVal, this is enough to force recompilation of anything that uses a value class type. If the underlying type of a value class change, its name hash doesn't change, but the name hash of `<init>` changes and since every class uses the name `<init>`, we don't need to do anything special to trigger recompilations either.
smarter
added a commit
to smarter/sbt
that referenced
this pull request
Apr 15, 2016
This is a backport of sbt/zinc#95 The previous approach to value class API (introduced by sbt#2261 and refined by sbt#2413 and sbt#2414) was to store both unerased and erased signatures so that changes to value classes forced recompilations. This is no longer necessary thanks to sbt#2523: if a class type is used, then it becomes a dependency of the current class and its name is part of the used names of the current class. Since the name hash of a class changes if it stops or start extending AnyVal, this is enough to force recompilation of anything that uses a value class type. If the underlying type of a value class change, its name hash doesn't change, but the name hash of `<init>` changes and since every class uses the name `<init>`, we don't need to do anything special to trigger recompilations either.
smarter
added a commit
to smarter/sbt
that referenced
this pull request
Apr 15, 2016
This is a backport of sbt/zinc#95 The previous approach to value class API (introduced by sbt#2261 and refined by sbt#2413 and sbt#2414) was to store both unerased and erased signatures so that changes to value classes forced recompilations. This is no longer necessary thanks to sbt#2523: if a class type is used, then it becomes a dependency of the current class and its name is part of the used names of the current class. Since the name hash of a class changes if it stops or start extending AnyVal, this is enough to force recompilation of anything that uses a value class type. If the underlying type of a value class change, its name hash doesn't change, but the name hash of `<init>` changes and since every class uses the name `<init>`, we don't need to do anything special to trigger recompilations either.
smarter
added a commit
to smarter/zinc
that referenced
this pull request
Apr 15, 2016
smarter
added a commit
to smarter/zinc
that referenced
this pull request
Apr 15, 2016
smarter
added a commit
to smarter/sbt
that referenced
this pull request
Apr 15, 2016
This is a backport of sbt/zinc#95 The previous approach to value class API (introduced by sbt#2261 and refined by sbt#2413 and sbt#2414) was to store both unerased and erased signatures so that changes to value classes forced recompilations. This is no longer necessary thanks to sbt#2523: if a class type is used, then it becomes a dependency of the current class and its name is part of the used names of the current class. Since the name hash of a class changes if it stops or start extending AnyVal, this is enough to force recompilation of anything that uses a value class type. If the underlying type of a value class change, its name hash doesn't change, but the name hash of `<init>` changes and since every class uses the name `<init>`, we don't need to do anything special to trigger recompilations either.
smarter
added a commit
to smarter/sbt
that referenced
this pull request
Apr 15, 2016
This is a backport of sbt/zinc#95 The previous approach to value class API (introduced by sbt#2261 and refined by sbt#2413 and sbt#2414) was to store both unerased and erased signatures so that changes to value classes forced recompilations. This is no longer necessary thanks to sbt#2523: if a class type is used, then it becomes a dependency of the current class and its name is part of the used names of the current class. Since the name hash of a class changes if it stops or start extending AnyVal, this is enough to force recompilation of anything that uses a value class type. If the underlying type of a value class change, its name hash doesn't change, but the name hash of `<init>` changes and since every class uses the name `<init>`, we don't need to do anything special to trigger recompilations either.
smarter
added a commit
to smarter/sbt
that referenced
this pull request
Apr 16, 2016
This is a backport of sbt/zinc#95 The previous approach to value class API (introduced by sbt#2261 and refined by sbt#2413 and sbt#2414) was to store both unerased and erased signatures so that changes to value classes forced recompilations. This is no longer necessary thanks to sbt#2523: if a class type is used, then it becomes a dependency of the current class and its name is part of the used names of the current class. Since the name hash of a class changes if it stops or start extending AnyVal, this is enough to force recompilation of anything that uses a value class type. If the underlying type of a value class change, its name hash doesn't change, but the name hash of `<init>` changes and since every class uses the name `<init>`, we don't need to do anything special to trigger recompilations either.
gkossakowski
added a commit
that referenced
this pull request
Apr 17, 2016
Remove leftover dead code after #95
smarter
added a commit
to smarter/sbt
that referenced
this pull request
Apr 18, 2016
This is a backport of sbt/zinc#95 The previous approach to value class API (introduced by sbt#2261 and refined by sbt#2413 and sbt#2414) was to store both unerased and erased signatures so that changes to value classes forced recompilations. This is no longer necessary thanks to sbt#2523: if a class type is used, then it becomes a dependency of the current class and its name is part of the used names of the current class. Since the name hash of a class changes if it stops or start extending AnyVal, this is enough to force recompilation of anything that uses a value class type. If the underlying type of a value class change, its name hash doesn't change, but the name hash of `<init>` changes and since every class uses the name `<init>`, we don't need to do anything special to trigger recompilations either.
smarter
added a commit
to smarter/sbt
that referenced
this pull request
Apr 19, 2016
This is a backport of sbt/zinc#95 The previous approach to value class API (introduced by sbt#2261 and refined by sbt#2413 and sbt#2414) was to store both unerased and erased signatures so that changes to value classes forced recompilations. This is no longer necessary thanks to sbt#2523: if a class type is used, then it becomes a dependency of the current class and its name is part of the used names of the current class. Since the name hash of a class changes if it stops or start extending AnyVal, this is enough to force recompilation of anything that uses a value class type. If the underlying type of a value class change, its name hash doesn't change, but the name hash of `<init>` changes and since every class uses the name `<init>`, we don't need to do anything special to trigger recompilations either.
smarter
added a commit
to smarter/sbt
that referenced
this pull request
Apr 20, 2016
This is a backport of sbt/zinc#95 The previous approach to value class API (introduced by sbt#2261 and refined by sbt#2413 and sbt#2414) was to store both unerased and erased signatures so that changes to value classes forced recompilations. This is no longer necessary thanks to sbt#2523: if a class type is used, then it becomes a dependency of the current class and its name is part of the used names of the current class. Since the name hash of a class changes if it stops or start extending AnyVal, this is enough to force recompilation of anything that uses a value class type. If the underlying type of a value class change, its name hash doesn't change, but the name hash of `<init>` changes and since every class uses the name `<init>`, we don't need to do anything special to trigger recompilations either.
smarter
added a commit
to smarter/sbt
that referenced
this pull request
Apr 20, 2016
This is a backport of sbt/zinc#95 The previous approach to value class API (introduced by sbt#2261 and refined by sbt#2413 and sbt#2414) was to store both unerased and erased signatures so that changes to value classes forced recompilations. This is no longer necessary thanks to sbt#2523: if a class type is used, then it becomes a dependency of the current class and its name is part of the used names of the current class. Since the name hash of a class changes if it stops or start extending AnyVal, this is enough to force recompilation of anything that uses a value class type. If the underlying type of a value class change, its name hash doesn't change, but the name hash of `<init>` changes and since every class uses the name `<init>`, we don't need to do anything special to trigger recompilations either.
7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The previous approach to value class API (introduced by sbt/sbt#2261 and
refined by sbt/sbt#2413 and sbt/sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced recompilations.
This is no longer necessary thanks to #87: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of
<init>changes and since every class uses the name<init>, we don't need to do anything special to trigger recompilationseither.