Does the gradle build work?

@karelpeeters No, it fails because of a coroutine 0.19 incompatibility, but Its hard to solve it w/o code complete etc...

I even tried going back to 0.18, and it compiles OK, but everything is still red...

I had to Invalidate the IDE cache after the downgrade and successful build and the main code is OK, but the test code dependencies are still red even after running the tests...

not stritly related to Kotlin but... Does anyone know if there's a live template variable that returns the list of members of the current class?

basically I'm trying to generate some code by iterating over a classe's members - couldn't find any way to do that

Please refer to the channel topic, general idea questions go here: https://intellij-support.jetbrains.com/hc/en-us/community/topics/200382555-IntelliJ-IDEA-Users

sure

Now all reference to main source set or gradle dependencies from my test source set is all in red... Anyone has an idea how to fix this? I tried invalidating the IDE cache and reindexing, I even tried updating to gradle 4.2-all...

When I run the tests, they work (although some are failing.. )

In the end, I had to remove the .idea folder and re-import from gradle w/o making a module per source set...

Hello, I am a new Kotlin developer and was trying to help with the github project, in the code inspection module. On the moment, I got to build the IDE from IDEA with the command "./gradlew runIde". Even so, it seems IDEA isn't recognizing various classes, like IntentionWrapper(I tried adding some jars as library and some folders as source, but didn't get any result), and I don't know how, but IDEA isn't accepting anymore extensions like the .any {} for lists. Is there anyone who could share some advice on starting colaborating with the project?

I just updated to JDK9, working on adapting TornadoFX to the new module system, but I can't build from IDEA via the plugin. Command line (Maven) is working fine. Have anybody else had this issue?

@edvin uploaded a file: Untitled

I've invalidated caches, cleared my config folder and even tried the latest EAP, same result.

quick question - i know that the return type is optional but this doesn't pop up for explicit of other types (e.g.

Int

) any thoughts on if this should be files as an issue or not?

I’m not sure what you’re asking

Unit

as a return type is redundant because functions that don’t have a specified return type are inferred to return

Unit

anyhow

right but i can do something like

fun thisFunction(myThing: MyThing) = myThing.doOtherThing()

you may want to clarify the return type for these single expression functions - does that make sense?

incase

myThing.doOtherThing()

type signature changes or something down the line - my main question was that the IntelliJ intention says it is redundant for

Unit

but not for other types like

Int

the redundancy i think makes sense when the function has a body

{}

because you always need to specify return type if it is not

Unit

I guess I can kind of see where you’re coming from, and I think you could soundly argue that expression body functions might benefit from explicit typing in all cases

I don’t think it’s necessarily not working as intended, however

I think they ought to give you an option to disable that inspection though

yeah i can disable it, just noticed a coworker remove the

Unit

because IntelliJ suggested it

OTOH, I think if your method changes return type from

Unit

to anything else, that probably warrants a renaming of the function, or maybe marking it as

@Deprecated

and replacing it with a more appropriately named call

but that’s more of a code style discussion, less so an IDE one

Have a serious issue where IntelliJ's test runner (via Run window) breaks when tests are done using Kotlin Coroutines. For instance a failed test shows a "green icon" instead of a "yellow icon" in the Run window. Using Kotlin Test with Vert.x in a Kotlin Gradle project (via Gradle Kotlin DSL).

IntelliJ's test runner breaks when Kotlin Coroutines are used.

this is most likely caused by the way your tests are written. if the test method completes before an exception is thrown in another thread, then there's no way for the test runner to detect a test failure