-
Notifications
You must be signed in to change notification settings - Fork 1.1k
SIP Implementation: Precise type annotation #15765
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
Closed
Conversation
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
ac31672
to
8ec5b35
Compare
b7cf6dd
to
65850f8
Compare
d4016a6
to
aada2ca
Compare
f18a306
to
3df158a
Compare
Added formal proposal scala/improvement-proposals#48 |
6a65432
to
0555be1
Compare
add `paramPrecise` to `ParamInfo` add `paramPrecises` to LambdaType and propagate it through all dependent code that construct new lambdas (poly, method, higher-kinded), and including the user-facing macro quotes API
…ns on type parameters.
precise indicator context is added to the proto. precise mode is activated when precise typing is required, and disabled when there in no-longer an expression context (like Block stats).
for this purpose, additional context was required in `TyperState`. a stack was used for the conversion history. Also, a more general fix for scala#12802 was applied.
…f precise implicit conversions, the mechanism changed slightly so it caused the reported to change to error order)
…e information that the opaque may have. E.g.: `opaque type Foo[@PRECISE T] = T`
…ecise type is used with compiletime-ops (the reason is that default covariant widening kept this bug from surfacing)
OK, I did a complete rebase and split the PR into change-related commits. I'll update the SIP proposal to reflect the latest changes. |
This SIP is withdrawn. See scala/improvement-proposals#48 (comment) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
This PR adds support for the Precise Type Annotation SIP.
Links
Official Proposal: scala/improvement-proposals#48
Discussion: https://contributors.scala-lang.org/t/pre-sip-exact-type-annotation/5835
Implementation
The implementation includes the following:
scala.annotation.precise
annotation class to be applied on type parameters. This class is only available under@experimental
, but the underlying implementation can still affect performance of the compiler for existing applications.@precise
inPlainPrinter
.def paramPrecises: List[Boolean]
toLambdaType
and thus propagate precise parameter indications toPolyType
andHKLambdaType
.paramPrecises
forMethodType
always yieldsNil
. This is the most disruptive change that affects most of the files. An alternative and more fragile approach could have used mutation similarly to variance propagation.apply
constructors withparamPrecises
argument for thePolyType
/HKLambdaType
Quotes
API under@experimental
. When this SIP is officially accepted, at the next minor release the apply methods can be combined withparamPrecises
as an optional argument.Precise
mode as bit 31. This is used to track whether we need to apply precise typing or not.precise
default arguments methods by enabling precise mode for them inNamer
.sbt-test/precise
.compiletime.ops
bug (that surfaced due to changes made by this SIP).def isPrecise: Boolean
toType
. This is overriden is various situations. All are covered by the tests.TyperState
. This is used to store arguments that experienced implicit conversions that should have been precisely typed.ProtoTypes
,Application
andTyper
to accommodate various situations where precise typing needs to be applied. In situations where the compiler knows the method before typing the arguments, then typing only occurs once, and according to the precise types. However, when we have unknown method until arguments are typed (overloading, extension methods, and implicit conversions), then we need to redo the typing with the proper precise typing enforced.Testing
I've been "dogfooding" this myself as the implementation progressed via our library that required a lot of precise argument usages. Consequently, this PR has quite extensive checks that try to cover a wide range of language feature interactions with
@precise
. Please look at the tests and suggest other interactions I may have missed covering.Performance tests have yet to be carried out
Related Issues
Resolves scala/bug#10838
Resolves #8231
Acknowledgement
The work on this PR was sponsored by DFiant.