If a potential receiver is resolved to an error type, we consider
any other type as a subtype of it and therefore may select
any candidate that we happen to find in a scope.
In particular, in the case of scripts, or code with a context receiver,
the receiver candidate resolved to a cycle was accepted as a receiver
to an invoke on a random class from stdlib.
The fix skips adding invoke resolve task in this case, allowing
the tower to find the correct candidate in another scope.
#KT-64241 fixed
#KT-65576 fixed
Script parameters now can be resolved independently of the script.
But, as parameters are part of the script, their resolve will be called
before the script.
^KT-66276 Fixed
it is impossible to declare test data with another output yet
as `myScriptFile.test.ll.kts` won't be treated as custom definition as
it requires `test.kts` extension.
^KT-66232 Fixed
^KT-66276
The problem was that in K2 for some top-level script declarations we
need to add a dispatch receiver parameter (because frontend do not
assign any, but representing script as a class requires it to be the
script class) and at the same time, calls to these declarations rely on
properly set dispatch receiver parameter.
The simplest solution found is to have an additional traversal on the
relevan top-level declarations and assigning the dispatch receiver,
before running the main transformation.
#KT-64502 fixed
namely, add them to importing scopes directly and according to the
schema used for other implicit imports, rather than adding them
to the regular script file imports. See KT-65982 for explanation.
#KT-65982 fixed
The base class in scripting considered obsolete and therefore supported
via some ad-hoc mechanisms. In particular parameters to the base class
c-tor are passed via script provided properties. But in combination
with the resolution logic, this leads to issues described in KT-60452
This commits filters out such parameters from script resolution
scope and avoids this problem for now.
Bot it should be noted that proper diagnostics for properties shadowing
should still be implemented - see #KT-65809
#KT-60452 fixed
based on the regular compiler tests infrastructure, but adding
directives that can customize the definition from testdata.
So far only default imports and provided properties are supported, but
the infrastructure is easily extendable to other customizations.
Another limitations that provided properties are not supported for
the black box tests - the constructor parameters computing code
should be adapted to support it.
Note: in order to pick up the customized definition, the script files
should have an extension .test.kts
Ilya Chernikov