Skip to content

Conversation

@rbeazleyspot
Copy link
Contributor

@rbeazleyspot rbeazleyspot commented Jun 25, 2025

WIP

exploring analysis tests with different configuration properties set

arrange.bzl produces a small set of targets

[main_target_library] --dep--> [dependency_a] --dep--> [dependency_a_trans_dep_jar]

experimental_prune_transitive_deps_tests.bzl

has two tests, one test enables experimental_prune_transitive_deps the other dosnt.

basic assertions around the KotlinCompile action to check --classpath, --direct_dependencies and inputs

[dependency_a_trans_dep_jar] should be dropped when the experimental flag is enabled

for these tests to work I think all flags need to be public, ie not the ones in the internal/kotlin/kt_configure_toolchains function

These tests dont run perfectly yet but i thought i would share what i have so far, i have an issue with checking absolute paths atm

  0: bazel-out/darwin_arm64-fastbuild/bin/src/test/starlark/rules/enabled_dependency_a.abi.jar
actual argv:
  0: external/+rules_kotlin_extensions+com_github_jetbrains_kotlin_git/lib/annotations-13.0.jar
  1: external/+rules_kotlin_extensions+com_github_jetbrains_kotlin_git/lib/kotlin-stdlib.jar
  2: external/+rules_kotlin_extensions+com_github_jetbrains_kotlin_git/lib/kotlin-stdlib-jdk7.jar
  3: external/+rules_kotlin_extensions+com_github_jetbrains_kotlin_git/lib/kotlin-stdlib-jdk8.jar
  4: bazel-out/darwin_arm64-fastbuild-ST-d9dfb3145612/bin/src/test/starlark/rules/enabled_dependency_a.abi.jar

im guessing darwin_arm64-fastbuild-ST-d9dfb3145612 is something to do with the "reconfiguration" when the analysis test runs with the new flags

agluszak added a commit to agluszak/rules_kotlin that referenced this pull request Dec 7, 2025
Revive PR bazelbuild#1343 by rbeazleyspot which adds analysis tests for the
experimental_prune_transitive_deps feature.

The original tests failed because config_settings creates a configuration
transition, causing output paths to include a hash suffix (e.g.,
k8-fastbuild-ST-xxx). Fixed by comparing file basenames instead of full
paths using matching.file_basename_equals() predicates.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
agluszak added a commit to agluszak/rules_kotlin that referenced this pull request Dec 8, 2025
Revive PR bazelbuild#1343 by rbeazleyspot which adds analysis tests for the
experimental_prune_transitive_deps feature.

The original tests failed because config_settings creates a configuration
transition, causing output paths to include a hash suffix (e.g.,
k8-fastbuild-ST-xxx). Fixed by comparing file basenames instead of full
paths using matching.file_basename_equals() predicates.
Bencodes pushed a commit that referenced this pull request Dec 18, 2025
* Add example analysis_test with configuration

* Fix analysis tests for experimental_prune_transitive_deps

Revive PR #1343 by rbeazleyspot which adds analysis tests for the
experimental_prune_transitive_deps feature.

The original tests failed because config_settings creates a configuration
transition, causing output paths to include a hash suffix (e.g.,
k8-fastbuild-ST-xxx). Fixed by comparing file basenames instead of full
paths using matching.file_basename_equals() predicates.

* Migrate from KSP1 (compiler plugin) to KSP2 (standalone tool) (#1405)

* Migrate from KSP1 (compiler plugin) to KSP2 (standalone tool)

KSP2 is a standalone program that runs separately from the Kotlin compiler,
unlike KSP1 which was a compiler plugin. This migration required:

- Add KSP2 tool definition in kotlin/compiler/ksp.bzl and BUILD.bazel
- Implement _run_ksp_builder_actions in compile.bzl to invoke KSP2 as a
  separate action that produces tree artifacts for generated sources
- Add tree_artifact_packager worker to package KSP2 output directories
  into srcjars for downstream compilation
- Fix source-roots handling: KSP2 expects directory paths, not file paths
- Update examples/ksp to use bzlmod (MODULE.bazel) instead of WORKSPACE
- Expand KSP test coverage with Dagger-based coffee example demonstrating
  mixed Kotlin/Java code generation scenarios

Key changes:
- KSP now runs as a pre-compilation step producing generated sources
- Generated sources are packaged into srcjars and compiled with main sources
- Removed KSP1-specific code from KotlinToolchain and InternalCompilerPlugins

* WIP

* WIP

* Fix

* Fix

* Move staging to the builder

* Add tests, remove unused code

* Fix test

* Update KSP to 2.3.3

* Remove the note about KSP multiplex workers support

* Address code review issues

* Revert unnecessary change

* compile against the ksp concrete classes

* Bump bazel version on CI

* Bump RBE ubuntu version to support bazel 7.7.1

* Bump bazel version on CI to 8.4.2

* Fix stardoc generation

---------

Co-authored-by: Corbin McNeely-Smith <[email protected]>

* Fix post-merge error (#1420)

* Document x_lambdas and x_sam_conversions defaults (#1419)

* Document x_lambdas and x_sam_conversions defaults

Explain that rules_kotlin defaults to "class" for x_lambdas and
x_sam_conversions, differing from Kotlin 2.x/Gradle's "indy"
default. Add README section with configuration examples for
Gradle-compatible bytecode generation.

Update API docs in opts.kotlinc.bzl to clarify the default
behavior and compatibility implications.

Closes #1417

* Simplify README lambda bytecode documentation

Reduce the documentation to a concise note within the existing
"Kotlin and Java compiler flags" section, with a single code
example showing how to configure for invokedynamic behavior.

---------

Co-authored-by: Ross Beazley <[email protected]>
Co-authored-by: Corbin McNeely-Smith <[email protected]>
Co-authored-by: Jonathan Mohrbacher <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant