11 Commits

Author	SHA1	Message	Date
Jinseong Jeon	f5d2ce3022	AA: render containing file and JvmClassName	2023-12-21 15:34:34 +00:00
Dmitrii Gridin	72d8fa216a	[AA] DebugSymbolRenderer: move annotations and type arguments renderer befor type to avoid resolve race ... ^KT-56046	2023-02-03 19:48:56 +00:00
Dmitrii Gridin	1e2d517c21	[AA] DebugSymbolRenderer: improve type render ... to process all nested annotations and types ^KT-56046	2023-02-03 19:48:55 +00:00
Dmitrii Gridin	37d688ae83	[AA] introduce FirReceiverParameter ... ^KT-54417	2022-11-17 09:50:09 +00:00
Stanislav Erokhin	66851c7afd	[Analysis API] Add KtReceiverParameterSymbol#correspondingSymbol	2022-06-27 19:32:44 +00:00
Stanislav Erokhin	2234813363	[Analysis API] Add KtCallableMemberCall#typeArgumentsMapping	2022-06-23 07:50:21 +00:00
Stanislav Erokhin	8d8fc6e291	[Analysis API] Add type to KtReceiverValue ... Maybe in the future we could remove type from the KtImplicitReceiverValue, because it has ktSymbol, and in theory that should be enough to create corresponding KtType. Unfortunately that is not the case for KtClassOrObjectSymbol -- it doesn't have the API for "default" type creation currently. Regarding code in KtFirCallResolver.kt -- it seems like code there needs some love in the future. Psi created via custom code there, because for call x() FIR has receiver x with psi = null	2022-06-23 07:50:21 +00:00
Ilya Kirillov	2c1074ac37	[Analysis API] actualize testdata	2022-06-22 09:31:45 +02:00
Roman Golyshev	564e408434	KT-50862 Add name property to KtSignature ... See the KDoc of the property for the reasons why it was created	2022-01-29 07:42:17 +00:00
Tianyu Geng	9b05019137	FIR Analysis API: reimplement KtFirCallResolver with new data model	2021-12-06 12:40:43 +01:00
Ilya Kirillov	6f6a33e852	Analysis API: move testdata to corresponding components folders	2021-11-17 20:55:08 +01:00