Add sanitizer support using GCC toolchain features#3
Add sanitizer support using GCC toolchain features#3saksham-chawla wants to merge 5 commits intocodex/replay-pr-64-basefrom
Conversation
![propel-code-bot[bot]](https://avatars.githubusercontent.com/in/1179004?s=60&v=4){kind=small}
There was a problem hiding this comment.
Several important configuration and CI issues need fixes before sanitizer support is reliable.
Status: Changes Suggested | Risk: Medium | Readiness: 5/10 (Needs Polish)
Issues Identified & Suggestions
- Dependency points to personal fork; use canonical org repo:
MODULE.bazel - Sanitizer tag filters overridden; incompatible tests may run:
.bazelrc,.github/workflows/sanitizers.yml - Workflow cache never saved due to event condition mismatch:
.github/workflows/sanitizers.yml - Suppressions filegroup not wired into sanitizer runtime:
quality/sanitizer/BUILD
Review Details
📁 9 files reviewed | 💬 5 comments
👍 / 👎 individual comments to help improve reviews for you
| git_override( | ||
| module_name = "score_cpp_policies", | ||
| commit = "07a78d6", | ||
| remote = "https://github.com/RSingh1511/score_cpp_policies.git", |
There was a problem hiding this comment.
[Security] The remote points to a personal GitHub repository (RSingh1511/score_cpp_policies), not the organization's (eclipse-score). Personal forks can be deleted, force-pushed, or go stale without notice, breaking all CI and developer builds. This should point to the canonical organization repository.
| remote = "https://github.com/RSingh1511/score_cpp_policies.git", | |
| remote = "https://github.com/eclipse-score/score_cpp_policies.git", |
Context for Agents
The remote points to a personal GitHub repository (`RSingh1511/score_cpp_policies`), not the organization's (`eclipse-score`). Personal forks can be deleted, force-pushed, or go stale without notice, breaking all CI and developer builds. This should point to the canonical organization repository.
```suggestion
remote = "https://github.com/eclipse-score/score_cpp_policies.git",
```
File: MODULE.bazel
Line: 44Chain of Thought
- Validation Decision: accepted
- Confidence: 0.97
- Likelihood Score: 5/5
- Likelihood Reason: Personal forks can be deleted or force-pushed at any time, which would inevitably break builds for all developers and CI. The issue is introduced by this PR and inconsistent with the established pattern of using organization repos.
- Suggested Action: keep
- Tool Calls Used: 3
Reasoning
The comment is accurate and well-supported by evidence:
-
Issue is real: The PR adds lines 40-45, which introduce a new
git_overrideforscore_cpp_policiespointing tohttps://github.com/RSingh1511/score_cpp_policies.git— a personal GitHub repository. -
Inconsistent with existing pattern: All other
git_overrideentries inMODULE.bazeluse organization repositories:trlc→https://github.com/bmw-software-engineering/trlc.gitscore_baselibs→https://github.com/eclipse-score/baselibs.gitscore_communication→https://github.com/eclipse-score/communication.git
-
Introduced by this PR: This is new code (all added lines), not pre-existing debt. The BASE file has no reference to
score_cpp_policiesat all. -
Actionable: The comment provides a concrete fix — change the remote URL to
https://github.com/eclipse-score/score_cpp_policies.git, consistent with the repository's naming convention (score_*packages useeclipse-scoreorganization). -
Real risk: Depending on a personal fork for a build dependency is a well-known supply chain risk. If the owner deletes, force-pushes, or abandons the fork, all builds break.
Evidence Summary
1. File Snapshot (HEAD)
- File:
MODULE.bazel
1: # *******************************************************************************
2: # Copyright (c) 2025 Contributors to the Eclipse Foundation
3: #
4: # See the NOTICE file(s) distributed with this work for additional
5: # information regarding copyright ownership.
6: #
7: # This program and the accompanying materials are made available under the
8: # terms of the Apache License Version 2.0 which is available at
9: # https://www.apache.org/licenses/LICENSE-2.0
10: #
...
2. File Snapshot (BASE)
- File:
MODULE.bazel
1: # *******************************************************************************
2: # Copyright (c) 2025 Contributors to the Eclipse Foundation
3: #
4: # See the NOTICE file(s) distributed with this work for additional
5: # information regarding copyright ownership.
6: #
7: # This program and the accompanying materials are made available under the
8: # terms of the Apache License Version 2.0 which is available at
9: # https://www.apache.org/licenses/LICENSE-2.0
10: #
...
| build:asan --config=asan_ubsan_lsan | ||
| test:asan --test_tag_filters=-no-asan | ||
| build:ubsan --config=asan_ubsan_lsan | ||
| test:ubsan --test_tag_filters=-no-ubsan | ||
| build:lsan --config=asan_ubsan_lsan | ||
| test:lsan --test_tag_filters=-no-lsan |
There was a problem hiding this comment.
[Logic] The shortcut configs (asan, ubsan, lsan) inherit asan_ubsan_lsan via --config=asan_ubsan_lsan but then override --test_tag_filters with a narrower filter. Since Bazel uses last-value-wins for --test_tag_filters, running bazel test --config=asan will build with ASan+UBSan+LSan but only exclude -no-asan tests, not -no-lsan or -no-ubsan. This means tests tagged no-ubsan or no-lsan will still execute under those sanitizers, potentially causing false failures or undefined behavior.
Either remove the shortcut tag overrides (relying on the parent config's filters) or make the shortcuts self-contained with the correct combined filters:
test:asan --test_tag_filters=-no-asan,-no-lsan,-no-ubsan
test:ubsan --test_tag_filters=-no-asan,-no-lsan,-no-ubsan
test:lsan --test_tag_filters=-no-asan,-no-lsan,-no-ubsan
Context for Agents
The shortcut configs (`asan`, `ubsan`, `lsan`) inherit `asan_ubsan_lsan` via `--config=asan_ubsan_lsan` but then override `--test_tag_filters` with a narrower filter. Since Bazel uses last-value-wins for `--test_tag_filters`, running `bazel test --config=asan` will build with ASan+UBSan+LSan **but only exclude `-no-asan` tests**, not `-no-lsan` or `-no-ubsan`. This means tests tagged `no-ubsan` or `no-lsan` will still execute under those sanitizers, potentially causing false failures or undefined behavior.
Either remove the shortcut tag overrides (relying on the parent config's filters) or make the shortcuts self-contained with the correct combined filters:
```
test:asan --test_tag_filters=-no-asan,-no-lsan,-no-ubsan
test:ubsan --test_tag_filters=-no-asan,-no-lsan,-no-ubsan
test:lsan --test_tag_filters=-no-asan,-no-lsan,-no-ubsan
```
File: .bazelrc
Line: 111Chain of Thought
- Validation Decision: accepted
- Confidence: 0.95
- Likelihood Score: 4/5
- Likelihood Reason: Anyone using the shortcut configs (--config=asan, --config=ubsan, --config=lsan) will trigger this issue. Tests tagged no-ubsan or no-lsan will run under those sanitizers when using --config=asan, likely causing false failures. The shortcuts exist to be used, so this will surface for a noticeable portion of users.
- Suggested Action: keep
- Tool Calls Used: 2
Reasoning
The comment correctly identifies a real bug in the newly added code. Here's the evidence:
-
Bazel's
--test_tag_filtersis a last-value-wins flag - confirmed via library docs. When specified multiple times, the last value completely replaces earlier values. -
The config expansion chain creates a conflict:
build:asan --config=asan_ubsan_lsan(line 106) inherits the parent config, which includestest:asan_ubsan_lsan --test_tag_filters=-no-asan,-no-lsan,-no-ubsan(line 101)test:asan --test_tag_filters=-no-asan(line 107) then overrides the inherited test_tag_filters with a narrower filter
-
Net effect of
--config=asan:- Builds with all three sanitizers enabled (ASan+UBSan+LSan via features)
- But only excludes tests tagged
no-asan, NOTno-ubsanorno-lsan - Tests tagged
no-ubsanorno-lsanwill still execute under those active sanitizers
-
This is newly introduced by this PR - all the sanitizer config lines are additions in the diff.
-
The comment is actionable - it provides two concrete solutions: either remove the shortcut tag overrides entirely (relying on parent's filters) or make each shortcut use the full combined filter string.
The same issue applies symmetrically to --config=ubsan and --config=lsan.
Evidence Summary
1. Library Docs
- Library:
bazel - Query:
test_tag_filters flag behavior last value wins accumulating
Now let me search specifically for documentation about flag accumulation behavior and "last value wins" semantics in Bazel:Here is the relevant Bazel documentation regarding `--test_tag_filters` and flag behavior:
---
## `--test_tag_filters`
### Syntax
```
--test_tag_filters=tag[,tag]*
```
...
2. File Snapshot (HEAD)
- File:
.bazelrc - Lines:
85-124
85:
86: # ==============================================================================
87: # Dynamic analysis (sanitizers) for Linux host builds/tests
88: # ==============================================================================
89:
90: # Debug symbols for sanitizer stack traces
91: test:with_debug_symbols --cxxopt=-g1
92: test:with_debug_symbols --strip=never
93:
94: # AddressSanitizer + UndefinedBehaviorSanitizer + LeakSanitizer (Combined)
...
| # SPDX-License-Identifier: Apache-2.0 | ||
| # ******************************************************************************* | ||
|
|
||
| filegroup( |
There was a problem hiding this comment.
[Logic] The repo_suppressions filegroup is declared and made publicly visible, but it is not referenced anywhere in .bazelrc or by the @score_cpp_policies//sanitizers:wrapper / @score_cpp_policies//sanitizers/flags:sanitizer targets. Are these suppression files actually wired into the sanitizer runtime environment (e.g., via ASAN_OPTIONS=suppressions=...)? If not, they will be silently ignored and sanitizer findings they're meant to suppress will still fire.
Context for Agents
The `repo_suppressions` filegroup is declared and made publicly visible, but it is not referenced anywhere in `.bazelrc` or by the `@score_cpp_policies//sanitizers:wrapper` / `@score_cpp_policies//sanitizers/flags:sanitizer` targets. Are these suppression files actually wired into the sanitizer runtime environment (e.g., via `ASAN_OPTIONS=suppressions=...`)? If not, they will be silently ignored and sanitizer findings they're meant to suppress will still fire.
File: quality/sanitizer/BUILD
Line: 14Chain of Thought
- Validation Decision: accepted
- Confidence: 0.65
- Likelihood Score: 3/5
- Likelihood Reason: The filegroup has no visible consumer in this repo's code. The external wrapper might consume it by convention, but there's no evidence of that in this PR. Currently the suppression files are empty so nothing is actually lost, but the infrastructure gap is real if future suppressions are added without wiring them in.
- Suggested Action: keep
- Tool Calls Used: 10
Reasoning
The comment correctly identifies that:
- The
repo_suppressionsfilegroup is declared inquality/sanitizer/BUILDwith public visibility. - There is no reference to this filegroup in
.bazelrc- the sanitizer configs use--run_under=@score_cpp_policies//sanitizers:wrapperand--@score_cpp_policies//sanitizers/flags:sanitizer=...but never reference//quality/sanitizer:repo_suppressions. - No
*SAN_OPTIONS=suppressions=...environment variables are set anywhere in the PR's changes.
The one uncertainty is whether the external @score_cpp_policies//sanitizers:wrapper (from a git_override pointing to RSingh1511/score_cpp_policies.git) might have a built-in convention to discover and use //quality/sanitizer:repo_suppressions. We cannot inspect that external module from this repo. If the wrapper does consume it automatically, the comment would be a false positive.
However, the comment is phrased as a question ("Are these suppression files actually wired into the sanitizer runtime environment?") rather than an assertion, which is appropriate given the uncertainty. It's asking the PR author to confirm the wiring exists somewhere (perhaps in the external wrapper).
The comment is actionable because it:
- Points to a specific potential gap in the infrastructure
- Identifies exactly what mechanism would be needed (e.g.,
ASAN_OPTIONS=suppressions=...) - Asks for concrete verification
Currently, the suppression files are empty (just comments), so the practical impact is zero right now. But the comment is valid as a design review concern about the infrastructure being incomplete.
Evidence Summary
1. File Snapshot (HEAD)
- File:
MODULE.bazel
1: # *******************************************************************************
2: # Copyright (c) 2025 Contributors to the Eclipse Foundation
3: #
4: # See the NOTICE file(s) distributed with this work for additional
5: # information regarding copyright ownership.
6: #
7: # This program and the accompanying materials are made available under the
8: # terms of the Apache License Version 2.0 which is available at
9: # https://www.apache.org/licenses/LICENSE-2.0
10: #
...
2. File Snapshot (HEAD)
- File:
.bazelrc
1: # *******************************************************************************
2: # Copyright (c) 2025 Contributors to the Eclipse Foundation
3: #
4: # See the NOTICE file(s) distributed with this work for additional
5: # information regarding copyright ownership.
6: #
7: # This program and the accompanying materials are made available under the
8: # terms of the Apache License Version 2.0 which is available at
9: # https://www.apache.org/licenses/LICENSE-2.0
10: #
...
3. File Snapshot (HEAD)
- File:
.github/workflows/sanitizers.yml
1: # *******************************************************************************
2: # Copyright (c) 2026 Contributors to the Eclipse Foundation
3: #
4: # See the NOTICE file(s) distributed with this work for additional
5: # information regarding copyright ownership.
6: #
7: # This program and the accompanying materials are made available under the
8: # terms of the Apache License Version 2.0 which is available at
9: # https://www.apache.org/licenses/LICENSE-2.0
10: #
...
4. File Snapshot (HEAD)
- File:
quality/sanitizer/lsan.supp
1: # *******************************************************************************
2: # Copyright (c) 2026 Contributors to the Eclipse Foundation
3: #
4: # See the NOTICE file(s) distributed with this work for additional
5: # information regarding copyright ownership.
6: #
7: # This program and the accompanying materials are made available under the
8: # terms of the Apache License Version 2.0 which is available at
9: # https://www.apache.org/licenses/LICENSE-2.0
10: #
...
5. File Snapshot (HEAD)
- File:
quality/sanitizer/asan.supp
1: # *******************************************************************************
2: # Copyright (c) 2026 Contributors to the Eclipse Foundation
3: #
4: # See the NOTICE file(s) distributed with this work for additional
5: # information regarding copyright ownership.
6: #
7: # This program and the accompanying materials are made available under the
8: # terms of the Apache License Version 2.0 which is available at
9: # https://www.apache.org/licenses/LICENSE-2.0
10: #
...
6. File Snapshot (HEAD)
- File:
quality/sanitizer/ubsan.supp
1: # *******************************************************************************
2: # Copyright (c) 2026 Contributors to the Eclipse Foundation
3: #
4: # See the NOTICE file(s) distributed with this work for additional
5: # information regarding copyright ownership.
6: #
7: # This program and the accompanying materials are made available under the
8: # terms of the Apache License Version 2.0 which is available at
9: # https://www.apache.org/licenses/LICENSE-2.0
10: #
...
7. File Snapshot (HEAD)
- File:
quality/sanitizer/tsan.supp
1: # *******************************************************************************
2: # Copyright (c) 2026 Contributors to the Eclipse Foundation
3: #
4: # See the NOTICE file(s) distributed with this work for additional
5: # information regarding copyright ownership.
6: #
7: # This program and the accompanying materials are made available under the
8: # terms of the Apache License Version 2.0 which is available at
9: # https://www.apache.org/licenses/LICENSE-2.0
10: #
...
| disk-cache: true | ||
| repository-cache: true | ||
| bazelisk-cache: true | ||
| cache-save: ${{ github.event_name == 'push' }} |
There was a problem hiding this comment.
[Logic] cache-save is set to ${{ github.event_name == 'push' }}, but this workflow only triggers on pull_request and merge_group events (lines 17-20). The expression github.event_name == 'push' will always evaluate to false, so the Bazel disk/repository cache is never saved. On every run the cache starts empty, negating the caching setup entirely. Either add a push trigger to the workflow, or change the condition to match one of the actual trigger events (e.g., github.event_name == 'merge_group').
Context for Agents
[**Bug**] `cache-save` is set to `${{ github.event_name == 'push' }}`, but this workflow only triggers on `pull_request` and `merge_group` events (lines 17-20). The expression `github.event_name == 'push'` will **always** evaluate to `false`, so the Bazel disk/repository cache is never saved. On every run the cache starts empty, negating the caching setup entirely. Either add a `push` trigger to the workflow, or change the condition to match one of the actual trigger events (e.g., `github.event_name == 'merge_group'`).
File: .github/workflows/sanitizers.yml
Line: 48Chain of Thought
- Validation Decision: accepted
- Confidence: 0.00
- Likelihood Score: 0/5
- Suggested Action: keep
- Tool Calls Used: 16
Reasoning
Failed to parse validation response
Evidence Summary
1. File Lookup
- Filename:
.yml - Max Results:
10
No files found matching '.yml'
2. File Lookup
- Filename:
sanitizers.yml
No files found matching 'sanitizers.yml'
3. Library Docs
- Library:
bazel-contrib/setup-bazel - Query:
cache-save parameter
The library wasn't found on npm or Context7. Let me search on GitHub — `bazel-contrib/setup-bazel` is a GitHub Action, so let me try searching its source code directly.The library isn't indexed in the available registries or Context7. Since `bazel-contrib/setup-bazel` is a GitHub Action, let me try to find its documentation through alternative searches.Unfortunately, the `bazel-contrib/setup-bazel` GitHub Action is not indexed in the documentation sources or package registries available to me. However, based on publicly known documentation for this GitHub Action, here is the relevant information about the **`cache-save`** parameter:
---
## `cache-save` Parameter — `bazel-contrib/setup-bazel`
### Description
The `cache-save` input controls **whether caches are saved** at the end of a workflow run. This is useful for optimizing CI pipelines by skipping cache saves on certain runs (e.g., pull request builds) where you don't want to update the cache.
...
4. File Lookup
- Filename:
workflows - Max Results:
10
No files found matching 'workflows'
5. File Snapshot (HEAD)
- File:
.github/workflows/sanitizers.yml
1: # *******************************************************************************
2: # Copyright (c) 2026 Contributors to the Eclipse Foundation
3: #
4: # See the NOTICE file(s) distributed with this work for additional
5: # information regarding copyright ownership.
6: #
7: # This program and the accompanying materials are made available under the
8: # terms of the Apache License Version 2.0 which is available at
9: # https://www.apache.org/licenses/LICENSE-2.0
10: #
...
6. File Lookup
- Filename:
test.yml
No files found matching 'test.yml'
7. File Lookup
- Filename:
ci.yml
No files found matching 'ci.yml'
8. File Lookup
- Filename:
bazel.yml
No files found matching 'bazel.yml'
9. File Lookup
- Filename:
build.yml
Found 1 file(s) matching 'build.yml':
- .github/workflows/build.yml
10. File Snapshot (BASE)
- File:
.github/workflows/build.yml
1: # *******************************************************************************
2: # Copyright (c) 2025 Contributors to the Eclipse Foundation
3: #
4: # See the NOTICE file(s) distributed with this work for additional
5: # information regarding copyright ownership.
6: #
7: # This program and the accompanying materials are made available under the
8: # terms of the Apache License Version 2.0 which is available at
9: # https://www.apache.org/licenses/LICENSE-2.0
10: #
...
| bazel test \ | ||
| --config=${{ matrix.sanitizer_config }} \ | ||
| //score/... \ | ||
| --build_tag_filters=-rust \ | ||
| --test_tag_filters=-rust \ |
There was a problem hiding this comment.
[Testing] Passing --test_tag_filters=-rust here overwrites the filter list that --config=asan_ubsan_lsan adds in .bazelrc (--test_tag_filters=-no-asan,-no-lsan,-no-ubsan). Bazel does not merge multiple --test_tag_filters flags—the last one wins—so all tests tagged no-asan/no-lsan/no-ubsan will now run under sanitizers even though they are explicitly marked incompatible, causing spurious CI failures. Either drop the explicit flag or include all exclusions in a single list, e.g. --test_tag_filters=-rust,-no-asan,-no-lsan,-no-ubsan.
Context for Agents
Passing `--test_tag_filters=-rust` here overwrites the filter list that `--config=asan_ubsan_lsan` adds in `.bazelrc` (`--test_tag_filters=-no-asan,-no-lsan,-no-ubsan`). Bazel does not merge multiple `--test_tag_filters` flags—the last one wins—so all tests tagged `no-asan`/`no-lsan`/`no-ubsan` will now run under sanitizers even though they are explicitly marked incompatible, causing spurious CI failures. Either drop the explicit flag or include all exclusions in a single list, e.g. `--test_tag_filters=-rust,-no-asan,-no-lsan,-no-ubsan`.
File: .github/workflows/sanitizers.yml
Line: 60Chain of Thought
- Validation Decision: accepted
- Confidence: 0.97
- Likelihood Score: 5/5
- Likelihood Reason: The Bazel
--test_tag_filtersflag definitively uses "last one wins" semantics (not accumulation). This is confirmed by Bazel GitHub issue #7322 which is specifically a feature request to change this behavior. The command line--test_tag_filters=-rustwill inevitably override the.bazelrcconfig's--test_tag_filters=-no-asan,-no-lsan,-no-ubsan, causing sanitizer-incompatible tests to run every single CI invocation. - Suggested Action: keep
- Tool Calls Used: 2
Reasoning
The review comment claims:
--test_tag_filters=-ruston the command line (workflow line 60) overwrites--test_tag_filters=-no-asan,-no-lsan,-no-ubsanfrom.bazelrcline 101 (set viatest:asan_ubsan_lsanconfig).- Bazel does not merge multiple
--test_tag_filtersflags — the last one wins. - This will cause tests tagged
no-asan/no-lsan/no-ubsanto run under sanitizers, causing spurious CI failures.
Evidence gathered:
-
.bazelrcat HEAD (line 101):test:asan_ubsan_lsan --test_tag_filters=-no-asan,-no-lsan,-no-ubsan— confirmed this setting exists. -
Workflow file (line 57-60): The command runs
--config=asan_ubsan_lsanfirst, then--test_tag_filters=-rustafter it on the command line. Since Bazel expands--config=Xin place, the effective order is--test_tag_filters=-no-asan,-no-lsan,-no-ubsan(from config expansion) followed by--test_tag_filters=-rust(from explicit CLI), and the last one wins. -
Bazel "last one wins" behavior confirmed: GitHub issue Change
build_tag_filtersandtest_tag_filtersoptions to accumulate uses bazelbuild/bazel#7322 is titled "Changebuild_tag_filtersandtest_tag_filtersoptions to accumulate uses" and explicitly states that command-line--test_tag_filters"totally ignore those options" set in.bazelrc. This is a known, documented limitation — the flag does NOT accumulate. -
Both files are new in this PR —
.github/workflows/sanitizers.ymlis a brand new file and the sanitizer configs in.bazelrcare also new additions, so this is a bug introduced by this PR, not pre-existing debt. -
The suggested fix is correct: Combining all exclusions into a single
--test_tag_filters=-rust,-no-asan,-no-lsan,-no-ubsanwould properly filter all intended tags. -
Additional note: The
.bazelrcalso hastest --test_tag_filters=-manualon line 21, which would similarly be overridden by the command line flag, potentially also runningmanual-tagged tests. The comment doesn't mention this but it's another consequence of the same issue.
The ...
Evidence Summary
1. File Snapshot (HEAD)
- File:
.bazelrc
1: # *******************************************************************************
2: # Copyright (c) 2025 Contributors to the Eclipse Foundation
3: #
4: # See the NOTICE file(s) distributed with this work for additional
5: # information regarding copyright ownership.
6: #
7: # This program and the accompanying materials are made available under the
8: # terms of the Apache License Version 2.0 which is available at
9: # https://www.apache.org/licenses/LICENSE-2.0
10: #
...
2 participants
Summary
Adopts centralized sanitizer infrastructure from
score_cpp_policies.Changes
score_cpp_policiesdev dependency for sanitizer wrapper/flagsquality/sanitizer/to.bazelrcquality/sanitizer/folderNotes for Reviewer
Pre-Review Checklist for the PR Author
Checklist for the PR Reviewer
Post-review Checklist for the PR Author
References
Closes #
Add sanitizer support using GCC toolchain features
This pull request integrates centralized sanitizer infrastructure by adopting
score_cpp_policiesas a development dependency. It introduces comprehensive sanitizer configurations (AddressSanitizer, UndefinedBehaviorSanitizer, LeakSanitizer, ThreadSanitizer) into the.bazelrcfile, leveraging the new dependency for flags and wrappers. Additionally, repository-specific suppression files for these sanitizers are added to thequality/sanitizer/directory, and the GitHub Actions workflow is updated to execute Bazel tests with the new sanitizer configurations. Rust tests are explicitly tagged to be excluded from C++ sanitizer runs.Architecture Diagram:
flowchart TD subgraph CI_Layer A["GitHub Actions (+69 lines)"] end subgraph Build_System_Layer B["Bazel Build System"] C[/".bazelrc (+40 lines)"/] D["MODULE.bazel (+6 lines)"] end subgraph Configuration_Layer E[/".suppression files (+71 lines)"/] F["quality/sanitizer/BUILD (+23 lines)"] end subgraph Dependency_Layer G["score_cpp_policies"] end subgraph Application_Layer H["C++ Codebase"] I["Rust Tests (score_log_bridge/BUILD +5 lines)"] end A -->|triggers| B B -->|reads config| C C -->|uses flags from| G C -->|applies| E F -->|defines filegroup for| E B -->|builds/tests| H B -->|filters out| I D -->|adds dependency| GThis summary was automatically generated by @propel-code-bot