Synchronize development branch with GCC's master branch

[dkm]

This branch has a no-op merge as the last commit:

• one arm is the "current" development branch from github
• the other arm is a rebased version of the "current" master branch onto a recent GCC's master

The merge is obtained with "git merge --strategy=ours" to only keep the changes from second arm.

[powerboat9]

Wouldn't it be easier to put commits adjusting the expected warnings after the merge commit? Doesn't really matter either way, of course.

[dkm]

Wouldn't it be easier to put commits adjusting the expected warnings after the merge commit? Doesn't really matter either way, of course.

Not sure why you would want that? The goal is to have everything in one sequence between the upstream base and the merge commit. The regular sync will take the commits added after the merge by the pull request and move them between the base and the new merge.

[powerboat9]

What should the .gitignore look like? Should we have every entry from both upstream and downstream, modify our downstream to match upstream exactly, keep only some entries from upstream and downstream, or something else?

[powerboat9]

It looks like the formatting for ast/rust-macro.cc is a bit odd, probably since it doesn't contain any function definitions. Should we just remove the file?

[powerboat9]

Are some of the clang-format-off sections added to rust-attribs.cc still relevant, with the clang-format upgrade?

[powerboat9]

Also, it looks like there are some non-trivial changes to the headers included by rust-lang.cc. Idk if the changes are good/bad though, would require further investigation.

[dkm]

It looks like the formatting for ast/rust-macro.cc is a bit odd, probably since it doesn't contain any function definitions. Should we just remove the file?

I guess we could yes, good catch.

Also, it looks like there are some non-trivial changes to the headers included by rust-lang.cc. Idk if the changes are good/bad though, would require further investigation.

Erm, you've already mentioned that on the Zulip, here's my copy of the answer for completeness :)

[snip snip 8<---8<----]

.... I think it has not been discarded, but more squashed with other changes with the initial upstreaming, and we may have introduced this small change in the process:

diff --git a/gcc/rust/rust-lang.cc b/gcc/rust/rust-lang.cc
index df06026387c..f3a155dbad1 100644
--- a/gcc/rust/rust-lang.cc
+++ b/gcc/rust/rust-lang.cc
@@ -1,4 +1,4 @@
-// Copyright (C) 2020-2024 Free Software Foundation, Inc.
+// Copyright (C) 2020-2025 Free Software Foundation, Inc.
 
 // This file is part of GCC.
 
@@ -16,9 +16,8 @@
 // along with GCC; see the file COPYING3.  If not see
 // <http://www.gnu.org/licenses/>.
 
+#include "rust-system.h"
 #include "rust-diagnostics.h"
-#include "config.h"
-#include "system.h"
 #include "coretypes.h"
 #include "target.h"
 #include "tree.h"
@@ -32,7 +31,6 @@
 #include "convert.h"
 #include "langhooks.h"
 #include "langhooks-def.h"
-
 #include "selftest.h"
 #include "rust-cfg-parser.h"
 #include "rust-privacy-ctx.h"
@@ -66,7 +64,6 @@
  * e.g. HIR conversion.
  */
 
-#include "rust-system.h"
 #include "rust-session-manager.h"
 #include "rust-tree.h"

I think it's OK.

[dkm]

What should the .gitignore look like? Should we have every entry from both upstream and downstream, modify our downstream to match upstream exactly, keep only some entries from upstream and downstream, or something else?

I think it's not very important, as long as we add stuff at the end. The vscode part could be dropped as it has been added upstream.

[dkm]

The gitignore change looks like:

 # ADDITIONS from GCCRS front-end
-.vscode/*
-test.code-workspace
-
-gcc/rust/test3-tiny/*
-.clang-format.swap

vscode has been moved up (upstream change).
The others entries are very old and probably not relevant anymore. So now we only have:

# ADDITIONS from GCCRS front-end
libgrust/*/target/

which can probably be removed as I don't think we are building rust crate in the source tree anymore (cc @P-E-P ?)

[P-E-P]

vscode has been moved up (upstream change). The others entries are very old and probably not relevant anymore. So now we only have:

# ADDITIONS from GCCRS front-end
libgrust/*/target/

I agree we should remove those

which can probably be removed as I don't think we are building rust crate in the source tree anymore (cc @P-E-P ?)

Yeah we're not building it in tree anymore, libformat_parser is now built in $build/libformat_parser.