CohenArthur
CohenArthur
Ah, I see. I thought it was a different set of tests failing, related to https://github.com/Rust-GCC/gccrs/issues/1446 but it's different. Some of these are an "easy fix", I'll get them done...
I'm getting the same "test1canary" failure on one of the SPARC machines on the build farm. Here is the gimple output: ```c __attribute__((cdecl)) struct builtin_macro_eager1::main () { struct D.139; RUSTTMP.1...
I think either solution is ok. `c_int` will not always resolve to an `i32` depending on the target. I'm not sure how this will affect the testsuite on some weirder...
Yes, that looks good :) I like it. Do you want to do the PR or leave it as a `good-first-pr` @tschwinge ?
> Either way is fine for me -- but I'm not sure, is this a `good-first-pr` given that it's just some repetitive, tedious editing? In that case, it might just...
> Can we define `__c_int` as a builtin type, like `i32` or `i8`? Perhaps gated behind a compiler flag. I think this could cause issues down the line. The definition...
@tschwinge the checkout action does take a lot of time and I'm not sure why. We do the following: ```yaml - uses: actions/checkout@v3 with: ref: ${{ github.event.pull_request.head.sha }} fetch-depth: 0...
> do we have to update the syntax you have provided for every single file? and will the new syntax will stay the same if some do `cargo fmt`? please...
Sounds good @ArshErgon :) Thanks. Assigning you!
Done @DrMahad! Thank you :)