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
Improve the test which checks that we use correct metadata version if
`-language-version` is passed by checking all supported language
versions.
The change in libraries/reflect/build.gradle.kts is needed because
kotlinx-metadata-jvm of version 0.1.0 is based on pre-1.4 Kotlin, which
doesn't support the new module file metadata generated with metadata
version 1.4 and later, and module files need to be readable there to be
able to transform them for the shadow plugin.
Similarly override dependency on kotlinx-metadata-jvm in the
binary-compatibility-validator module.
Add -X flag to report extra compiler diagnostics which migth break compatibility.
Use the flag to unconditionally check constructors without fear of
prematurely evaluating lazy supertypes.
KT-19234
KT-42404
KT-44583
Take local/anonymous classes and their inner classes into account.
Simplify approximation: use first available super classifier instead
of first super class. This approximation should only happen for
private declarations that were not previously approximated by frontend.
So basically the only requirement for the approximated types is to be
denotable. Note that this only works if the types are not used later.
JVM uses a different string table implementatin as it needs exact
types of private members for reflection.
^KT-20996 Fixed
* a writing source mapper has `mapLineNumber(line, file, class)` that
inserts a new SMAP entry and returns a fake line number from it;
* a copying source mapper has `mapLineNumber(line)` that uses an
existing SMAP to resolve the line number and call the former method
on a different source mapper;
* those two types are disjoint.
The problem here is that we have separate bootstrap compiler and
artifacts (stdlib, for example) that are used in tests and implicitly
participate in them.
For example, this test started to fail when bootstrap compiler was
advanced to a version where pre_release flag is enabled. As a result,
dependent stdlib become pre_release as well and now we have additional
error about `Unit` type
Set first supported version to 1.3
Add property for oldest depecated language version in order to control unsupported ones
Report error on attempts to manually disable language feature from unsupported versions
Update test data, drop compatibility tests for features from unsupported versions
KT-36146 In progress
From now on, the old JVM backend will report an error by default when
compiling against class files produced by the JVM IR backend. This is
needed because we're not yet sure that the ABI generated by JVM IR is
fully correct and do not want to land in a 2-dimensional compatibility
situation where we'll need to consider twice more scenarios when
introducing any breaking change in the language. This is generally OK
since the JVM IR backend is still going to be experimental in 1.4.
However, for purposes of users which _do_ need to compile something with
the old backend against JVM IR, we provide two new compiler flags:
* -Xallow-jvm-ir-dependencies -- allows to suppress the error when
compiling with the old backend against JVM IR.
* -Xir-binary-with-stable-api -- allows to mark the generated binaries
as stable, when compiling anything with JVM IR, so that dependent
modules will compile even with the old backend automatically. In this
case, the author usually does not care for the generated ABI, or s/he
ensures that it's consistent with the one expected by the old compiler
with some external tools.
Internally, this is implemented by storing two new flags in
kotlin.Metadata: one tells if the class file was compiled with the JVM
IR, and another tells if the class file is stable (in case it's compiled
with JVM IR). Implementation is similar to the diagnostic reported by
the pre-release dependency checker.
Similar to references to error type, this may happen if library A uses
an entity from library B annotated with an annotation from C, but A is
compiled without C on the classpath.
Ilya Chernikov