Last declaration in block is resolved in DEPENDENT mode because it has
influence on return type and therefore fake call for destructuring declaration
wasn't completed (see `getBlockReturnedTypeWithWritableScope`)
Now we resolve fake call for destructuring declaration in INDEPENDENT
mode as it doesn't have effect on return type
#KT-15480 Fixed
It has been introduced in 2286027bed
and should've help to avoid verify error
Now it became both impossible and unnecessary:
- It's impossible now since we can't determine in codegen
if we'll needa state machine
(it depends from inline functions' contents)
- It's unnecessary since we'll introduce the state machines for cases
described in the 2286027bed tests
NB: There's still a problem that now we work a bit suboptimally
because actually these samples can be generated without state
machines
Local delegated property accessors calling suspend operators getValue
or setValue should be suspend functions themselves.
KT-17605 Getter and setter of suspend delegated property are not suspend
This makes "-verbose" not required for JPS to run correctly and
therefore allows to print more useful debugging stuff in the compiler
and read them in CLI, for example. The output will also be more readable
because there'll be no "output" messages
The regression appeared after
b5a8ffaddc
when we started trying both static and member methods until
first success and when there is no successful
we were just leaving the last one (e.g. private member)
But the actual problem is that we were commiting the trace
in case of single (but incorrect) result in resolution mode of
SHAPE_FUNCTION_ARGUMENTS when we couldn't yet choose the
correct static method
Also we shouldn't choose a shape for callable reference
using only the knowledge that result is single:
it may lead to the wrong inference result
(see test with Pattern::compile)
#KT-17597 Fixed
`isScript` gets invoked for each call
(see org.jetbrains.kotlin.resolve.calls.CandidateResolver#checkOuterClassMemberIsAccessible)
And currently it may work for O(|top-level-declarations|),
that is rather slow e.g. for native stubs for gtk
#KT-17562 Fixed
This is not needed anymore because we use a special TypeCheckerContext
which correctly matches header class to impl typealias.
Also fix 'platformModule' in areCompatibleClassifiers: it's not b's
module (b is already the expansion of a typealias), but the module of
"other", original 'impl' classifier
Also do not call isHeader/isImpl because the returned declarations are
guaranteed to be isHeader in findCompatibleHeaderForImpl and isImpl in
findCompatibleImplForHeader
Build the compatibility map when looking for header given an impl, in
the same way as it's done for the search of impl given a header. The map
is mostly unused now (only its value at key=Compatible is used), but
will be used in the future to improve the diagnostic messages here
use it from the installed plugin for dependent modules (frontend)
use it from bootstrap in the plugin being built
also drop unused daemon-client from the plugin
This makes it consistent with ant build and allow building idea project
without prior ant dist
Mikhail Zarechenskiy