Nikolay Lunyak
7b04201e77
Otherwise, when we come to `ClassCodegen.kt:173 for `GradleActionTest` and check `FUN FAKE_OVERRIDE name:<get-project>`, we then go to `JvmSignatureClashDetector.kt:37`, and call `mapRawSignature(overriddenFunction)` which ignores the original `@JvmName`. It does so because it relies on the property copy which forgets to copy the getter, but `@get:JvmName` is stored in it. Extra when-branches for `FAKE_OVERRIDE` are needed, because otherwise the annotations would not be copied in `Fir2IrDeclarationStorage.kt:723`. Extra when-branches for `DELEGATED_MEMBER` are needed, because otherwise the generated IR changes in some tests. For example, see: `FirLightTreeIrTextTestGenerated.Declarations.testKt35550`. The `assumesBackingField`-related change is backed by the `FirLightTreeIrTextTestGenerated.Stubs.testJavaEnum` test. `this.body = null` ensures the resulting IR matches K1. The change in `FirImplicitBodyResolve.kt` is needed, because otherwise the bootstrap compiler fails at `:compiler:frontend:compileKotlin`, but I didn't come up with a smaller test for it. If we don't make an explicit accessor copy, then when we later create a `Fir2IrLazyPropertyAccessor` for the fake override getter, it's `fir` will be a reference to the `FirProperty`, not `FirPropertyAccessor`. That's why `DumpIrTreeVisitor` will render `IntrinsicConstEvaluation` as a getter annotation as well. `FirPsiIrTextTestGenerated.testDelegatedGenericImplementation` renders type parameters from `<get-x>`, because when assigning `extensionReceiverParameter` of the setter `<set-x>` we come to `Fir2IrClassifierStorage.kt:638`, and in this cache there's the parameter with the `<get-x>` parent. Note that `typeContext.origin == DEFAULT` in `getCachedIrTypeParameter`. It's `DEFAULT` because at the line `Fir2IrDeclarationStorage.kt:335` the `function` variable is `null` (because there's no setter). The change in `declarationAttributes.kt` is backed by the `FirPsiIrTextTestGenerated.testKt45853` test. ^KT-57104 Fixed ^KT-57432 Fixed Merge-request: KT-MR-9210 Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
Diagnostic tests format specification
Each diagnostic test consists of a single .kt file containing the code of one or several Kotlin or Java source files. Each diagnostic, be it a warning or an error, is marked in the following way:
<!DIAGNOSTIC_FACTORY_NAME!>element<!>
where DIAGNOSTIC_FACTORY_NAME is the name of the diagnostic which is usually one of the constants in one of Errors* classes.
To test not only the presence of the diagnostic but also the arguments which will be rendered to the user, provide string representations of all of them in the parentheses delimited with ; after the diagnostic name:
return <!TYPE_MISMATCH(String; Nothing)!>"OK"<!>
Note: if you're unsure what text should be added for the parameters, just leave the parentheses empty and the failed test will present the actual values in the assertion message.
Directives
Several directives can be added to the beginning of a test file with the following syntax:
// !DIRECTIVE
1. DIAGNOSTICS
This directive allows to exclude some irrelevant diagnostics (e.g. unused parameter) from a certain test or to include others.
The syntax is
'([ + - ] DIAGNOSTIC_FACTORY_NAME | ERROR | WARNING | INFO ) +'
where
-
+means 'include'; -
-means 'exclude'.Directives are applied in the order of appearance, i.e.
+FOO -BARmeans includeFOObut notBAR.
Usage:
// !DIAGNOSTICS: -WARNING +CAST_NEVER_SUCCEEDS
// !DIAGNOSTICS: -UNUSED_EXPRESSION -UNUSED_PARAMETER -UNUSED_VARIABLE
2. CHECK_TYPE
The directive adds the following declarations to the file:
fun <T> checkSubtype(t: T) = t
class Inv<T>
fun <E> Inv<E>._() {}
infix fun <T> T.checkType(f: Inv<T>.() -> Unit) {}
With that, an exact type of an expression can be checked in the following way:
fun test(expr: A) {
expr checkType { _<A>() }
}
CHECK_TYPE directive also disables UNDERSCORE_USAGE_WITHOUT_BACKTICKS diagnostics output.
Usage:
// !CHECK_TYPE
3. FILE
The directive lets you compose a test consisting of several files in one actual file.
Usage:
// FILE: A.java
/* Java code */
// FILE: B.kt
/* Kotlin code */
4. LANGUAGE
This directive lets you enable or disable certain language features. Language features are named as enum entries of the class LanguageFeature.
Each feature can be enabled with +, disabled with -, or enabled with warning with warn:.
Usage:
// !LANGUAGE: -TopLevelSealedInheritance
// !LANGUAGE: +TypeAliases -LocalDelegatedProperties
// !LANGUAGE: warn:Coroutines
5. API_VERSION
This directive emulates the behavior of the -api-version command line option, disallowing to use declarations annotated with @SinceKotlin(X) where X is greater than the specified API version.
Note that if this directive is present, the NEWER_VERSION_IN_SINCE_KOTLIN diagnostic is automatically disabled, unless the "!DIAGNOSTICS" directive is present.
Usage:
// !API_VERSION: 1.0
6. RENDER_DIAGNOSTICS_MESSAGES
This directive forces Diagnostic printer prints parametrized diagnostics with all parameters.
Usage:
// !RENDER_DIAGNOSTICS_MESSAGES