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.
The main idea is the following: since we need to generate
(fake)continuations before inlining, we move IrClasses of suspend
lambdas and continuation classes of named functions into the functions.
Thus, it allows the codegen to generate them prior to inlining and
the inliner will happily transform them for us.
Because of that, lowerings which transform call-site function are likely
to change reference to lowered suspend lambdas or functions.
Hence, do not rely on references to lowered suspend lambdas or
functions, instead, rely on attributes.
Do not generate continuation for inline suspend lambdas.
Previously, inline suspend lambdas were treated like suspend functions,
thus we generated continuations for them. Now we just do not treat them
as suspend functions or lambdas during AddContinuationLowering.
We should add continuation parameter to them, however.
Do not generate secondary constructor for suspend lambdas, otherwise,
the inliner is unable to transform them (it requires only one
constructor to be present).
Generate continuation classes for suspend functions as first statement
inside the function.
This enables suspend functions in local object inside inline functions.
Since we already have attributes inside suspend named functions, we
just reuse them to generate continuation class names. This allows us
to close the gap between code generated by old back-end and the new
one.
If a suspend named function captures crossinline lambda, we should
generate a template for inliner: a copy of the function without
state-machine and a continuation constructor call. The call is needed
so the inliner transforms the continuation as well.
Refactor CoroutineTransformerMethodVisitor, so it no longer depends on
PSI.
FakeCallableDescriptorForObject instance, which is not ConstructorDescriptor,
is checked with call checkers when object's contents are being used.
Checker of missing supertypes should not be run against this fake descriptor.
Object's members belong to separate member scope, so their resolution doesn't
force containing class' supertypes evaluation. I.e. object's methods
may work fine even if some supertypes of containing class are missing.
Call checker and declaration checker are used in order to preserve backward compatibility.
Attempt to use classifier usage checker was not good enouth,
since not all errors found with it would actually be reported before.
For example types and constructor calls don't cause supertypes to resolve,
so missing supertypes would not lead to errors in case they are the only use of class name.
Updated tests failing due to missing Java dependencies in superclasses.
Generally, using state.classFileVersion would be enough because we
report an error when inlining bytecode into a class file with a lower
target version (see INLINE_FROM_HIGHER_PLATFORM). However, we take maxOf
with the original version of the class file, _just in case_ the user has
suppressed this error (for example, to workaround some other corner case
in the compiler).
#KT-30744 Fixed
Similarly to 38536638, skip annotation arguments that reference classes
which are not found in our compilation classpath.
This fix is especially needed because of the way _nested_ classes are
currently referenced in annotations. Since we don't generate all needed
InnerClasses attributes yet (KT-27936), we can't unambiguously resolve a
reference to a nested class in annotation arguments. This leads to an
ErrorValue loaded in the annotation descriptor. The old backend doesn't
care, since it doesn't look at that annotation or its arguments, but
psi2ir tries to convert all annotation arguments and it crashed with CCE
here, trying to cast IrErrorType to IrSimpleType.
Denis.Zharkov