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
- encapsulate semantic more into helpers
- allow lazy scopes iteration
- simplify reporting code in tower resolver
- fix some inconsistencies and wrong lookups
- remove redundant lookup recordings
- remove lookup scopes for non-star imports
The commit is a refactoring and doesn't change the behaviour of
neither IC nor CRI. Changes in the lookups are mostly due to the
previous obviously wrong lookups (see changed test data).
The commit "K2 scripting: treat default import similarly to K1"
introduced the new extension that provides default imports for scripts,
instead of the previous approach of explicit `FirImport` elements
creation. But registering it for the IDE case was forgotten. This
commit adds missing registration.
#KTIJ-28960 fixed
Generally the wrapping anonymous initializer can be used as a
"containing declaration" for some elements, but since the initialiser
for the last script expression could be dropped (the expression could
be converted to the result property), this may lead to the surprises,
e.g. as described in KT-65984
This fix marks the last initialiser as local, preventing it from being
referenced as "containing declaration".
#KT-65984
Current implementation checks only immediate supertype, while
in case of gradle build scripts DSL, the annotated superclass
is located deeper in the hierarchy.
The fix implements a recursive supertype check.
#KT-65983 fixed
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
otherwise they are easily swallowed by the reporting logic.
This commit was needed to ensure that the problem described in
KT-63665 is reproducible in IC test
But some JS IC logic relies on handling compiler exceptions as a signal
for scope expansions, and the newly introduced exception logging
broke a few tests. To mitigate it, the directive was introduced
to disable exception logging for particular test.
(reuse anonymous initializers as block wrappers) so the top-level script
elements are all declarations now. Rename the property accordingly (
together with the previous commit).
It makes script more similar to the class and thus simplify e.g.
control flow analysis and resolve code.
rename them since they generate variables with initialization, rather
than arbitrary statements, and this fact is used in scripts
and also add initialization helper, used for scripting support too.
slf4j libs are bundled unshadowed to main-kts jar to avoid annoying
slf4j stderr printout (slf4j is used in the maven dependencies resolver)
Exluding it from proguard processing solves problems with using it
directly from scripts.
#KT-60813 fixed
#KT-54819 fixed
The failure diagnostics from resolvers are ignored now if followed
by a successful result from a following resolver.
#KT-63352 fixed
the commit is idirectly tested by the test MainKtsIT.testUseSlf4j
from the followin commit "Scripting: ignore some diags if artefact is
resolved", namely without these changes, additional two warnings are
reported in this test.
that causes flaky tests because the default positioning strategy
was dependent on the order of the reported messages.
The code led to it was introduced in an attempt to extract common
PSI-independent strategy because PSI is leaking into the abstract
diagnostic infrastructure. The approach is definitely problematic,
but to fix it now, the leaking dependency to the psi-based module
is introduced. This should be fixed in the future by introducing
better abstractions.
Fixes flaky tests touched in the commit.
#KT-63002 fixed
since implicit imports are used in the gradle scripts, where it seems
difficult to precisely control list of import to avoid
unresolved names. And we can relatively safely ignore
unresolved imports there
#KT-62404 fixed
#KT-62305 fixed
NB: kotlin reflection do not see script class constructor after
this change, and it's ok, since the fact that the script is compiled
into a class is an implementation detail.
If needed, java reflection could be used to access the constructor.
The -all jar is compacted with proguard, and the proguard removes
synthetic methods methods with $default suffix from classes regardless
of the -keep flag.
Therefore the calls to the $default metods lead to the NoSuchMethodError
exception on runtime.
Removing the main interface module from the proguarded jar solves the
problem for now (but not generally, the use of "proguarded" jars as
libraries should be discouraged.)
#KT-60862 fixed
Temporary solution for K1 - see comments in the code
it seems that a scenario reproduced in the MainKtsTest.testKt48812
wasn't covered with analogous changes before.
And it wasn't detected while main-kts tests weren't a part of the
K1 scripting tests.
The test is fixed now, and testing of main-kts is restored.
the script declarations are considered public, at least because they
can be reused from another script then used with the `importedScripts`
configuration property. It also improves the compatibility with K1
scripting.
Ilya Chernikov