SI-3439 Fix use of implicit constructor params in super call#4043
Merged
retronym merged 2 commits intoscala:2.11.xfrom Nov 2, 2014
Merged
SI-3439 Fix use of implicit constructor params in super call#4043retronym merged 2 commits intoscala:2.11.xfrom
retronym merged 2 commits intoscala:2.11.xfrom
Conversation
b813d43 to
2871501
Compare
When typechecking the primary constructor body, the symbols of constructor parameters of a class are owned by the class's owner. This is done make scoping work; you shouldn't be able to refer to class members in that position. However, other parts of the compiler weren't so happy about this arrangement. The enclosed test case shows that our checks for invalid, top-level implicits was spuriously triggered, and implicit search itself would fail. Furthermore, we had to hack `Run#compiles` to special case top-level early-initialized symbols. See SI-7264 / 86e6e92. This commit: - introduces an intermediate local dummy term symbol which will act as the owner for constructor parameters and early initialized members - adds this to the `Run#symSource` map if it is top level - simplifies `Run#compiles` accordingly - tests this all in a top-level class, and one nested in another class.
99cbe94 to
bfa7997
Compare
Contributor
|
PLS REBUILD/pr-scala@bfa7997 |
|
(kitty-note-to-self: ignore 60403289) |
Member
|
LGTM! |
retronym
added a commit
that referenced
this pull request
Nov 2, 2014
SI-3439 Fix use of implicit constructor params in super call
retronym
added a commit
to retronym/scala
that referenced
this pull request
Jan 15, 2015
Implicit search declines to force the info of candidate implicits
that either a) are defined beyond the position of the implicit search
site, or b) enclose the implicit search site.
The second criterion used to prevent consideration of `O` in
the super constructor call:
implicit object O extends C( { implicitly[X] })
However, after scala#4043, the
block containing the implicit search is typechecked in a context
owned by a local dummy symbol rather than by `O`. (The dummy and
`O` share an owner.)
This led to `O` being considered as a candidate for this implicit
search. This search is undertaken during completion of the info of
`O`, which leads to it being excluded on account of the LOCKED flag.
Unfortunately, this also excludes it from use in implicit search
sites subsequent to `O`, as `ImplicitInfo` caches
`isCyclicOrErroneous`.
This commit adjusts the position of the local dummy to be identical
to that of the object. This serves to exclude `O` as a candidate
during the super call on account of criterion a).
retronym
added a commit
to retronym/scala
that referenced
this pull request
Jan 29, 2015
Implicit search declines to force the info of candidate implicits
that either a) are defined beyond the position of the implicit search
site, or b) enclose the implicit search site.
The second criterion used to prevent consideration of `O` in
the super constructor call:
implicit object O extends C( { implicitly[X] })
However, after scala#4043, the
block containing the implicit search is typechecked in a context
owned by a local dummy symbol rather than by `O`. (The dummy and
`O` share an owner.)
This led to `O` being considered as a candidate for this implicit
search. This search is undertaken during completion of the info of
`O`, which leads to it being excluded on account of the LOCKED flag.
Unfortunately, this also excludes it from use in implicit search
sites subsequent to `O`, as `ImplicitInfo` caches
`isCyclicOrErroneous`.
This commit adjusts the position of the local dummy to be identical
to that of the object. This serves to exclude `O` as a candidate
during the super call on account of criterion a).
albsadowski
pushed a commit
to albsadowski/scala
that referenced
this pull request
Feb 17, 2015
Implicit search declines to force the info of candidate implicits
that either a) are defined beyond the position of the implicit search
site, or b) enclose the implicit search site.
The second criterion used to prevent consideration of `O` in
the super constructor call:
implicit object O extends C( { implicitly[X] })
However, after scala#4043, the
block containing the implicit search is typechecked in a context
owned by a local dummy symbol rather than by `O`. (The dummy and
`O` share an owner.)
This led to `O` being considered as a candidate for this implicit
search. This search is undertaken during completion of the info of
`O`, which leads to it being excluded on account of the LOCKED flag.
Unfortunately, this also excludes it from use in implicit search
sites subsequent to `O`, as `ImplicitInfo` caches
`isCyclicOrErroneous`.
This commit adjusts the position of the local dummy to be identical
to that of the object. This serves to exclude `O` as a candidate
during the super call on account of criterion a).
This was referenced Apr 7, 2017
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.
When typechecking the primary constructor body, the symbols of
constructor parameters of a class are owned by the class's owner.
This is done make scoping work; you shouldn't be able to refer to
class members in that position.
However, other parts of the compiler weren't so happy about
this arrangement. The enclosed test case shows that our
checks for invalid, top-level implicits was spuriously triggered,
and implicit search itself would fail.
Furthermore, we had to hack
Run#compilesto special casetop-level early-initialized symbols. See SI-7264 / 86e6e92.
This commit:
will act as the owner for constructor parameters and early
initialized members
Run#symSourcemap if it is top levelRun#compilesaccordinglyanother class.
Review by @lrytz.
Up for discussion: this might need to target
-Xsource:2.12as it could introduce a new candidate implicit in the super call.