It was used to allow custom contracts when compiling stdlib
with the Kotlin 1.2 compiler. Since 1.3 compiler is used now, this
flag is no longer necessary.
There was a problem with `reportDiagnosticOnce` method which was
called, for example, to report diagnostics about experimentalities. It
was crucial for code as in the issue (KT-34204).
The whole complexity was "count of experimental diagnostics" multiply
"count of all diagnostics" multiply very large constant. Almost on
each `reportDiagnosticOnce` method `readonlyView()` was called which
in turn called computation of cache. During cache computation we were
iterating through the all diagnostics and also were using
KotlinSuppressCache, which is not very fast.
#KT-34204 Fixed
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
Stanislav Erokhin