- 24 3月, 2021 26 次提交
-
-
由 Mikhail Glukhikh 提交于
-
由 Mikhail Glukhikh 提交于
-
由 Mikhail Glukhikh 提交于
-
由 Mikhail Glukhikh 提交于
-
由 Mikhail Glukhikh 提交于
-
由 Jinseong Jeon 提交于
-
由 Victor Petukhov 提交于
-
由 Victor Petukhov 提交于
-
由 Victor Petukhov 提交于
-
由 Victor Petukhov 提交于
-
由 Victor Petukhov 提交于
-
由 Victor Petukhov 提交于
-
由 Victor Petukhov 提交于
^KT-42742 Fixed
-
由 Vladimir Dolzhenko 提交于
#KT-45339 Fixed
-
由 Vladimir Dolzhenko 提交于
Relates to #KT-38959
-
由 Dmitriy Novozhilov 提交于
-
由 Ilya Muradyan 提交于
Before this fix, if some imports were not resolved during compilation, this result had been saved in caches, and this import couldn't been resolved during following compilations even if it was added to the module dependencies. This commit adds special handling of resolution caches for the REPL compiler.
-
由 Dmitriy Novozhilov 提交于
-
由 Dmitriy Novozhilov 提交于
-
由 Dmitriy Novozhilov 提交于
-
由 Dmitriy Novozhilov 提交于
-
由 Dmitriy Novozhilov 提交于
-
由 Dmitriy Novozhilov 提交于
-
由 Dmitriy Novozhilov 提交于
-
由 Dmitriy Novozhilov 提交于
-
由 Dmitriy Novozhilov 提交于
-
- 23 3月, 2021 8 次提交
-
-
由 Dmitry Petrov 提交于
-
由 Ilya Kirillov 提交于
-
由 Alexander Udalov 提交于
This will be used in the compiler starting from 1.5.20 instead of the currently used approach of looking for the single value parameter of the primary constructor. The problem with the current approach is that primary constructor can be private (since 1.4.30) and the property could always be private. Relying on private declarations from metadata is dangerous; for example lazy IR doesn't usually create stubs for private declarations, and it didn't create stubs for private inline class constructors before b5f9b1df, which led to the problem reported in KT-44723.
-
由 Ilmir Usmanov 提交于
Previously, -Xallow-result-return-type was used to test, whether the launcher parses -X... flags correctly, however, it has no effect - returning Result is allowed anyway. So, instead, use -Xno-inline and check runtime behavior.
-
由 Alexander Udalov 提交于
#KT-44723 Fixed
-
由 Alexander Udalov 提交于
-
由 Ilmir Usmanov 提交于
-
由 Mads Ager 提交于
When a suspension point is inlined, the inlining local spans unspilling code where the local slot has not been initialized. The transformer already inserted initialization code for the local, however, it did not split the local variable table. Therefore, the inlining local is defined on instructions where the local slot has no value (namely the instructions that initialize the local slot on the unspilling path). This change adds splitting of the local variable table as well. When updating to a new version of D8, the uninitialized local slot showed up. D8 will repair it in this case, but it is better to not generate such code.
-
- 22 3月, 2021 6 次提交
-
-
由 Ilmir Usmanov 提交于
-
由 Ilmir Usmanov 提交于
by default
-
由 Br0mm 提交于
-
由 Ilya Kirillov 提交于
-
由 Ilya Kirillov 提交于
-
由 Ilya Kirillov 提交于
-