- 12 2月, 2021 1 次提交
-
-
由 Dmitriy Novozhilov 提交于
- Allow declaring protected constructors in sealed classes - Make default visibility of sealed class constructor `protected` KT-44861 KT-44865
-
- 11 2月, 2021 1 次提交
-
-
由 Jinseong Jeon 提交于
-
- 10 2月, 2021 2 次提交
-
-
由 Dmitriy Novozhilov 提交于
-
由 Jinseong Jeon 提交于
-
- 09 2月, 2021 7 次提交
-
-
由 Dmitriy Novozhilov 提交于
KT-44810
-
由 Dmitriy Novozhilov 提交于
-
由 Dmitriy Novozhilov 提交于
-
由 Dmitriy Novozhilov 提交于
-
由 Dmitriy Novozhilov 提交于
-
由 Dmitriy Novozhilov 提交于
#KT-44511 Fixed
-
由 Dmitriy Novozhilov 提交于
#KT-44554 Fixed
-
- 08 2月, 2021 4 次提交
-
-
由 Mikhail Glukhikh 提交于
Before this commit we initialized delegate fields in primary constructor, that could provoke NPE in case delegate is used in initializer of some property backing field. Now we initialize delegate fields directly instead.
-
由 Jinseong Jeon 提交于
^KT-39075 Fixed
-
由 Jinseong Jeon 提交于
^KT-44699 Fixed
-
由 Jinseong Jeon 提交于
-
- 05 2月, 2021 1 次提交
-
-
由 eugenpolytechnic 提交于
-
- 03 2月, 2021 2 次提交
-
-
由 Dmitriy Novozhilov 提交于
-
由 Jinseong Jeon 提交于
-
- 02 2月, 2021 1 次提交
-
-
由 Mikhail Glukhikh 提交于
-
- 01 2月, 2021 2 次提交
-
-
由 eugenpolytechnic 提交于
-
由 eugenpolytechnic 提交于
-
- 29 1月, 2021 3 次提交
-
-
由 Mikhail Glukhikh 提交于
-
由 Mikhail Glukhikh 提交于
-
由 Jinseong Jeon 提交于
To do so, inside the root cause of inapplicable candidate errors, we will record expected/actual type of receiver, if any. That will help identifying inapplicable calls on nullable receiver.
-
- 28 1月, 2021 3 次提交
-
-
由 Dmitriy Novozhilov 提交于
-
由 Jinseong Jeon 提交于
-
由 Jinseong Jeon 提交于
and use them to add support diagnostics: ANONYMOUS_FUNCTION_PARAMETER_WITH_DEFAULT_VALUE USELESS_VARARG_ON_PARAMETER
-
- 25 1月, 2021 1 次提交
-
-
由 Victor Petukhov 提交于
Approximate definitely not-null types for type parameter's types if they are already not-null (has not-null upper bounds) ^KT-44440 Fixed
-
- 23 1月, 2021 1 次提交
-
-
由 Mikhail Glukhikh 提交于
-
- 22 1月, 2021 2 次提交
-
-
由 Mikhail Glukhikh 提交于
-
由 Dmitriy Novozhilov 提交于
-
- 21 1月, 2021 7 次提交
-
-
由 Denis.Zharkov 提交于
Type of a block is a kind of irrelevant for lambdas: their type is much more complicated and defined via FirDataFlowAnalyzer#returnExpressionsOfAnonymousFunction at at FirCallCompleter.LambdaAnalyzerImpl#analyzeAndGetLambdaReturnArguments
-
由 Denis.Zharkov 提交于
See the test case Completion for synthetic call: x ?: return@myRun materialize() makes `materialize()` while it's obviously too early for that
-
由 Jinseong Jeon 提交于
and use it to add support diagnostic FUNCTION_DECLARATION_WITH_NO_NAME
-
由 Mikhail Glukhikh 提交于
-
由 Jinseong Jeon 提交于
and fix CONFLICTING_OVERLOADS to use it
-
由 Igor Yakovlev 提交于
[FIR] Fix invalid diagnostic fir node sites and improved invalid type parameters count diagnostic report
-
由 Dmitriy Novozhilov 提交于
- argument type is flexible - supertype has flexible type argument - type of expression is more specific than bare type
-
- 18 1月, 2021 2 次提交
-
-
由 Mikhail Glukhikh 提交于
Now the same resolve context is used for enum entries and for constructors.
-
由 Mikhail Glukhikh 提交于
Before this commit, during the resolve of companion objects we used the same context than for any nested class. However, during companion object resolve we should not have companion object receiver itself accessible in any case (in particular, it should not be accessible in constructor). So in this commit we introduced separate context for this purpose.
-