We need to invoke `llvm-profdata` tool from
the same toolchain as Clang (on macOS we use the one from Xcode).
(cherry picked from commit 91665b36af68b7fb3a56c0e7ed7ebb7d819adfb2)
Allow toolchain builder to add a suffix to toolchain name.
It is useful for rebuilding the same toolchain in different environment.
(cherry picked from commit 83148fc5bb4e8bcc5afcf119df53ec1bc854be17)
Also improve an error message in `IrType.erasedUpperBound`, which seems
like a frequent first place where the JVM IR backend crashes in case an
error type has made it past psi2ir.
This will help in diagnosing problems such as KT-45016.
Because generateDefaultGetterBody/generateDefaultSetterBody reference
the property's backing field, which in case of extension properties
leads to an error "Unbound symbols not allowed" because extension
property cannot have a backing field.
In some way, this check is similar to the `isExpect` check in
`generatePrimaryConstructor`.
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
Pass parentContext to SamWrapperCodegen from the outside instead of
using the one from parentCodegen. The difference is that in case of an
inline lambda, we're creating an InlineLambdaContext whose parent is a
ClosureContext, but the codegen for that lambda has that latter
ClosureContext as its context. So the getNonInlineOuterContext call in
SamWrapperCodegen.generateInnerClassInformation wasn't able to identify
that this is a context of a lambda that needs to be skipped, and
generated it as EnclosingMethod, which caused Java reflection to fail
because once that lambda was inlined, it was removed and thus didn't
make it to runtime.
#KT-44827 Fixed
Mikhael Bogdanov