4 Commits

Author	SHA1	Message	Date
Marco Pennekamp	d4e6a4ad54	[FIR] KT-54978 Prohibit explicit type arguments in property accesses ... - Add a checker which ensures that property accesses have no explicit type arguments. If an error on the property access's callee reference already exists, the new error is not reported in favor of the existing error, as the property access may have been intended to be a function call. - `complicatedLTGT.fir.kt`: The underlying parser issue is not yet solved, which is why `x` is parsed as a property access with explicit type arguments. - `reservedExpressionSyntax` tests: This new check makes a lot of the access expressions in these tests illegal, so valid lines have been added and invalid lines appropriately marked with `EXPLICIT_TYPE_ARGUMENTS_IN_PROPERTY_ACCESS` errors. ^KT-54978 fixed	2022-11-29 14:47:59 +00:00
Victor Petukhov	27fa632630	[FE 1.0] Update test data with new error type representation	2022-03-23 21:13:33 +00:00
Dmitry Petrov	33ed98a0d3	Update typing rules for class literal expressions. ... C::class : KClass<C> expr: T => expr::class : KClass<out T> NB: this means Obj::class : KClass<out Obj> for object Obj.	2016-12-19 10:41:49 +03:00
Dmitry Petrov	2cd6c85cc7	Syntax forms 'a<T>::foo', 'a?::foo' have special cases resolved for future releases. ... '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.	2016-11-29 13:10:01 +03:00