[WIP] Kotlin 2.0 support (2.0.0-RC2)

[3flex]

Unless I've missed something it seems that the classic method of running detekt is compatible with K2 but the compiler plugin isn't.

Testing & experimentation is encouraged.

Fixes #6715

[jarroyoesp]

Hey @3flex after trying the commit 429a178 as you mentioned here #6715 (comment). I've been able to compile your branch and generate the library on my MavenLocal. But when I've run detekt in my project, I am getting the following errors:

> Task :build-conventions:compileKotlin FAILED
e: Pre-release classes were found in dependencies. Remove them from the classpath, recompile with a release compiler or use '-Xskip-prerelease-check' to suppress errors
e: file:///Users/javierarroyo/Projects/Personal/Forlago/build-conventions/build/generated-sources/kotlin-dsl-accessors/kotlin/gradle/kotlin/dsl/accessors/_2fb462c0d2ba107f613d15985247d494/Accessors32ikgp1isdd8mwexzgbe6rirl.kt:65:44 Class 'io.gitlab.arturbosch.detekt.extensions.DetektExtension' is compiled by a pre-release version of Kotlin and cannot be loaded by this version of the compiler

Thanks :)

[3flex]

You probably need to follow steps here: https://docs.gradle.org/8.3/release-notes.html#kotlin_k2 and be sure to use Gradle 8.3 or higher.

Also have a read of https://kotlinlang.org/docs/whatsnew-eap.html#current-k2-compiler-limitations

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 84.37%. Comparing base (fa596fd) to head (8a9b77f).

Files	Patch %	Lines
...lin/io/github/detekt/parser/BindingContextUtils.kt	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #6640      +/-   ##
============================================
- Coverage     84.70%   84.37%   -0.34%     
- Complexity     3992     4163     +171     
============================================
  Files           578      578              
  Lines         12163    12082      -81     
  Branches       2495     2478      -17     
============================================
- Hits          10303    10194     -109     
- Misses          626      644      +18     
- Partials       1234     1244      +10     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[3flex]

I wouldn't expect this to get merged to main until Kotlin 2 final is released - I don't recall ever supporting new Kotlin versions in snapshots while in beta/RC phase. It's also not backwards compatible, and new fixes in beta5 will mean some workarounds in this branch will be reverted.

It also relies on a snapshot version of poko.

I'm glad it's working well, and thank you for testing, but it's not ready to be merged.

[mgroth0]

Thank you for telling me what I can expect. I appreciate your work on this and there is definitely no rush. I also understand your point about waiting for K2 to stabilizing more first.

I will continue to test this in the meantime.

[mgroth0]

Hey @3flex . I am eager to work with the changes from both this branch as well as main, and I'd be happy to merge or rebase the branches myself. If I do so, would I be able to make a PR into this branch? I would just like to avoid a scenario where I make a merged or branch myself, work off that, and then get out of sync with you if you also merge it to main yourself in the future.

If this sounds alright to you, I'd appreciate you advice on how to do this the best way with git. My current proposal is:

1. I would use git rebase to incrementally take commits from main into this k2 branch. I would do it slowly and carefully, not all at once.
2. I would push my rebased k2 branch to my GitHub fork
3. I would make a PR from my k2 branch to your kotlin-2 branch. I would start the PR early on, after I've rebased the first few commits.
4. If you merge my PR, I expect that would get propagated into this PR?

If I see any complicated merge conflicts, I would consult you. I expect to get this up to main incrementally, not all at once.

I've never done something like this before so I want to check with you that it would work. In particular, I want to make sure the rebasing wouldn't be destructive (I have no idea how GitHub PRs handle rebasing)

[3flex]

It really depends what the change is. This PR/branch is intended only to introduce support for Kotlin 2/K2 so any changes you want to make to this branch would need to support that goal. You'd said it's already working well, so I'm not sure what you'd want to change?

Any other changes for detekt should be raised as separate PRs.

I'll rebase this branch on main when new Kotlin 2.0.0 releases are made so it will stay fairly current. For everything else I'd suggest merging the other way - keep your own branch and occasionally rebase on top of this branch.

I'm sorry but beyond that I can't provide much help, you can try stack overflow to ask questions about git usage.

[mgroth0]

If I recall correctly, and I could have been mistaken, I think that this branch was about 6 months behind main but now it seems more caught up. Though, maybe I made a mistake. It's hard to tell with the rebasing.

keep your own branch and occasionally rebase on top of this branch.

That is basically my plan. The reason I said what I said before was to offer to help with the rebasing of this branch on top of main. I wasn't so much asking for help as much as I was asking if this would be a useful contribution, and I was asking for clarification on what style of git merging you preferred.