Ensure the bug was not already reported by searching on GitHub under Issues.
If you're unable to find an open issue addressing the problem, open a new one. Be sure to include a title and clear description, as much relevant information as possible, and a code sample or an executable test case demonstrating the expected behavior that is not occurring.
Open a new GitHub pull request with the patch.
Ensure the PR description clearly describes the problem and solution. Include the relevant issue number if applicable.
Before submitting, GCC development requires copyright assignment or the Developer's Certificate of Origin sign-off. Please see the Contributing to GCC guide or Developer's Certificate of Origin (DCO) Sign-off guide.
Patches sent to the gcc-rust mailing list are likewise welcome. These will be imported into a GitHub PR to follow the normal review process, and the link to the GitHub PR sent to the submitter.
Suggest your change in the Zulip and start writing code.
Do not open an issue on GitHub until you have collected positive feedback about the change. GitHub issues are primarily intended for bug reports and fixes.
The PR policy: Everything has to go through a PR
Reviewers/Maintainers of the project (aka people who have bors rights) should be pinged for reviews/questions.
A PR can have one or several commits (split should have a technical/logical reason, ie. no fixup-ish commit)
Avoid PR‘s with merge commit unless there’s a good reason
Where possible please add test cases to gcc/testsuite/rust/ for all PRs. Some issues may not be testable via dejagnu/automation such as debug dump changes.
Follow the GCC coding style (see clang-format below).
PRs won't be merged until the build and tests pass.
Please take the time to create good git commit messages. See the existing format of them in the git log or refer to something like: https://chris.beams.io/posts/git-commit/
clang-format locally.github/workflows/clang-format.yml) is doing, with clang-format-10 being available locally, and avoiding the Docker overhead.$ wget 'https://github.com/DoozyX/clang-format-lint-action/raw/v0.11/run-clang-format.py' $ cp contrib/clang-format .clang-format $ python3 run-clang-format.py --clang-format-executable clang-format-10 --recursive --extensions h,cc gcc/rust/
on a given patch using python scripts See the clang-format documentation :
$ git diff -U0 --no-color HEAD^ | clang-format-diff.py -i -p1
using git interface
At least on Debian and its derivative, each clang-format packages also comes with git-clang-format command that can be used easily. It applies on staged changes, and any modification can be seen as unstaged changes:
$ git diff --cached diff --git a/gcc/rust/rust-abi.h b/gcc/rust/rust-abi.h index bd3043295ce..9559374ce60 100644 --- a/gcc/rust/rust-abi.h +++ b/gcc/rust/rust-abi.h @@ -22,10 +22,10 @@ namespace Rust { enum ABI { UNKNOWN, - RUST, + RUST, INTRINSIC, C, - CDECL, + CDECL, STDCALL, FASTCALL, }; gccrs/gcc/rust on dkm/clang_format [$!+?] ❯ git clang-format changed files: gcc/rust/rust-abi.h gccrs/gcc/rust on dkm/clang_format [$!+?] $ git diff rust-abi.h diff --git a/gcc/rust/rust-abi.h b/gcc/rust/rust-abi.h index 9559374ce60..bd3043295ce 100644 --- a/gcc/rust/rust-abi.h +++ b/gcc/rust/rust-abi.h @@ -22,10 +22,10 @@ namespace Rust { enum ABI { UNKNOWN, - RUST, + RUST, INTRINSIC, C, - CDECL, + CDECL, STDCALL, FASTCALL, };
Also note that you can use a given version of clang-format by using git clang-format-10 if you have installed that particular version.
Thanks! :heart: :heart: :heart:
GCCRS Team