Commit Graph

11 Commits

Author SHA1 Message Date
Ivan Kochurkin 84c5f58cab [FIR] Implement UNRESOLVED_REFERENCE_WRONG_RECEIVER 2021-08-25 21:53:23 +00:00
Denis.Zharkov 2ecba6ac39 Remove WITH_NEW_INFERENCE directive from all tests
This directive anyway does not make test run twice with OI, and with NI
It only once run the test with specific settings (// LANGUAGE)
and ignores irrelevant (OI or NI tags)
2021-05-25 13:28:26 +03:00
Ivan Kochurkin 4353365968 [FIR] Implement NULL_FOR_NONNULL_TYPE diagnostics, fix tests 2021-04-19 12:46:08 +03:00
Denis Zharkov 72b09ff323 FIR: Rename FirSuperTypeScope and reuse it for type parameter type
It would allow ConeKotlinType.scope return FirTypeScope
and thus pulling down org.jetbrains.kotlin.fir.scopes.FirScope#processOverriddenFunctions
(See the following commits)
2020-06-11 11:31:31 +03:00
Ilya Chernikov 6356807997 Reapply "Only create descriptors for candidates with lambda args"
#KT-36247 fixed
A lot of testdata changed because significanly less (error) descriptors
are created for unresolved types, so diagnostics became different.
2020-02-14 11:41:30 +01:00
Dmitriy Novozhilov 2536fa0cd5 [FIR-TEST] Add new testdata generated after changes in previous commit 2019-12-12 16:11:46 +03:00
Mikhail Zarechenskiy b2299ed19f [NI] Fix testdata after introducing DefinitelyNotNull types 2017-12-06 18:36:16 +03:00
Mikhail Zarechenskiy 8757298994 Add diagnostics to test data from NI 2017-11-29 02:54:26 +03:00
Mikhail Zarechenskiy a71238bf94 Place !WITH_NEW_INFERENCE directive to diagnostics test data 2017-11-29 02:53:49 +03:00
Mikhail Zarechenskiy 7541a3754d Move SAM constructors to synthetic scope 2017-05-05 21:30:35 +03:00
Denis Zharkov b4bb92d136 Fix overload resolution ambiguity for types intersection
There are two different forms of types intestion:
1. Type parameters with multiple bounds
2. Smart casts

The problem was that when member scope of type intersection contained
effective duplicates and that lead to overload resolution ambiguity in
strange cases like `x.hashCode()`

For first type we do effectively the same thing as when building member
scope for class extending several interfaces: group all descriptors by
both-way-overridability relation and then choose most-specific in each
group.

For smart casts we do basically the same thing but with special
treatments:
1. From all descriptors that _equal_ to most specific we choose
   the one that works without smartcast if possible (i.e. we choose first from candidates list)
2. If smart-cast value seems to be unstable we use only member scope
   of receiver type + all descriptors from smart cast possible types
   that has incompatible signature. If we'd include all of them and
   choose one as more specific, and it would lead to false
   SMART_CAST_IMPOSIBLE (see test unstableSmartCast.kt)

 #KT-3996 Fixed
 #KT-10315 Fixed
2015-12-15 16:18:31 +03:00