Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to prevent Clang headers from being used #2842

Open
wmmc88 opened this issue May 30, 2024 · 5 comments
Open

Unable to prevent Clang headers from being used #2842

wmmc88 opened this issue May 30, 2024 · 5 comments

Comments

@wmmc88
Copy link

wmmc88 commented May 30, 2024

All versions of LLVM 18 have a bug where the __prefetch intrinsic has the wrong definition. This bug was fixed in llvm/llvm-project#93235, but will not be released until LLVM 19 comes out.

When bindgen invokes clang to parse the headers, it looks like clang is actually using its bugged intrin.h which brings in the invalid signature for __prefetch. This leads to the failure to generate bindings for any header that pulls in msvc's intrin.h on aarch64. I attempted to use clang's -fno-builtin arg to prevent bindgen from pulling in the wrong definition of __prefetch, but it seems to not have any effect here.

Bindgen Invocation

use std::env;
use std::path::PathBuf;

fn main() {
    let bindings = bindgen::Builder::default()
        .header_contents(
            "input.h",
            r#"
void __prefetch(const void *);"#,
        )
        .parse_callbacks(Box::new(bindgen::CargoCallbacks::new()))
        .clang_args([
            "-fms-compatibility",
            "-fms-extensions",
            "-fdelayed-template-parsing",
            "-fno-builtin", // attempt to prevent intrin.h from clang from being used (not working)
            "-fno-builtin-__prefetch" // another not working attempt
        ])
        .generate()
        .expect("Unable to generate bindings");

    let out_path = PathBuf::from(env::var("OUT_DIR").unwrap());
    bindings
        .write_to_file(out_path.join("bindings.rs"))
        .expect("Couldn't write bindings!");
}

Actual Results

cargo build --target aarch64-pc-windows-msvc
   Compiling bindgen-test v0.1.0 (D:\git-repos\bindgen-test)
error: failed to run custom build command for `bindgen-test v0.1.0 (D:\git-repos\bindgen-test)`

Caused by:
  process didn't exit successfully: `D:\git-repos\bindgen-test\target\debug\build\bindgen-test-28575ca189a67a38\build-script-build` (exit code: 101)
  --- stdout
  cargo:rerun-if-env-changed=TARGET
  cargo:rerun-if-env-changed=BINDGEN_EXTRA_CLANG_ARGS_aarch64-pc-windows-msvc
  cargo:rerun-if-env-changed=BINDGEN_EXTRA_CLANG_ARGS_aarch64_pc_windows_msvc
  cargo:rerun-if-env-changed=BINDGEN_EXTRA_CLANG_ARGS

  --- stderr
  D:\git-repos\bindgen-test\input.h:2:6: error: conflicting types for '__prefetch'
  D:\git-repos\bindgen-test\input.h:2:6: note: '__prefetch' is a builtin with type 'void (void *)'
  thread 'main' panicked at build.rs:23:10:
  Unable to generate bindings: ClangDiagnostic("D:\\git-repos\\bindgen-test\\input.h:2:6: error: conflicting types for '__prefetch'\n")
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Expected Results

Should compile sucessfully

@workingjubilee
Copy link
Member

why is clang not issuing a patch release?

@workingjubilee
Copy link
Member

Unfortunately, this can't be backported (there are no more 18.x releases, and this change is a breaking change), so I'll see if I can get a workaround added on MSVC's side for Clang 18.

ah.

@pvdrz
Copy link
Contributor

pvdrz commented Jul 17, 2024

@workingjubilee @wmmc88 is there something we can do from bindgen's side to mitigate this?

@wmmc88
Copy link
Author

wmmc88 commented Jul 17, 2024

@workingjubilee @wmmc88 is there something we can do from bindgen's side to mitigate this?

Is it possible for bindgen to provide a way to prevent the use of clang's builtin headers (i.e. __prefetch.h)?

@pvdrz
Copy link
Contributor

pvdrz commented Sep 7, 2024

it depends, if you can filter it using allowlist_file or any other allowlist method maybe we can do something about it.

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

No branches or pull requests

3 participants