3febabe977
Use OPT_IN instead of EXPERIMENTAL in diagnostic names
2021-09-10 16:29:13 +03:00
b94335dd1c
FIR: Update diagnostics test data
...
Green code correctly became red
2021-05-20 17:24:30 +03:00
3cb17ac2f0
[FIR] Implement FirReturnAllowedChecker
...
Supported diagnostics:
- RETURN_NOT_ALLOWED
- RETURN_IN_FUNCTION_WITH_EXPRESSION_BODY
2021-04-06 12:30:41 +03:00
f0ff9ad5a7
FIR: rename AMBIGUITY to OVERLOAD_RESOLUTION_AMBIGUITY to match FE 1.0
2021-04-02 16:22:01 +03:00
55e5af1111
FIR: Add workaround for flatMap issue
2021-03-31 15:57:03 +03:00
e6b5cb5216
[TD] Update diagnostics test data due to new test runners
...
Update includes:
- Changing syntax of `OI/`NI` tags from `<!NI;TAG!>` to `<!TAG{NI}!>`
- Fix some incorrect directives
- Change order of diagnostics in some places
- Remove ignored diagnostics from FIR test data (previously `DIAGNOSTICS` didn't work)
- Update FIR dumps in some places and add `FIR_IDENTICAL` if needed
- Replace all JAVAC_SKIP with SKIP_JAVAC directive
2020-12-16 19:52:25 +03:00
9f5aadd2f4
[FIR] Implement overload resolution by lambda return type
...
#KT-43129 Fixed
2020-11-11 09:52:55 +03:00
a936386e53
FIR: Add more complicated workaround for OverloadResolutionByLambdaReturnType
...
That helps for minOfOrNull/maxOfOrNull
2020-11-03 18:30:15 +03:00
4612f26bfb
FIR: Add workaround for OverloadResolutionByLambdaReturnType
...
Mostly, that should help for existing flatMap usages
^KT-43129 Submitted
2020-11-03 18:30:15 +03:00
f283f2db43
[FIR] Improve diagnostic reporting & don't use error symbol for candidate if possible
...
Also introduce few new diagnostics:
- NONE_APPLICABLE more many inapplicable candidates
- HIDDEN for visible candidates
2020-07-28 20:46:56 +03:00
93e9d3e57d
Delay check for possibly deferred return type for reference candidate
...
This issue appeared after recently added new overload for flatMapTo.
Before that, we picked candidate returning List<T> and completed
inference, now we also check one more flatMapTo, which is here is
incorrect and as a result we go into outer scope. Outer scope contains
one property with deferred type, which introduced error about
"typechecker has run into recursive problem" even it isn't applicable
by receiver.
So, the fix is to check receiver first and only then check return
type of a candidate.
#KT-39470 Fixed
2020-06-09 17:36:58 +03:00
069adebf01
[NI] Fix checking for inline lambdas without candidate
...
#KT-34506
2020-06-01 23:40:32 +03:00
ea6a8ce5cd
Rename language feature to make it more clear
2020-05-31 18:13:17 +03:00
2812ed0a02
[NI] Use types and systems from return arguments instead of return type of lambda
2020-05-29 09:36:33 +03:00
f76b57d260
[OI] Prefer candidate without @OverloadResolutionByLambdaReturnType
2020-05-29 09:36:33 +03:00
a604404bff
[NI] Report warning if candidate was chosen using only @OverloadResolutionByLambdaReturnType
2020-05-29 09:36:33 +03:00
82ce2e7b7c
[NI] Update annotation used in testdata
2020-05-29 09:36:32 +03:00
e1418a5540
[NI] Check for maximally specific candidate chosen with factory resolution
2020-05-29 09:36:32 +03:00
e7869bd9d4
[NI] Analyse lambda in factory pattern resolution in independent context
2020-05-29 09:36:32 +03:00
8c524769b1
[NI] Add required FactoryPattern annotation for factory pattern resolve
...
#KT-11265
2020-05-29 09:36:31 +03:00
865ddac07a
[NI] Add feature for choosing candidate by lambda return type
2020-05-29 09:36:31 +03:00
Mikhail Glukhikh