Disable annotation rendering in default type and descriptor renderers.
Preserve annotations in Android and Serialization plugins.
Update error texts in ide tests.
Nullability annotations in Java descriptors are rendered with context-dependent renderer.
#KT-20258 Fixed
If the delegated property operators involved are inline, and delegated
property metadata parameter is not used (which is often the case, e.g.,
'lazy'), we can skip those properties in metadata generation.
NOT implemented: special case when only 'kProperty.name' is used by the
corresponding delegated property operators.
Also a sneak fix for KT-34060.
Using files turned to be a bad idea, because people often
use the same name for files with expects and with corresponding actuals.
This commits disambiguiates ambiguous message for
AMBIGUOUS_ACTUALS/AMBGIUOUS_EXPECTS diagnostics by using modules instead
of files
^KT-32582 Fixed
This allows to easily re-use other renderers from 'Renderer'-block
(previously, one had to declare 'ContextDependentRenderer' just to get
hold of 'RenderingContext' just to call 'render(O, RenderingContext)'
from DiagnosticParameterRenderer, which would be unused anyways)
This commit introduces more specific subtype,
'ContextIndependentParameterRenderer', which exposes 'render(O)' method
for easy re-use.
Several (ab)uses of 'ContextDependentRenderer' have been removed
The changes introduced 471134d31e are only needed
for the case of HMPP project while for other cases it might break the behavior
a bit like in KT-34027
See org.jetbrains.kotlin.resolve.calls.results.OverloadingConflictResolver#filterOutEquivalentCalls
Before 471134d we were comparing
"fun foo(x: String)" with "[substituted] fun foo(x: String)"
and areCallableDescriptorsEquivalent returned false for such case.
Thus, both overrides were left in the resulting set.
After 471134d, those two descriptors
becamed considered as equal thus having a possibility to remove any of them.
The problem is that "areCallableDescriptorsEquivalent" has kind of
unclear contract. Effectively it checks whether two descriptors match
to the same declaration
But straightforward fixing of this exact call-site (using original descriptors)
doesn't help: behavior might change in a very subtle way (see org.jetbrains.kotlin.spec.checkers.DiagnosticsTestSpecGenerated.NotLinked.Dfa.Pos#test72)
So, the main idea is changing the contract for areCallableDescriptorsEquivalent
only when project is HMPP one.
^KT-34027 In Progress
Alternative message for errors, caused by unexpected lambda expression arguments on a new line.
Both diagnostic are reported, if multiple lambda expressions were passed to the call.
For other errors trailing lambda diagnostic overrides the original one.
Quickfix for erroneous trailing lambdas on a new line after call.
Fix separates lambda expression from previous call with semicolon.
All trailing lambda arguments become standalone lambda expressions.
Previously, ResolverForProjectImpl had multiple callbacks in
constructor. Some of those callbacks were used only to overcome module
visibility and provide an ability to inject IDE-specific logic into
compiler (ResolverForProject is in the 'compiler'-module)
This commit introduces abstract class which implements
environment-independent logic (previously, this logic had been stored in
ResolverForProjectImpl) with several abstract met hods (previously,
callbacks). Then, we provide few concrete implementations of
AbstractResolverForProject with clear semantics:
- IdeaResolverForProject: resolver used in IDE, where we have indices,
oracles, multiple modules, etc.
- ResolverForSingleModuleProject: resolver for project with only one
module, commonly used for CLI compiler/tests
- one anonymous implementation for MultimoduleTests
This refactoring achieves several things:
- now it is easier to see what kinds of ResolverForProject you might see
in some particular environment (previously, one had to inspect all
call-sites of constructor)
- we can easily add IDE-specific logic in IdeaResolverForProject without
adding noisy callbacks (which most probably wouldn't have any other
non-trivial implementations)
This call was needed at some point for smartcasts on qualified
expressions but become obsolete (most likely after
daa27016ca).
Now `ComplexDataFlowBenchmark` has similar results for NI and OI
Split error reporting into two parts for incorrect and missing candidates.
Missing function error is not reported on provideDelegate.
Update error factory and default message for error.
Update error texts in quick fix test data.
#KT-16526 Fixed
- this adds enum entries to the completion on the typealiases
- we cannot use `unsubstitutedInnerClassesScope` instead of `EnumEntriesScope` because it allows to complete things that are not allowed to be resolved by the Kotlin compiler; see `EnumEntriesScope` doc for details
- ^KT-17689 Fixed
Relates to KT-8834, we continue reducing differences between old and new
inference. Note that as for `SamConversionPerArgument`, this feature
is enabled in the compiler and not in the IDE to avoid breaking code
for those users that already enabled new inference in the compiler
We've found that the BindingContext is necessary for any meaningful suppressor.
This change adds the ability for suppressors to use the BindingContext when available.
Change-Id: I14d8148ef659eca273445bf0638bcdb8c3b21f02
Kotlin compiler strips all debug information for @InlineOnly functions, making them non-debuggable.
This commit disables breakpoints inside @InlineOnly functions to prevent false expectations.
Previously, type for "c.a"-receiver in "c.a.platformFun()"
has not been refined because typechecking of "c.a" doesn't go
through common facade org.jetbrains.kotlin.types.expressions.ExpressionTypingServices#getTypeInfo
where the most of expressions are expected to be type checked.
(see org.jetbrains.kotlin.resolve.calls.CallExpressionResolver#getUnsafeSelectorTypeInfo)
Under COMPOSITE mode we don't have a globally known way to create
built-ins, instead, we have to create them on per-module basis.
So, in this commit we:
1. Use builtInsProvider: (ModuleInfo) -> KotlinBuiltIns instead of
precomputed builtIns instance, in order to be able to calculate
builtIns on per-module basis
2. Introduce new entity, called BuiltInsCache, which, roughly
speaking, is a map of form ModuleInfo -> KotlinBuiltIns, to prevent
creation of multiple builtInsInstances
NB. Actually, it's of form BuiltInsCacheKey -> KotlinBuiltIns, because
we shouldn't create new builtIns for each module. Also, currently,
each platform has its own BuiltInsCacheKey implementation, because
parameters by which built-ins are created, are a bit different across
different platforms. Ideally, we should eliminate those differences
and they use one concrete implementation as a key.
Under COMPOSITE resolution mode (see ResolutionModeComponent) we have
no fixed and globally known SDK, instead, for each module we have to
find SDK it it's transitive dependencies.
Currently, this is necessary in order to create proper JvmBuiltIns,
which need dependency on SDK to be present in immediate dependencies.
This commit introduces CompositeResolverForModuleFactory, which should
work under so-called "composite resolution mode", where sources of all
all modules are analyzed in one global facade.
This allows to:
- avoid re-analyzation of common sources
- avoid retaining memory for all platforms (which can be very bad as
soon as we'll start distinguishing various flavours of platforms,
especially "flavours" of common platform)
- support running platform-specific checks in common modules (e.g.,
report JVM_PLATFORM_DECLARATION_CLASH if common sources are going to have
it)
- support analysis of shared platform modules, like commonNative
This mode heavily depends on so-called "type refinement" support in the
compiler, which is introduced in other series of commits.
In this commit, CompositeResolver and related codepaths are left unused.
Also, this commit misses several important pieces of logic in
resolvers-setup code, which should be different for CompositeResolver
- computation of 'firstDependency'
- computation of built-ins
- computation of modules owned by facade
They will be covered in the following commits
As consequence, remove IdePlatformKindTooling.resolverForModule, because
it became more than just field, and it duplicates similar API in
IdePlatformKindResolution anyways
Pavel Kirpichenkov