'hasDefaultValue' needs to be adapted to support locating default values
in 'expect' functions, and this is not possible in module 'descriptors',
where it was originally declared. Therefore, move it to module
'resolution' and copy its current logic to a separate function
'declaresOrInheritsDefaultValue' which is used in 5 places.
'hasDefaultValue' itself is updated in subsequent commits.
Besides changing imports, also use a simpler declaresDefaultValue in
some places, which does not include default values inherited from
supertypes: this is OK for constructors, and in LazyJavaClassMemberScope
for functions from built-ins which do not have default argument values
at all
- Convert between conventions call for 'get' and 'invoke'
- Drop 'operator' when converting 'get'/'invoke' to something other than
'invoke'/'get' respectively
#KT-12365 Fixed
they are getting obfuscated in the ultimate SDK, which prevents us
from using ultimate sdk for all modules.
Could probably be rolled back after fixing KT-18563
Before this change `filesScope` was effectively empty in cases when
module info is a library, thus looking
into PackageIndexUtil.packageExists(name, indexedFilesScope, project)
was kind of redundant since it always returns false for empty scopes
The initial motivation was run by 1716720604
that made PackageIndexUtil::packageExists calls much more frequent
Object model for deserialized protobuf isn't very cheap, so
loading just our stdlib's packages several times (as we do in the IDE)
might lead to ~ 96 MB of retained memory just by these objects.
While in fact many of them remain unused
#KT-21517 Fixed
Only require implementations to be able to compute the enum class name
and the corresponding entry name. Only this should be necessary to
correctly resolve the argument; the resolvers will find the
corresponding class descriptor if necessary
The problem was that there is no special entity for libraries
in the IntelliJ model, and when we have an element for a library
we have to search through all of its dependencies
(see getOrderEntriesForFile call in collectInfosByVirtualFile)
But for popular library there could be quite a lot of dependencies,
while in most cases we need only the first one to obtain module
info for library itself (see changed usage in resolverForElement).
So it's worth replacing List with Sequence here
It's implemented through Jsr305State while it's not related
to jsr-305 becasue currently it's the most convenient way
to introduce the flag.
Probably, it's worth renaming Jsr305State to something more abstract
like NullabilityAnnotationsConfiguration
#KT-21982 Fixed
It leads to undesired behaviour
such as returning library source when only binaries are queried
It is redundant since js libraries do not include kotlin source files
(real binary format is used for this purpose for along time now)
Mikhail Glukhikh