The checker also checks the metadata version, which
would be handled separately. Now it would never
emmit this error for klib-based backends.
^KT-61773
^KT-61596
^KT-55809
Note that 3 tests are still muted, but for another reason: for FIR
versions of the tests, we need to compile the "pre-release library" with
the next language version which is 2.1. But since currently
LanguageVersion.LATEST_STABLE is 1.9, the compiler refuses to read
metadata of version 2.1, regardless of its own language version. Which
is correct, but it leads to irrelevant errors in the test output -- the
ones about the incompatible metadata version, NOT about the
prereleaseness.
These 3 tests can be unmuted once the default language version is
switched to 2.0.
#KT-60780 Fixed
Before the change, the compiler threw exception in the unmuted tests,
because it tried to load metadata even though it had an unsupported
version. Use the same approach as in K1 (see
DeserializedDescriptorResolver).
Now the tests are unmuted, but note that test data differs from K1. K1
does not report errors related to the class `a.A` because it loads this
class as a _Java class_, so calling its constructor and methods somehow
works. This behavior is questionable since the compiler surely knows
that it is a Kotlin class, but with an unsupported metadata version.
Trying to interpret it as a Java class may lead to subtle problems. So
it's safer for now to avoid loading Kotlin classes with unsupported
metadata versions in K2.
#KT-60795 Fixed
This is needed because after changing default language version to 2.0,
we still need to test many scenarios from this test in K1.
Move K1-specific tests to OldCompileKotlinAgainstCustomBinariesTest, and
K2-specific tests to FirCompileKotlinAgainstCustomBinariesTest.
Mute failing K2 tests via `muteForK2`. It will throw exception if the
muted test will suddenly start passing.
This test uses multiple features which are obsolete and will be
discontinued soon:
- Language version 1.4
- Expect/actual declarations in the same module
- Declaring inline classes via "inline class"
Check that the client code compiles against the "broken" classpath
instead. Descriptor text dump is a part of the obsolete test
infrastructure and should not be used anymore.
"oldJvm*" tests are no longer testing the old JVM backend, so remove
that prefix from them. Also, remove the test "firAgainstOldJvm" because
it is now checking something that cannot NOT work.
The problem was that we were using unenhanced constructors that still
might contain java type refs.
Basically, most of the `firClass.declarations` usages are unsafe in that
meaning.
The test is very complicated because to reproduce the exception there
should be some conditions met:
- MyClass should be compiled with K1, so it has `@EnhancedNullability`
annotation serialized (that is unnecessary, but don't do any harm)
- `@Nls` scope should be properly resolved, so enum entries are converted
to resolved type refs
- That leads to attempt to check if null-check might be needed to be
inserted and to failure at FirTypeUtilsKt.getCanBeNull
While this quite controversial to have this check being performed for
freshly created annotations calls, the problem with improper constructor
lookup anyway existed and fixed correctly.
^KT-57213 Fixed
The commit is based on b09561c3c3
Co-authored-by: Dmitriy Novozhilov <dmitriy.novozhilov@jetbrains.com>
^KT-40904 Fixed
^KT-55177 Fixed
Review: https://jetbrains.team/p/kt/reviews/8731
True negative test already exist:
`compiler/testData/diagnostics/tests/multiplatform/hmpp/multiplatformCompositeAnalysis/intermediateWithActualAndExpect.kt`
This flag is true by default but is set to false for
- Java methods and constructors
- interface delegation methods that delegate to Java
The NAMED_ARGUMENTS_NOT_ALLOWED logic is mostly refactored to use the
new flag though some custom logic remains for determining the correct
message and to work around a corner case with fake overrides.
The flag is (de)serialized from/to metadata. For backward compatibility
with K1, delegated methods to Java types are deserialized as stable.
^KT-40480 Fixed
It affected the changed test in the following way: "strict metadata
version semantics" is a flag which is written to the .kotlin_module file
between the version and the protobuf data, see `ModuleMapping:73`. But
flags are written only for Kotlin 1.4+, i.e. if `isKotlin1Dot4OrLater`
returns true. So in the test, the flag was not written, thus we did not
detect that the module actually has incompatible metadata, and thus
incorrectly did not report an error.
It also has an effect that version requirements for nested classes will
now be written correctly to protobuf with metadata version 2.0+.
We have several tests which tests how compiler with LV = LATEST_STABLE
can consume binaries compiled with LV = LATEST_STABLE + 1 with
different CLI flags. For LV = 2.0 we have special rules for those flags,
so testdata was changed
After switching LV in repository to 2.0 this testdata should be rolled back
Fix merge conflict related to renaming of one of the tests
Regenerate tests affected by previous commit
Fix merge conflict related to renaming of one of the tests
Improve wording of the `-Xuse-k2 -language-version 1.*` CLI warning
Improve wording of LV2.0-specific CLI warnings some more
Fix output of one of the tests for -Xuse-k2 deprecation
Tweak wording of LV2.0-specific CLI warnings
* make it clear in every warning that -Xuse-k2 is deprecated
* add a reminder to remove -Xuse-k2 for `-Xuse-k2 -language-version 2.0`
* add both possibly wanted fixes for `-Xuse-k2 -language-version 1.*`
Remove deprecated -Xuse-k2 flag from one of the tests
Merge-request: KT-MR-8449
Merged-by: Stanislav Ruban <Stanislav.Ruban@jetbrains.com>
This reverts commit b09561c3c3.
It was decided to postpone this warning till 1.9
This is needed to provide proper IDE support
^KT-40904 Open
^KT-55177 Open
See the class org.ini4j.Ini used in intelliJ (derived kt class MyIni)
It contains inherited remove override with the following signature:
String remove(Object sectionName, Object optionName)
While also, from kotlin.collections.MutableMap we inherit
boolean remove(Object, Object)
And we should treat them as different methods to have correct signatures
in resulting class scope
* Change 1.6 to 1.7 constants
* Fix SAFE_CALL_WILL_CHANGE_NULLABILITY for testData
* Change EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_WARNING to EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_ERROR
* Change NON_EXHAUSTIVE_WHEN_STATEMENT to NO_ELSE_IN_WHEN
* Fix testData for SafeCallsAreAlwaysNullable
* Change T -> T & Any in test dumps
* Change INVALID_CHARACTERS_NATIVE_WARNING -> INVALID_CHARACTERS_NATIVE_ERROR
* TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_WARNING -> TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_ERROR
See the class at org/jmock/Expectations
public <T> T with(Matcher<T> matcher);
public boolean with(Matcher<Boolean> matcher);
When we extending such class it we start assuming
that fake generic override overrides both of the overridden that is wrong
from POV of Java and it fails at FIR ultimate build
NB: It's hard to write a test because such Expectation-like
class is impossible to write in pure Java
currently some old backend reporting schemes are used in IR backend that
rely on the PSI alement passing. This conflicts with updated generic
diagnostic infrastructure that is shared between FIR and IR backends.
As soon as such places will be abstracted out and the IR will be
completely switched to the new diagnostic infrastructure, this and
similar changes could be reverted.
Now, milestones of major Kotlin releases (e.g. 1.6.0-M1) will NOT
generate prerelease binaries anymore.
The reason for that is it's proven to be quite a complicated process to
turn on IR_PRE_RELEASE after the release is branched, perform double
bootstrap and fix tests, and then do it again in reverse just before
release. With the new release cadence, we don't have that much time to
do it and verify that everything works as intended.
Note that this only removes the "global" prerelease flag. Compiler will
still generate prerelease binaries if a non-stable language version is
used. For example, Kotlin 1.6.0-M1 with `-language-version 1.7` will
generate prerelease binaries.
This has no effect on correct code because extension properties cannot
have a backing field anyway and that is checked separately. But this
function is used in psi2ir to determine whether or not to create a
backing field for a property, and in case the code where the property is
declared is unreachable like in KT-44496 and has no explicit getter or
setter, it would previously return true for extension properties, which
on JVM would result in an actual field in the class file, which made no
sense.
After this change, the compiler will actually crash with an exception in
the IR validaton step because the symbol for the field is unbound. That
is a bit better than proceeding to generate potentially invalid
bytecode, but of course a proper fix would be to report an error in the
frontend.
#KT-44496
Mikhail Glukhikh