Fix tests that fail when run concurrently. - #3467
Merged
Merged
Conversation
beckysiegel
pushed a commit
to chromium/chromium
that referenced
this pull request
Sep 8, 2026
The Build From Tarball builder (https://ci.chromium.org/ui/p/infra/builders/cron/Build%20From%20Tarball) aims to build Chromium from the source code tarball rather than from a git checkout. When building from a git checkout, Chromium simply downloads precompiled binaries of rustc and bindgen. However, when building from a *source tarball*, it compiles the latest rustc from source itself, then builds bindgen, and... ...there were a couple bugs in that build! In particular: * The newest `rustc` began reserving attributes starting with `rustc` for exclusive use by the `rustc` compiler (fixed in bindgen here rust-lang/rust-bindgen#3372 and here rust-lang/rust-bindgen#3388) * Test expectations weren't regenerated for libgclang 23 (fixed here rust-lang/rust-bindgen#3430) * Bindgen started inserting dummy fields into bitfields in a way that caused misalignment for some Rust-Chromium structs (fixed here rust-lang/rust-bindgen#3431) After all those fixes were merged, two more tests were discovered to now be failing. An upstream pull requests has been opened here rust-lang/rust-bindgen#3467 but we simply add them to EXCLUDED_TESTS for now so we can go ahead and unbreak the builder. To verify this fix, I ran both `build_rust.py` and `build_bindgen.py` locally and both pass without issue. Bug: 510018493 Change-Id: I290d87a6ea3042b419c23eb89a5b1db7cb376f63 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8372616 Commit-Queue: Julia Hansbrough <flowerhack@google.com> Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org> Cr-Commit-Position: refs/heads/main@{#1694170}
beckysiegel
pushed a commit
to chromium/chromium
that referenced
this pull request
Sep 9, 2026
With the merging of https://chromium-review.git.corp.google.com/c/chromium/src/+/8372616, there's now only two tests that we must excluded when running them for Chromium, so let's re-enable the non-problematic tests. (Fixing those remaining two tests is a job for rust-lang/rust-bindgen#3467.) Bug: 558838938 Change-Id: Ifa2437c668a63ff8aeb0cfddcc29e4f6fa25c257 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8371988 Commit-Queue: Devon Loehr <dloehr@google.com> Reviewed-by: Arthur Eubanks <aeubanks@google.com> Commit-Queue: Arthur Eubanks <aeubanks@google.com> Reviewed-by: Devon Loehr <dloehr@google.com> Cr-Commit-Position: refs/heads/main@{#1694751}
When building & testing bindgen on a multicore machine, I noticed persistent failures in `header_issue_753_h` and `header_macro_fallback_include_builtin_h`. Upon investigation, it seems the root cause is: * Both headers enable `--clang-macro-fallback`. * BUT, neither provides a `--clang_macro_fallback_build_dir`. * So, scratch files are (by default) written directly into the current directory (see https://github.com/flowerhack/rust-bindgen/blob/main/bindgen/ir/context.rs#L2089). * When these tests simultaneously tried to write to the same file ("-precompile.h.pch"), and clobbered each other. By creating a temporary directory for `clang_macro_fallback_build_dir` when `clang-macro-fallback` is passed in, we ensure the tests remain isolated by writing that file to different temporary directories. (I think perhaps this issue hasn't come up for most users since running tests on a machine with *lots* of cores may be somewhat uncommon? But this should fix it for everyone.)
algitbot
pushed a commit
to alpinelinux/aports
that referenced
this pull request
Sep 9, 2026
fix_tests_that_fail_when_run_concurrently.patch source: rust-lang/rust-bindgen#3467 patch upstream test_wrap_static_fns workaround for aarch64 to include 32bit arm, issue: rust-lang/rust-bindgen#3234
Contributor
Author
|
@emilio ! Should be a fairly simple merge, I hope~ |
emilio
self-requested a review
September 10, 2026 07:52
emilio
approved these changes
Sep 10, 2026
| compare_generated_header(&header, builder, check_roundtrip) | ||
| }); | ||
| let result = | ||
| create_bindgen_builder(&header).and_then(|mut builder| { |
Contributor
There was a problem hiding this comment.
Since we're panicking anyway below, maybe worth simplifying this to:
let builder = create_bindgen_builder(&header).unwrap();
builder.builder.clang_macro_fallback_build_dir(tmpdir.path());
let check_roundtrip = ...;
compare_generated_header(...).unwrap();Or so?
But I guess looks good either way.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When building & testing bindgen on a multicore machine, I noticed persistent failures in
header_issue_753_handheader_macro_fallback_include_builtin_h.Upon investigation, it seems the root cause is:
--clang-macro-fallback.--clang_macro_fallback_build_dir.By creating a temporary directory for
clang_macro_fallback_build_dirfor whenclang-macro-fallbackis passed in,we ensure the tests remain isolated by writing that file to different temporary directories.
(I think perhaps this issue hasn't come up for most users since running tests on a machine with lots of cores may be somewhat uncommon? But this should fix it for everyone.)