Similarly to pre-release classes, load metadata for the class anyway and allow
the resolution to select it as the result and prohibit its usage in the end
with the special diagnostic reported in MissingDependencyClassChecker
This has no effect for the original use case of mock class descriptors
(unresolved classes used in libraries), but is necessary for pre-release
classes in case the compiler is a release, because such classes end up in scope
and can be the result of the resolution
Change expectations for double and float ranges according to #KT-4481
#KT-5044 #KT-4481
Custom 'rangeTo' might be unoptimized, but still 'in' should not diverge from 'contains'.
After this change SAM adapters are being resolved in the same group
as members, thus their overload resolution happens simultaneously.
But in the case of overload resolution ambiguity try to filter out all
synthetic members and run the process again.
See the issue and new test for clarification
#KT-11128 In Progress
1) for all cases of misusing of JsModule report on JsNonModule as well
2) report about non-top-level declarations with JsModule/JsNonModule
3) report about JsModule/JsNonModule declarations inside file marked with JsModule/JsNonModule
4) report about usages of declarations not marked with both JsModule and JsNonModule from UMD module
'a<T>::foo' is reserved if 'a' is a simple name and can be resolved as an expression
(this can be extended to 'a.b.c<T>::foo' case, although that is rather hard to implement using PSI).
'a?::foo' is reserved if 'a' can be resolved as an expression.
Use "-Xno-check-impl" to suppress checking whether the platform declaration
implementation has the "impl" modifier.
Do not check presence of fake overrides from platform class in the impl class,
otherwise there would be a lot of errors about the fact that
equals/hashCode/toString are not marked with the "impl" modifier
When matching platform and impl classifiers, ensure that each declaration from
the platform class scope is present in the impl class scope.
Note that the presence of the 'impl' modifier is not checked yet
For each platform declaration, there must be at least one impl declaration in
the module with the compatible signature; similarly, for each impl declaration,
there must be at least one platform declaration with the compatible signature.
Note that currently the presence of the 'impl' modifier is not checked yet.
Also, the sad fact is that if you have platform and impl declarations which are
not compatible, you get two errors: on the platform delcaration and on the impl
declaration. This needs to be addressed as well
Alexander Udalov