does anybody have an idea how to work around this problem: https://youtrack.jetbrains.com/issue/KT-19939

Well you can wait for a couple of days for the devs to respond ☺️

I have an interesting issue. Environment: gradle wrapper 4.0.1, kotlin 1.1.3-2, IntelliJ Ultimate 2017.2.2 Build → Rebuild project works ./gradlew build works gradle build initiated from Grdle projects view within IntelliJ fails with cannot resolve symbol errors Problem started after I moved some kotlin classes from one package to another.

Did you do a clean build? Sync gradle project? Invalidate idea caches? Restart Idea?

yes, all the standard hoola-baloo, even did invalidate caches and restarted, removed classes, out, build dirs, deleted .gradle directory

nothing helps

And have you reimported the project?

you mean delete idea project structure and import as new project?

like uber-sync?

sounds like https://youtrack.jetbrains.com/issue/KT-18475 to me

fixed in 1.1.4

@Czar Yes I'd try that.

@yole, updated to 1.1.4-2, doesn't help

the weirdest thing is that from command line gradle build works but from intellij it doesn't, I thought IJ is just calling gradle, but seems it does something else.

Are you on windows?

no, OpenSUSE

Resolved my problem, this was some magically weird thing probably inter-language classpath something, turned out the class that wasn't being resolved was a groovy enum. I haven't noticed that it was groovy because it was written java style, and for some reason in previous classes arrangement it was being resolved but when I moved the classes (even though within same gradle subproject) it stopped working. I rewrote the enum to Kt and now it's working.

By coincidence I just noticed a weird debugger issue if you have a test class in the test module which has the same name (and package) as one in the main module. Not sure if it’s worth to file an issue for it though?! Consider this class your main module:

// this is in main module
class Tester {

    fun foo() {
        println("main foo 1")
        println("main foo 2")
        println("main foo 3")
        println("main foo 4")
        println("main foo 5")
        println("main foo 6")
        println("main foo 7")
        println("main foo 8")
        println("main foo 9")
    }
}

And this one in your test module:

import org.junit.Test

// this is in test module
class Tester {

    @Test
    fun testFoo() {
        println("test foo 1")
        println("test foo 2")
        println("test foo 3")
        println("test foo 4")
        println("test foo 5")
        println("test foo 6")
        println("test foo 7")
        println("test foo 8")
        println("test foo 9")
    }
}

Now put a breakpoint on the first line of testFoo() and debug the function. The debugger/editor will break/jump to the same line number in main’s Tester class - fun foo() in this case - but executed will actually be the correct line in testFoo() (printlns are correct)

can't reproduce the same thing with a Java project. Intellij notices the "second" class though...

@User uploaded a file:

It seems

0.5.let(if (roundUp) Math::ceil else Math::floor)

is not inlined. Should there be a warning? This may come as a surprise to some users.

Well it can't be inlined because the lambda is not known at compile-time. A warning at every callsite would be a bit annoying I think.

why at every callsite?

I would expect a warning on calls of inline functions where a lambda object is "accidentally" instantiated

if that's what you meant, then yes

You propose to add a warning for when you call an inline function but it can't be inlined?

actually, the function is inlined

but a lambda is instantiated which defeats the purpose of inlining

Ah I see, maybe that could be fixed instead?

no, think about reified generics