[PUSHED] Disable parallel testing for 'rust/compile/nr2/compile.exp' [PR119508]

..., using the standard idiom. This '*.exp' file doesn't adhere to the parallel testing protocol as defined in 'gcc/testsuite/lib/gcc-defs.exp'. This also restores proper behavior for '*.exp' files executing after (!) this one, which erroneously caused hundreds or even thousands of individual tes

Re: [COMMITTED 136/145] gccrs: Fix nightly rustc warnings

I feel like holding on on this for a few days would make the process > easier? What do you > think? Works for me; I'll keep this local until then. Grüße Thomas > On Sat, 22 Mar 2025 at 15:43, Thomas Schwinge wrote: >> >> Hi! >> >> On 2025-03-17T16:33:34+

Re: [COMMITTED 136/145] gccrs: Fix nightly rustc warnings

Hi! On 2025-03-17T16:33:34+0100, arthur.co...@embecosm.com wrote: > From: Kushal Pal > > libgrust/ChangeLog: > > * libformat_parser/Cargo.toml: > Used crate-type instead of depricated crate_type. > * libformat_parser/generic_format_parser/src/lib.rs: > Remove dead code. >

Re: Rust: error[E0554]: `#![feature]` may not be used on the stable release channel

Hi! On 2025-03-17T20:03:48+, Iain Sandoe via Gcc wrote: >> On 17 Mar 2025, at 19:43, Toon Moene wrote: >> >> I was eager to try the new rust updates ... >> >> But I got this: >> >> error[E0554]: `#![feature]` may not be used on the stable release channel >> --> src/lib.rs:19:1 >> | >>

Rust: libformat_parser: Lower minimum Rust version to 1.49 (was: Rust: Work around 'error[E0658]: `let...else` statements are unstable')

Hi! On 2024-12-05T13:37:13+0100, Arthur Cohen wrote: > On 12/4/24 13:35, Thomas Schwinge wrote: >> On 2024-11-25T11:24:08+0100, Arthur Cohen wrote: >>> [...] We had previously done something similar to >>> adapt to Rust 1.72 when we originally reused the format

Re: Rust: Work around 'error[E0658]: `let...else` statements are unstable'

g the tree buildable with old 'rustc'/'cargo'.) Grüße Thomas > On 11/23/24 9:09 PM, Thomas Schwinge wrote: >> Hi! >> >> On 2024-08-01T16:56:01+0200, Arthur Cohen wrote: >>> Compile libformat_parser and link to it. >> >>> --- /d

gccrs: Remove unused files 'gcc/rust/typecheck/rust-hir-type-check-toplevel.{cc,h}' (was: [PATCH] gccrs: Remove unused files)

mmit 104cc285533e742726ae18a7d3d4f384dd20c350 "gccrs: Refactor TypeResolution to be a simple query based system". gcc/rust/ChangeLog: * typecheck/rust-hir-type-check-toplevel.cc: Removed. * typecheck/rust-hir-type-check-toplevel.h: Removed. Signed-off-by: Owen Avery Co

Rust: Work around 'error[E0599]: no method named `leak` found for struct `std::string::String` in the current scope' (was: [PATCH 048/125] gccrs: format-args: Start storing string in Rust memory)

the current scope'"? Builds and tests fine, but I don't know if this code path is actually exercised at this time, so please check carefully; as you know I'm not actually a Rust programmer (yet). ;-) Grüße Thomas >From 8d4821dabcf4663e51c7db859801837710038821 Mon Sep 17

Re: Linking commits to PRs/MRs

Hi! On 2024-10-23T17:33:38+0100, Jonathan Wakely wrote: > On Wed, 23 Oct 2024 at 16:14, Sam James wrote: >> I think we want a way to link commits to any possible reviews or >> discussions on the forge (*). >> >> freedesktop.org projects use 'Part-of' in each commit as a trailer >> linking to the

Inline 'gcc/rust/Make-lang.in:RUST_LIBDEPS' (was: [PATCH 006/125] gccrs: Add 'gcc/rust/Make-lang.in:LIBFORMAT_PARSER')

hed to trunk branch commit aab9f33ed1f1b92444a82eb3ea5cab1048593791 "Inline 'gcc/rust/Make-lang.in:RUST_LIBDEPS'", see attached -- this commit apparently had been omitted from the 2024-08-01 upstream submission. Grüße Thomas >From aab9f33ed1f1b92444a82eb3ea5cab1048593791 M

Don't override 'LIBS' if '--enable-languages=rust'; use 'CRAB1_LIBS' (was: [PATCH 005/125] gccrs: libgrust: Add format_parser library)

f29b2b033f5b136 "Don't override 'LIBS' if '--enable-languages=rust'; use 'CRAB1_LIBS'", see attached. Grüße Thomas >From 816c4de4d062c89f5b7a68f68f29b2b033f5b136 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 5 Aug 2024 10:06:05 +0200 Su

build: Use of cargo not yet supported here in Canadian cross configurations (was: [PATCH] build: Check for cargo when building rust language)

OK to push the attached "build: Use of cargo not yet supported here in Canadian cross configurations"? Grüße Thomas >From eb38990b4147951dd21f19def43072368f782af5 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 15 Apr 2024 14:27:45 +0200 Subject: [PATCH] build: Use

Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)

or disable '--enable-languages=rust' for those. Grüße Thomas > Revision: a3281dd0f4b46c16ec1192ad411c0a96e6d086eb > Worker: bb1-1 > Build Reason: (unknown) > Blamelist: H.J. Lu , Pierre-Emmanuel Patry > , Tamar Christina > , Thomas Schwinge > > Steps: > &

build: Don't check for host-prefixed 'cargo' program (was: [PATCH] build: Check for cargo when building rust language)

k for host-prefixed 'cargo' program", see attached? Grüße Thomas >From 913be0412665d02561f8aeb999860ce8d292c61e Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 15 Apr 2024 13:33:48 +0200 Subject: [PATCH] build: Don't check for host-prefixed 'cargo'

Re: [PATCH] build: Check for cargo when building rust language

Hi! On 2024-04-08T18:33:38+0200, pierre-emmanuel.pa...@embecosm.com wrote: > The rust frontend requires cargo to build some of it's components, In GCC upstream still: 's%requires%is going to require'. ;-) > it's presence was not checked during configuration. After confirming the desired semant

Re: [gcc r14-7544] gccrs: libproc_macro: Build statically

Add 'gcc/rust/Make-lang.in:LIBPROC_MACRO_INTERNAL'" - commit e3fda76af4f342ad1ba8bd901a72d811e8357e99 "Inline 'gcc/rust/Make-lang.in:RUST_LIBDEPS' into single user" Grüße Thomas >From cb70a49b30f0a22ec7a1b7df29c3ab370d603f90 Mon Sep 17 00:00:00 2001 From: Th

Re: [PATCH] rust: Add rust.install-dvi and rust.install-html rules

Hi Christophe! On 2024-04-04T16:27:19+, Christophe Lyon wrote: > rust has the (empty) rust.dvi and rust.html rules, but lacks the > (empty) rust.install-dvi and rust.install-html ones. Thanks, looks good to me. Grüße Thomas > 2024-04-04 Christophe Lyon > > gcc/rust/ > * M

Re: ☠ Buildbot (Sourceware): gccrust - failed compile (failure) (master)

.sourceware.org/buildbot/#/builders/132/builds/1691 > > Build state: failed compile (failure) > Revision: 6895e0bb24ddc3893f917537b319ac20ba31f369 > Worker: bb1-2 > Build Reason: (unknown) > Blamelist: Arthur Cohen , Thomas Schwinge > > > Steps: > > - 0: worker_

Re: ☠ Buildbot (Sourceware): gccrust - failed compile (failure) (master)

while > building gccrust. > > Full details are available at: > https://builder.sourceware.org/buildbot/#/builders/16/builds/1917 > > Build state: failed compile (failure) > Revision: e9de5b410da43cb2ac5f9865756153648e6f078b > Worker: bb3 > Build Reason: (unkno

Re: GSoC: Application for Rust Front-End Project at GCC

e themselves there, and get started on a first small task. Grüße Thomas > On Thu, 11 Jan, 2024, 4:16 am Thomas Schwinge, wrote: > >> Hi Arpit! >> >> First, welcome to GCC, and I appreciate your enthousiasm! >> >> On 2023-12-30T22:30:37+0530, CS21B062 ARPIT

Re: [PATCHSET] Fix Rust bootstrap for future libgrust changes

Hi! On 2024-01-11T15:22:07+0100, Arthur Cohen wrote: > Sorry about this - two simple changes to Makefile.def we had missed > during our first libgrust/ patchset I don't think those were "missed" but rather "intentionally omitted"? I'll have to have a more detailed look. (..., and almost no chan

Re: GSoC: Application for Rust Front-End Project at GCC

Hi Arpit! First, welcome to GCC, and I appreciate your enthousiasm! On 2023-12-30T22:30:37+0530, CS21B062 ARPIT GUPTA wrote: > Dear GCC Community, > > I hope this email finds you well. My name is Arpit and I am writing to > express my interest in participating in GSoC, specifically for the > Rus

libgrust: 'AM_ENABLE_MULTILIB' only for target builds [PR113056] (was: [PATCH v2 2/4] libgrust: Add libproc_macro and build system)

schaft: München; Registergericht München, HRB 106955 >From 71e00b191bd630aa3be66e38069c707ae76a91d3 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 18 Dec 2023 16:27:39 +0100 Subject: [PATCH] libgrust: 'AM_ENABLE_MULTILIB' only for target builds [PR113056] ..., but not for

Re: [PATCH v2 2/4] libgrust: Add libproc_macro and build system

Hi Jason! I think you usually deal with these kind of GCC Git things? If not, please let me know. On 2023-10-26T10:21:18+0200, I wrote: > First, I've pushed into GCC upstream Git branch devel/rust/libgrust-v2 > the "v2" libgrust changes as posted by Arthur, so that people can easily > test this

Re: GCC/Rust libgrust-v2/to-submit branch

Hi Arthur, Pierre-Emmanuel! On 2023-12-12T10:39:50+0100, I wrote: > On 2023-11-27T16:46:08+0100, I wrote: >> On 2023-11-21T16:20:22+0100, Arthur Cohen wrote: >>> On 11/20/23 15:55, Thomas Schwinge wrote: >>>> Arthur and Pierre-Emmanuel have prepared a GCC/Rust lib

Re: GCC/Rust libgrust-v2/to-submit branch

Hi Arthur, Pierre-Emmanuel! On 2023-11-27T16:46:08+0100, I wrote: > On 2023-11-21T16:20:22+0100, Arthur Cohen wrote: >> On 11/20/23 15:55, Thomas Schwinge wrote: >>> Arthur and Pierre-Emmanuel have prepared a GCC/Rust libgrust-v2/to-submit >>> branch: <https://

Re: GCC/Rust libgrust-v2/to-submit branch

Hi! On 2023-11-21T16:20:22+0100, Arthur Cohen wrote: > A newer version of the library has been force-pushed to the branch > `libgrust-v2/to-submit`. > On 11/20/23 15:55, Thomas Schwinge wrote: >> Arthur and Pierre-Emmanuel have prepared a GCC/Rust libgrust-v2/to-submit &g

GCC/Rust libgrust-v2/to-submit branch (was: [PATCH 2/3] build: Add libgrust as compilation modules)

Hi! Arthur and Pierre-Emmanuel have prepared a GCC/Rust libgrust-v2/to-submit branch: . In that one, most of the issues raised have been addressed, and which I've now successfully "tested" in my different GCC configurations, requiring j

Re: [PATCH 2/3] build: Add libgrust as compilation modules

Hi! To close the loop here: On 2023-09-27T00:25:16+0200, I wrote: > On 2023-09-20T13:59:53+0200, Arthur Cohen wrote: >> From: Pierre-Emmanuel Patry >> >> Define the libgrust directory as a host compilation module as well as >> for targets. > >> --- a/Makefile.def >> +++ b/Makefile.def >> @@ -14

Disable target libgrust if we're not building target libstdc++ (was: [PATCH v2 2/4] libgrust: Add libproc_macro and build system)

Hi! Short Friday evening status update: On 2023-10-27T16:20:34+0200, I wrote: > Short Friday afternoon status update: > > On 2023-10-27T08:51:12+0100, Iain Sandoe wrote: >>> On 26 Oct 2023, at 09:21, Thomas Schwinge wrote: >>> First, I've pushed into GCC upstrea

Re: [PATCH v2 2/4] libgrust: Add libproc_macro and build system

Hi! Short Friday afternoon status update: On 2023-10-27T08:51:12+0100, Iain Sandoe wrote: >> On 26 Oct 2023, at 09:21, Thomas Schwinge wrote: >> First, I've pushed into GCC upstream Git branch devel/rust/libgrust-v2 >> the "v2" libgrust changes as posted by

Only build host libgrust if the Rust language is enabled (was: [PATCH v2 3/4] build: Add libgrust as compilation modules)

80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From 403e6bf5349f8a22e4dc7b74ea80acb55e4f5133 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 27 Oct 2023 1

Re: [PATCH v2 2/4] libgrust: Add libproc_macro and build system

Hi! First, I've pushed into GCC upstream Git branch devel/rust/libgrust-v2 the "v2" libgrust changes as posted by Arthur, so that people can easily test this before it getting into Git master branch. I'll myself later try this for GCN and nvptx targets -- in their current form where they don't su

Re: [PATCH v2 3/4] build: Add libgrust as compilation modules

Hi! On 2023-10-25T13:06:48+0200, Arthur Cohen wrote: > From: Pierre-Emmanuel Patry > > Define the libgrust directory as a host compilation module as well as > for targets. I don't see a response to Richard's comments:

Re: [PATCH] rust: build failure after NON_DEPENDENT_EXPR removal [PR111899]

Hi Patrick! On 2023-10-20T13:36:30-0400, Patrick Palka wrote: > Built on x86_64-pc-linux-gnu, pushed to trunk as obvious (hopefully). > > -- >8 -- > > This patch removes stray NON_DEPENDENT_EXPR checks following the removal > of this tree code from the C++ FE. (Since this restores the build I >

Re: [PATCH 1/3] librust: Add libproc_macro and build system

Hi! On 2023-09-26T13:40:40+0200, Richard Biener wrote: > On Wed, Sep 20, 2023 at 2:04 PM Arthur Cohen > wrote: >> >> From: Pierre-Emmanuel Patry >> >> This patch series adds the build system changes to allow the Rust >> frontend to develop and distribute its own libraries. The first library >>

Re: [PATCH 2/3] build: Add libgrust as compilation modules

Hi! On 2023-09-20T13:59:53+0200, Arthur Cohen wrote: > From: Pierre-Emmanuel Patry > > Define the libgrust directory as a host compilation module as well as > for targets. > --- a/Makefile.def > +++ b/Makefile.def > @@ -149,6 +149,7 @@ host_modules= { module= libcc1; > extra_configure_flags=--

Re: [PATCH 2/2] rust: update usage of TARGET_AIX to TARGET_AIX_OS

Hi Paul! On 2023-06-16T11:00:02-0500, "Paul E. Murphy via Gcc-patches" wrote: > This was noticed when fixing the gccgo usage of the macro, the > rust usage is very similar. > > TARGET_AIX is defined as a non-zero value on linux/powerpc64le > which may cause unexpected behavior. TARGET_AIX_OS sh

Re: Rust front-end update 2023-04-05

Hi Arthur! On 2023-04-05T16:02:43+0200, arthur.co...@embecosm.com wrote: > This patchset contains around 80 commits concerning the Rust frontend. Did you not intend to actually 'git push' those? ;-P Grüße Thomas > We have been hard at work trying to get the Rust core library to > compile, a

Re: [GSoC] gccrs Unicode support

Hi! (By the way, this GSoC project is being discussed in GCC/Rust Zulip: .) I'm now also putting Mark Wielaard in CC; he once also started discussing this topic, "thinking of importing a couple of gnulib modules to

Re: ☠ Buildbot (Sourceware): gccrust - failed 'grep unexpected ...' (failure) (master)

Hi! On 2023-03-01T15:59:32+, builder--- via Gcc-rust wrote: > A new failure has been detected on builder gccrust-debian-i386 while building > gccrust. > > Full details are available at: > https://builder.sourceware.org/buildbot/#builders/27/builds/893 I've filed

Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types (was: Modula-2 / Rust: Many targets failing)

ng; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From cae898bef63db18cc40b94ee4d48f85aec258c02 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 22 Feb 2023 11:42:43 +0100 Subject: [PATCH] Rust: In 'type

Rust: Move void_list_node init to common code (was: [PATCH] Move void_list_node init to common code)

it a/gcc/tree.cc b/gcc/tree.cc > index 0546c8f4025..4165cbd7c3b 100644 > --- a/gcc/tree.cc > +++ b/gcc/tree.cc > @@ -9414,6 +9414,8 @@ build_common_tree_nodes (bool signed_char) >void_node = make_node (VOID_CST); >TREE_TYPE (void_node) = vo

Update copyright years. (was: [committed 003/103] gccrs: dump: Emit visibility when dumping items)

: München; Registergericht München, HRB 106955 >From e28c5b33b987374f753b32306b0d3ecf610b64f2 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 21 Feb 2023 13:49:42 +0100 Subject: [PATCH] Update copyright years. ... which accidentally had gotten reverted in recent commit r13-6156-g1e8e

[PING, v2] Add '-Wno-complain-wrong-lang', and use it in 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere

Hi! On 2023-01-11T13:31:56+0100, Jakub Jelinek via Gcc-patches wrote: > On Wed, Jan 11, 2023 at 12:41:06PM +0100, Thomas Schwinge wrote: > > I think this should be reviewed by Joseph as option handling maintainer. Joseph, please? >> +@item -Wno-complain-wrong-lang >> +@op

Rust: Don't depend on unused 'target-libffi', 'target-libbacktrace' (was: [PATCH Rust front-end v2 32/37] gccrs: Add config-lang.in)

sellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From 5d85939a3e3ebcfcf3f2ac9d3f2e01cbb1736578 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 20 Feb 2023 13:01:50 +0100 Subject: [P

'#include "tm_p.h"' in 'gcc/rust/backend/rust-tree.cc' (was: [gcc r13-5533] gccrs: const folding port)

"'#include "tm_p.h"' in 'gcc/rust/backend/rust-tree.cc'", see attached. Grüße Thomas - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas H

[PING] Add '-Wno-complain-wrong-lang', and use it in 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere

Hi! Ping. Grüße Thomas On 2022-12-16T15:10:12+0100, I wrote: > Hi! > > On 2022-12-15T16:17:05+0100, Jakub Jelinek wrote: >> On Thu, Dec 15, 2022 at 04:01:33PM +0100, Thomas Schwinge wrote: >>> Or, options are applicable to just one front end, and can just be a n

Add '-Wno-complain-wrong-lang', and use it in 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere (was: Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option)

Hi! On 2022-12-15T16:17:05+0100, Jakub Jelinek wrote: > On Thu, Dec 15, 2022 at 04:01:33PM +0100, Thomas Schwinge wrote: >> Or, options are applicable to just one front end, and can just be a no-op >> for others, for shared-language compilation. For example, '-nostdi

Re: Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option (was: Rust front-end patches v4)

Hi! On 2022-12-15T12:50:44+0100, Jakub Jelinek via Gcc-patches wrote: > On Thu, Dec 15, 2022 at 12:39:38PM +0100, Iain Buclaw wrote: >> For the gdc testsuite, those warnings arise because both language files >> are compiled in the same invocation (dg-additional-sources "cpp11.cpp"), >> so it end

Re: Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option (was: Rust front-end patches v4)

Hi! On 2022-12-15T08:53:13+0100, Richard Biener wrote: > On Wed, Dec 14, 2022 at 11:58 PM Thomas Schwinge > wrote: >> On 2022-12-13T14:40:36+0100, Arthur Cohen wrote: >> > We've also added one more commit, which only affects files inside the >> > Rust fr

Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option (was: Rust front-end patches v4)

H; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From 3b2a8a4df1637a0cad738165a2afa9b34e286fcf Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: W

Re: Rust front-end patches v4

Hi Martin! On 2022-12-09T14:24:18+0100, Martin Liška wrote: > I noticed a minor git issues when I tried [applying] the patches: [...] > > Can you please take a look at that? Done via "Fix whitespace errors". I've then force-updated the staging branc

Add stub 'gcc/rust/ChangeLog' (was: Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust)

, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From 24ff0b3e0c41e3997fb4c11736b8a412afbaadf3 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 10 Dec 2022 08:33:22 +0100 Subject: [PATCH] Add stub 'gcc/rust/ChangeLog' --- gcc/rust/ChangeLog |

Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust (was: Rust front-end patches v4)

sellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From 325529e21e81fbc3561d2568cb7e8a26296e5b2f Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 10 Dec 2022 07:27:55 +0100 Subject

Re: [PATCH Rust front-end v4 20/46] gccrs: Add wrapper for make_unique

Hi! On 2022-12-07T09:50:40+0100, Arsen Arsenović via Gcc-patches wrote: > arthur.co...@embecosm.com writes: > >> This is a wrapper for make_unique. We can likely get rid of this, as there >> are other implementations available, or simply keep using the unique_ptr >> constructor. >> --- >> gcc/r

Re: [PATCH Rust front-end v2 31/37] gccrs: Add GCC Rust front-end Make-lang.in

Hi! On 2022-09-14T15:34:10+0200, Richard Biener via Gcc-patches wrote: > On Wed, Aug 24, 2022 at 2:22 PM wrote: >> --- /dev/null >> +++ b/gcc/rust/Make-lang.in >> +# TODO: possibly find a way to ensure C++11 compilation level here? >> +RUST_CXXFLAGS = -std=c++11 -Wno-unused-parameter -Werror=o

Re: [PATCH Rust front-end v3 38/46] gccrs: Add HIR to GCC GENERIC lowering entry point

Hi! On 2022-11-09T14:53:44+0100, Richard Biener via Gcc-patches wrote: > On Wed, Oct 26, 2022 at 10:37 AM wrote: >> This patch [...] also contains a constant evaluator, ported >> over from the C++ frontend. Given that, and then: >> --- /dev/null >> +++ b/gcc/rust/backend/rust-constexpr.cc >>

Re: [PATCH Rust front-end v2 34/37] gccrs: add lang.opt

Hi! On 2022-09-14T15:39:47+0200, Richard Biener via Gcc-patches wrote: > On Wed, Aug 24, 2022 at 2:13 PM wrote: >> >> From: Philip Herron >> >> We have some rust specific langugage options note -fwrapv is enabled by >> default in the code. We are trying to respect options such as >> -Wunused-r

Re: Setting up editors for the GNU/GCC coding style?

Hi! On 2022-07-29T09:36:41+0200, Marc Poulhies via Gcc wrote: > Iannetta Paul writes: >> About configuring recent editors to follow the GNU coding style, I don't >> really >> know but it should always be possible to register a hook that will run >> `indent` >> when the file is saved. > > There

Re: GCC Rust git branch

;. Grüße Thomas - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From 15e0

Document mailing list (was: GCC Rust git branch)

- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From 1c89cdccbebda5d4c2eeeb627b1461b8

Regular Online GCC/Rust Meeting Time Slot

Hi! We're trying to figure out a good regular online GCC/Rust meeting time slot. Currently we're meeting once a month. It's been a bit difficult to find a (a) free online service that (b) doesn't work just with actual dates but generic days of week and (c) does consider different timezones... I

Re: Buildbot failure in Wildebeest Builder on whole buildset

Hi Arthur! On 2022-03-02T13:05:30+0100, Arthur Cohen wrote: > On 3/2/22 11:05, Thomas Schwinge wrote: >> On 2022-03-02T10:44:38+0100, I wrote: >>> On 2022-03-02T09:03:48+, Philip Herron >>> wrote: >>>> Yet again the build bots are out doing github a

Re: Buildbot failure in Wildebeest Builder on whole buildset

mit 6cf9f8c99c5813a23d7cec473fedf00683f409e4 "Merge #983", that was "clean" (just some lost memory etc.). > I can easily test any patches that you need tested. Grüße Thomas >> On Wed, 2 Mar 2022 at 07:21, Thomas Schwinge wrote: >>> >>> Hi! >&g

Re: Buildbot failure in Wildebeest Builder on whole buildset

oing out of scope when we set it up. Ah! So, "standard C/C++ undefined behavior, memory corruption"... ;-) I can easily test any patches that you need tested. Grüße Thomas > On Wed, 2 Mar 2022 at 07:21, Thomas Schwinge wrote: >> >> Hi! >> >> On 2022-03-02

Re: Buildbot failure in Wildebeest Builder on whole buildset

Hi! On 2022-03-02T00:15:41+0100, Mark Wielaard wrote: > On Tue, Mar 01, 2022 at 07:08:15PM +, build...@builder.wildebeest.org > wrote: >> The Buildbot has detected a new failure on builder gccrust-debian-arm64 >> while building gccrust. >> Full details are available at: >> https://build

Re: Buildbot failure in Wildebeest Builder on whole buildset

Hi Mark! On 2022-01-29T21:20:45+0100, Mark Wielaard wrote: > On Tue, Jan 25, 2022 at 11:42:41PM +0100, Mark Wielaard wrote: >> I added a filesIsImportant filter to the buildbot gccrs scheduler: >> >> gccrs_files = ["gcc/rust/", "gcc/testsuite/rust/", "gcc/config/.*/*-rust.c"] Is that last one co

Re: Buildbot failure in Wildebeest Builder on whole buildset

Hi! On 2022-01-24T22:30:21+0100, Marc via Gcc-rust wrote: > Mark Wielaard writes: > >> Sorry, I don't immediately know what is happening. >> I assume some merge took place and the buildbot doesn't know what are >> good/bad commits and just tries to do builds for everything in the >> merge. I hav

Re: Merge from GCC upstream into GCC/Rust

Hi! On 2021-09-24T10:30:15+0200, I wrote: > I'm preparing a merge from GCC upstream into GCC/Rust. Pushed to master branch commit 28f527c9598339cf834a30b5ee1f14258b8ecbb2 "Merge commit '2961ac45b9e19523958757e607d11c5893d6368b' [#247]". > This is normally > pretty unexciting ;-) -- the exception

Merge from GCC upstream into GCC/Rust

Hi "Testers"! I'm preparing a merge from GCC upstream into GCC/Rust. This is normally pretty unexciting ;-) -- the exception being, as once mentioned in : | Aside from the GCC/Rust-specific files (not existing in GCC upstream),

Re: [PATCH] Fix byte char and byte string lexing code

Hi Mark! On 2021-09-22T00:54:30+0200, Mark Wielaard wrote: > There were two warnings in lexer parse_byte_char and parse_byte_string > code for arches with signed chars: > > rust-lex.cc: In member function > ‘Rust::TokenPtr Rust::Lexer::parse_byte_char(Location)’: > rust-lex.cc:1564:2

Re: [PATCH 2/2] WIP union hir-lowering and type support

Hi! On 2021-08-02T00:37:37+0200, Mark Wielaard wrote: > On Sun, Aug 01, 2021 at 01:29:16PM +0200, Mark Wielaard wrote: >> I added two simple testcases to show the basic support for unions >> works now. But there are a couple of things that don't work correctly >> for unions yet. In particular whe

Re: [PATCH] Pass pratt parsed token to expr parser functions to fix expr locus

Hi! On 2021-07-29T12:55:38+0200, Mark Wielaard wrote: > On Thu, 2021-07-29 at 09:25 +0800, The Other via Gcc-rust wrote: >> I think the core idea of this patch (fixing locations) is very >> important and useful. Agreed. >> But isn’t it overkill to pass the token in instead of just the >> locati

Re: New contributor tasks

Hi! On 2021-07-13T00:44:13+0200, Mark Wielaard wrote: > On Mon, Jul 12, 2021 at 11:06:01AM +0100, Philip Herron wrote: >> The main one that sticks out in my mind is the AST, HIR dumps which are >> a bit of a mess at the moment. > > The AST dump (--rust-dump-parse) was actually useful for checking