Skip to content

Workspace: add shared sources case to transition test#8206

Open
LeFrosch wants to merge 2 commits intobazelbuild:masterfrom
LeFrosch:pull/9fd237fca78e0a8529643e2bf8ae06e24f674461
Open

Workspace: add shared sources case to transition test#8206
LeFrosch wants to merge 2 commits intobazelbuild:masterfrom
LeFrosch:pull/9fd237fca78e0a8529643e2bf8ae06e24f674461

Conversation

@LeFrosch
Copy link
Collaborator

@LeFrosch LeFrosch commented Mar 4, 2026

Test equivalence class computation as part of the transition test.

@gemini-code-assist
Copy link

Summary of Changes

Hello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the TransitionTest by adding comprehensive test cases for equivalence class computation. It specifically validates how the system handles shared source files and per-file compiler settings, ensuring that distinct configurations are generated when necessary and that shared files with identical settings correctly collapse into a single configuration. This improves the robustness of the configuration management logic.

Highlights

  • Test Coverage Expansion: Expanded the TransitionTest to include new targets (//main:shared_a, //main:shared_b) in the project view, enhancing the scope of configuration testing.
  • New Configuration Checks: Introduced two new verification methods, checkPerFileCompilerSettings() and checkSharedSourceFile(), to validate equivalence class computation for different compilation scenarios.
  • Per-File Compiler Settings Verification: Added a check to ensure that simple.cc correctly yields two distinct configurations when compiled with different flags (-DFOO vs. -DBAR), confirming proper handling of per-file settings.
  • Shared Source File Equivalence: Implemented a check to verify that shared.cc, when used by multiple targets (shared_a, shared_b) with identical compilation settings, correctly results in a single equivalence class.
  • Build File Updates: Modified the BUILD file to import cc_library and define the new shared_a and shared_b targets, which both utilize the newly added shared.cc.
Changelog
  • clwb/tests/headlesstests/com/google/idea/blaze/clwb/TransitionTest.java
    • Added new targets //main:shared_a and //main:shared_b to the project view for testing.
    • Integrated calls to checkPerFileCompilerSettings() and checkSharedSourceFile() into the main test flow.
    • Implemented checkPerFileCompilerSettings() to verify distinct compiler settings for simple.cc.
    • Implemented checkSharedSourceFile() to confirm single equivalence class for shared.cc.
  • clwb/tests/projects/transition/main/BUILD
    • Updated load statement to include cc_library.
    • Added cc_library targets shared_a and shared_b, both using shared.cc.
  • clwb/tests/projects/transition/main/shared.cc
    • Added a new C++ source file containing a simple shared_function.
Activity
  • No activity has been recorded for this pull request yet.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request adds a test case for shared sources with transitions, which is a good addition. I've found a logical flaw in one of the new test methods, checkPerFileCompilerSettings, where the assertion isn't strong enough to catch potential issues. My review includes a suggestion to fix this.

Comment on lines +118 to +129
for (final var config : configurations) {
final var settings = config.getCompilerSettings(CLanguageKind.CPP, file);
assertThat(settings).isNotNull();

final var switches = settings.getCompilerSwitches();
assertThat(switches).isNotNull();

final var rawSwitches = switches.getList(Format.RAW);

// each per-file config must contain exactly one of -DFOO or -DBAR
assertThat(rawSwitches.contains("-DFOO") ^ rawSwitches.contains("-DBAR")).isTrue();
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The current logic in the for-loop does not guarantee that one of each configuration (-DFOO and -DBAR) is present. It only checks that each configuration has either -DFOO or -DBAR, but not both. For instance, if both configurations had the -DFOO flag, this test would incorrectly pass. A better approach would be to collect the switches from all configurations and then assert that one has -DFOO and one has -DBAR, similar to how checkResolveConfigurations is implemented.

    final var compilerSwitches =
        configurations.stream()
            .map(config -> config.getCompilerSettings(CLanguageKind.CPP, file).getCompilerSwitches())
            .filter(Objects::nonNull)
            .map(switches -> switches.getList(Format.RAW))
            .toList();

    assertThat(compilerSwitches).hasSize(2);
    assertThat(compilerSwitches.stream().filter(it -> it.contains("-DFOO"))).hasSize(1);
    assertThat(compilerSwitches.stream().filter(it -> it.contains("-DBAR"))).hasSize(1);

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@LeFrosch LeFrosch marked this pull request as ready for review March 4, 2026 14:50
@github-actions github-actions bot added product: CLion CLion plugin awaiting-review Awaiting review from Bazel team on PRs labels Mar 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

awaiting-review Awaiting review from Bazel team on PRs product: CLion CLion plugin

Projects

Status: Untriaged

Development

Successfully merging this pull request may close these issues.

2 participants