So, maybe this is an Android Studio thing, but aft...

# android

[Don Phillips]

So, maybe this is an Android Studio thing, but after upgrading to Kotlin 1.4.0, AS keeps reporting all of the new language features of 1.4 as red squiggly errors, though it compiles just fine.

To get around this, we had to explicitly add the following to our build.gradle files

kotlinOptions {
    languageVersion = "1.4"
}

Did those of you using 1.4 have to do this? We're using AS 4.0.1, and we've got the Kotlin 1.4.10-release-Studio4.0-1 plugin installed in AS.

[louiscad]

@Don Phillips
Do you overwrite the freeCompileeArgs somewhere in the project without putting what's already there? If so, using += in place of = should fix the issue.

[Don Phillips]

lemme check. I don't think so. But I do remember Hilt mentioning something about compiler args so maybe we did.

[louiscad]

You can just do cmd/ctrl + shift + F ("Find in Path") and filter to gradle files (or also buildSrc files if you use it) to find out.

[Don Phillips]

Hmm, yep, looks like we screwed this up. Just found this in our convention plugin for our library modules:

freeCompilerArgs = listOf(
            "-Xuse-experimental=kotlinx.coroutines.ExperimentalCoroutinesApi"
        )

[Don Phillips]

lemme switch it and see if that solves it

[louiscad]

It's also quite outdated.

[Don Phillips]

We don't need that anymore for coroutines?

[louiscad]

I mean, you should use opt-in now in place of use-experimental.

[louiscad]

You need it if you use experiential APIs

[Don Phillips]

Ok, I think I see what you're saying. From https://kotlinlang.org/docs/reference/opt-in-requirements.html

so it should really be -Xopt-in=kotlinx.coroutines.ExperimentalCoroutinesApi

[Don Phillips]

correct?

[louiscad]

Yes

[louiscad]

Did my initial suggestions fix the issue?

[Don Phillips]

syncing now, standby

[Don Phillips]

Strange..it helped, sort of.

[Don Phillips]

So it looks like the SAM conversions are working correctly now. The following code isn't tossing a red squiggly now

[Don Phillips]

viewModel.dataRefreshedEvent.observe(this) {
            if (it == true) {
                listOf(
                    homeTabFragment, geniusTabFragment, overviewTabFragment, profileTabFragment
                ).forEach { baseFragment ->
                    baseFragment.updateDataOnView()
                }
            } else {
                homeTabFragment.hidePullToRefreshView()
            }
        }

[louiscad]

So it works?

[Don Phillips]

But, in another place, this code is still throwing a red squiggly on maxOrNull

[Don Phillips]

selectAccountVM.accountsToSelect.value?.map { item -> item.balance }
                        ?.maxOrNull() ?: -1f

[louiscad]

Another module ?

[Don Phillips]

same module

[louiscad]

What's the error?

[Don Phillips]

unresolved reference: maxOrNull

[Don Phillips]

hmm, what's stranger is that even after adding back the `languageVersion = "1.4" back to the build.gradle for the module, it's still coming up as unresolved reference

[louiscad]

What else do you get in autocompletion at this use site?

[Don Phillips]

Screen Shot 2020-09-16 at 10.54.46 AM.png

[Don Phillips]

Trying an "Invalidate Caches and Restart" to see if that might fix

[louiscad]

That doesn't show autocompletion

[Don Phillips]

oh, sorry, misunderstood.

[Don Phillips]

I see what you're getting at, one sec

[Don Phillips]

Well I'll be damned.. it seems to be pulling in 1.3.72 for some reason...

[Don Phillips]

running gradlew dependencies --configuration implementation now.

I don't see how it can be pulling in 1.3.72. I triple checked - our library convention plugin is specifying 1.4.10 for the stdlib

[Don Phillips]

well hell, might have found the reason. It looks like in some of the androidTestAnnotationProcessorClasspath configurations, 1.3.72 is being pulled in by androidx.databinding:databinding-compiler

[louiscad]

I'm not it's the culprit but there's some stuff to try here.

[louiscad]

If you can share a Gradle scan (granted it doesn't leak too private info), that could help.

[Don Phillips]

lemme run one and see what happens

[Don Phillips]

Yeah, I don't think I should publish a scan. I think that'll get me into trouble w/ infosec

[Don Phillips]

what other stuff should I try @louiscad?

[louiscad]

Check the build window for errors, sometimes it doesn't show that Gradle sync failed.

[Don Phillips]

Checked it, looks good, build successful with last sync

[louiscad]

Then Gradle scan could help diagnosis

[Don Phillips]

I just tested the new allowance of trailing commas as well. It's red squiggly'ing me with the message "the feature "trailing commas" is only available in 1.4.

This is so very strange.

[louiscad]

Does it compile from command line?

[Don Phillips]

I've been compiling by running the assemble_VariantName_ tasks in the Gradle pane of AS without problem

[Don Phillips]

lemme try from the CLI though, standby

[Don Phillips]

Yep, just ran gradlew assembleLocalDebug just fine from the terminal

[louiscad]

Can you try to make a reproducing project to share?

[Don Phillips]

I'll have to talk to the boss

[Don Phillips]

see if he wants to work this hard at the problem

[louiscad]

You can also submit an issue on kotl.in/issue and attach your project privately (selecting "Kotlin team") if you trust JetBrains with your private code.

[Don Phillips]

Thanks, I'll ask my boss, see what he wants to do

[Don Phillips]

Hey @louiscad - I figured it out. My custom gradle convention plugin was the problem. The plugin's build.gradle was still using 1.3.72 for the kotlin plugin dependency in the script.

So when I applied my convention plugin to the various modules having this problem, I was unknowingly applying 1.3.72 instead of 1.4.10.

TIL - precompiled script plugins which apply plugins use the version of plugins specified in their dependencies block, they ignore the plugin resolution strategy defined in the project that the precompiled script plugin is being applied to

[louiscad]

Ah, makes sense!

[louiscad]

Thanks for the info!

[Don Phillips]

You're welcome. Now to solve the next problem - precompiled script plugins must use the version of Kotlin that's embedded with Gradle. When I change the version to 1.4.10, I run into this problem https://youtrack.jetbrains.com/issue/KT-38010

[louiscad]

I think you can use buildSrc instead of convention plugin in the meantime

[Paul Woitaschek]

I'm facing the same problem. Is there an issue for it? What's a "convention plugin"? @Don Phillips

[Don Phillips]

The Gradle Community slack pointed me in this direction https://github.com/jjohannes/idiomatic-gradle

A "convention plugin" is a plugin that configures things that are common to modules of a given type in a project.

So if you look in this repo, you'll see how they've got a number of convention plugins, to configure java, jacoco, unit-testing, etc. in a standard way across modules in the subprojects folder.