zarechenskiy ( Mikhail Zarechenskiy )

PR opened JetBrains/intellij-community

KTIJ-11643 Add remaining branches for `when` statement automatically for postfix completion

https://youtrack.jetbrains.com/issue/KTIJ-11643

+92 -60

1 commit in t-kameyama/intellij-community/tree/KTIJ-11643 JetBrains/intellij-community/tree/master

0 comment

7 changed files

pr created time in an hour

issue commentKotlin/KEEP

Context receivers

I think the keyword within would make code more readable. Some examples taken from the proposal, comparing context vs. within:

context-coroutines

within-ann

It would also be a better match for with. For example:

The declaration-site would match the use-site really closely.

shadrina

comment created time in 2 hours

issue commentJetBrains/gradle-intellij-plugin

Support for Build Cache for test tasks

Did you men #705 ?

Yes...yes I did :(

abrooksv

comment created time in 3 hours

create barnchKotlin/kotlinx-datetime

branch : utc-offset-cleanup

created branch time in 3 hours

issue commentKotlin/KEEP

Context receivers

What is expected to happen with the old way to implement DSLs when I add an extension method to some class inside my class?
```
class C {
    operator fun String.unaryPlus() = ...
}
```
This way has lots of limitations like I cannot make this method an extension one. Because it already has a receiver. Also, such a way to declare DSLs looks quite contr-intuitive, unlike the suggested new one. That is why it would be great to hear about what is going to happen with current implementations. Would they be deprecated or what?
There was info about label generation restriction. Can we specify the label name explicitly? If so, we could escape creating typealiases if the label wasn't generated as they are too verbose for single usage.
This is definitely my fault, but I misunderstood how to call functions with context receivers. When I had member receivers, I could call it with:
- `entity.smth()
- with or something like that For the contextual receivers, we cannot use the first option and I failed to do it the right way with the second
I am very interested in the code colouring concept. So I would be glad to see it developed or at least discussed.

shadrina

comment created time in 3 hours

issue commentJetBrains/gradle-intellij-plugin

Support for Build Cache for test tasks

Did you men #705 ?

abrooksv

comment created time in 4 hours

pull request commentJetBrains/gradle-intellij-plugin

Fix cacheability of the test task

So fast! Thanks :))

cesar1000

comment created time in 5 hours

push eventJetBrains/gradle-intellij-plugin

Cesar Puerta

commit sha 6a6db0e919ed24b385280c515590ba58a3d6f775

Fix cacheability of the test task Fix several issues that affect the cacheability of the test task: * System properties containing absolute paths should be set in `doFirst`, so that they are not captured in the cache key (which would make the cache entry non-relocatable). * The configuration directory should be declared as an input, since it's created outside of the task, and Gradle will disable caching upon finding unexpected changes to an output directory. * All file inputs should use relative path sensitivity in order to make the task relocatable. * Passing a lambda into `doFirst` disables caching. Gradle recommends using an anonymous class instead. JIRA Issues: ANDROID-76125