azalea/kotlin-fork
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Minor: narrow deprecation scope of DataFlowValueFactoryImpl to constructor

Browse Source
This commit is contained in:
Dmitry Savvinov
2018-06-21 11:13:44 +03:00
parent 8964b2c7a4
commit fa72198505
1 changed files with 8 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
compiler/frontend/src/org/jetbrains/kotlin/resolve/calls/smartcasts/DataFlowValueFactoryImpl.kt
+8 -7
View File
@@ -23,8 +23,9 @@ import org.jetbrains.kotlin.types.KotlinType
import org.jetbrains.kotlin.types.expressions.ExpressionTypingUtils import org.jetbrains.kotlin.types.expressions.ExpressionTypingUtils
import org.jetbrains.kotlin.types.isError import org.jetbrains.kotlin.types.isError
@Deprecated("Please, avoid to use that implementation explicitly. If you need DataFlowValueFactory, use injection") class DataFlowValueFactoryImpl
class DataFlowValueFactoryImpl : DataFlowValueFactory { @Deprecated("Please, avoid to use that implementation explicitly. If you need DataFlowValueFactory, use injection") constructor() :
DataFlowValueFactory {
// Receivers // Receivers
override fun createDataFlowValue( override fun createDataFlowValue(
@@ -89,11 +90,11 @@ class DataFlowValueFactoryImpl : DataFlowValueFactory {
KotlinBuiltIns.isNullableNothing(type) -> KotlinBuiltIns.isNullableNothing(type) ->
DataFlowValue.nullValue(containingDeclarationOrModule.builtIns) // 'null' is the only inhabitant of 'Nothing?' DataFlowValue.nullValue(containingDeclarationOrModule.builtIns) // 'null' is the only inhabitant of 'Nothing?'
// In most cases type of `E!!`-expression is strictly not nullable and we could get proper Nullability // In most cases type of `E!!`-expression is strictly not nullable and we could get proper Nullability
// by calling `getImmanentNullability` (as it happens below). // by calling `getImmanentNullability` (as it happens below).
// //
// But there are some problem with types built on type parameters, e.g. // But there are some problem with types built on type parameters, e.g.
// fun <T : Any?> foo(x: T) = x!!.hashCode() // there no way in type system to denote that `x!!` is not nullable // fun <T : Any?> foo(x: T) = x!!.hashCode() // there no way in type system to denote that `x!!` is not nullable
ExpressionTypingUtils.isExclExclExpression(KtPsiUtil.deparenthesize(expression)) -> ExpressionTypingUtils.isExclExclExpression(KtPsiUtil.deparenthesize(expression)) ->
DataFlowValue(IdentifierInfo.Expression(expression), type, Nullability.NOT_NULL) DataFlowValue(IdentifierInfo.Expression(expression), type, Nullability.NOT_NULL)