* [PATCH] gccrs: avoid printing to stderr in selftest::rust_flatten_list @ 2022-12-16 17:01 David Malcolm 2023-01-02 12:47 ` Arthur Cohen 0 siblings, 1 reply; 6+ messages in thread From: David Malcolm @ 2022-12-16 17:01 UTC (permalink / raw) To: gcc-patches, Arthur Cohen; +Cc: David Malcolm Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. OK for trunk? gcc/rust/ChangeLog: * resolve/rust-ast-resolve-item.cc (selftest::rust_flatten_list): Remove output to stderr. Signed-off-by: David Malcolm <dmalcolm@redhat.com> --- gcc/rust/resolve/rust-ast-resolve-item.cc | 3 --- 1 file changed, 3 deletions(-) diff --git a/gcc/rust/resolve/rust-ast-resolve-item.cc b/gcc/rust/resolve/rust-ast-resolve-item.cc index 0c38f28d530..1276e845acc 100644 --- a/gcc/rust/resolve/rust-ast-resolve-item.cc +++ b/gcc/rust/resolve/rust-ast-resolve-item.cc @@ -1202,9 +1202,6 @@ rust_flatten_list (void) auto paths = std::vector<Rust::AST::SimplePath> (); Rust::Resolver::flatten_list (list, paths); - for (auto &path : paths) - fprintf (stderr, "%s\n", path.as_string ().c_str ()); - ASSERT_TRUE (!paths.empty ()); ASSERT_EQ (paths.size (), 2); ASSERT_EQ (paths[0].get_segments ()[0].as_string (), "foo"); -- 2.26.3 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gccrs: avoid printing to stderr in selftest::rust_flatten_list 2022-12-16 17:01 [PATCH] gccrs: avoid printing to stderr in selftest::rust_flatten_list David Malcolm @ 2023-01-02 12:47 ` Arthur Cohen 2023-01-04 19:28 ` David Malcolm 0 siblings, 1 reply; 6+ messages in thread From: Arthur Cohen @ 2023-01-02 12:47 UTC (permalink / raw) To: David Malcolm, gcc-patches [-- Attachment #1.1.1: Type: text/plain, Size: 1483 bytes --] Hi David, Sorry for the delayed reply! On 12/16/22 18:01, David Malcolm wrote: > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > > OK for trunk? > > gcc/rust/ChangeLog: > * resolve/rust-ast-resolve-item.cc (selftest::rust_flatten_list): > Remove output to stderr. > > Signed-off-by: David Malcolm <dmalcolm@redhat.com> > --- > gcc/rust/resolve/rust-ast-resolve-item.cc | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/gcc/rust/resolve/rust-ast-resolve-item.cc b/gcc/rust/resolve/rust-ast-resolve-item.cc > index 0c38f28d530..1276e845acc 100644 > --- a/gcc/rust/resolve/rust-ast-resolve-item.cc > +++ b/gcc/rust/resolve/rust-ast-resolve-item.cc > @@ -1202,9 +1202,6 @@ rust_flatten_list (void) > auto paths = std::vector<Rust::AST::SimplePath> (); > Rust::Resolver::flatten_list (list, paths); > > - for (auto &path : paths) > - fprintf (stderr, "%s\n", path.as_string ().c_str ()); > - > ASSERT_TRUE (!paths.empty ()); > ASSERT_EQ (paths.size (), 2); > ASSERT_EQ (paths[0].get_segments ()[0].as_string (), "foo"); Looks good to me. OK for trunk :) Thanks for taking the time! All the best, -- Arthur Cohen <arthur.cohen@embecosm.com> Toolchain Engineer Embecosm GmbH Geschäftsführer: Jeremy Bennett Niederlassung: Nürnberg Handelsregister: HR-B 36368 www.embecosm.de Fürther Str. 27 90429 Nürnberg Tel.: 091 - 128 707 040 Fax: 091 - 128 707 077 [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 3195 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gccrs: avoid printing to stderr in selftest::rust_flatten_list 2023-01-02 12:47 ` Arthur Cohen @ 2023-01-04 19:28 ` David Malcolm 2023-01-05 14:44 ` Arthur Cohen 0 siblings, 1 reply; 6+ messages in thread From: David Malcolm @ 2023-01-04 19:28 UTC (permalink / raw) To: Arthur Cohen, gcc-patches On Mon, 2023-01-02 at 13:47 +0100, Arthur Cohen wrote: > Hi David, > > Sorry for the delayed reply! > > On 12/16/22 18:01, David Malcolm wrote: > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > > > > OK for trunk? > > > > gcc/rust/ChangeLog: > > * resolve/rust-ast-resolve-item.cc > > (selftest::rust_flatten_list): > > Remove output to stderr. For reference, the stderr spewage was: foo::bar::baz foo::bar::bul > > > > Signed-off-by: David Malcolm <dmalcolm@redhat.com> > > --- > > gcc/rust/resolve/rust-ast-resolve-item.cc | 3 --- > > 1 file changed, 3 deletions(-) > > > > diff --git a/gcc/rust/resolve/rust-ast-resolve-item.cc > > b/gcc/rust/resolve/rust-ast-resolve-item.cc > > index 0c38f28d530..1276e845acc 100644 > > --- a/gcc/rust/resolve/rust-ast-resolve-item.cc > > +++ b/gcc/rust/resolve/rust-ast-resolve-item.cc > > @@ -1202,9 +1202,6 @@ rust_flatten_list (void) > > auto paths = std::vector<Rust::AST::SimplePath> (); > > Rust::Resolver::flatten_list (list, paths); > > > > - for (auto &path : paths) > > - fprintf (stderr, "%s\n", path.as_string ().c_str ()); > > - > > ASSERT_TRUE (!paths.empty ()); > > ASSERT_EQ (paths.size (), 2); > > ASSERT_EQ (paths[0].get_segments ()[0].as_string (), "foo"); > > Looks good to me. OK for trunk :) > > Thanks for taking the time! I was about to push this and https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608645.html to trunk (after retesting against all the changes since before my break), but you mentioned today on IRC something about merger issues: <cohenarthur> ibuclaw: I'm looking at the remaining issues for updating GCC's master with our most recent gccrs commits. I've come to the conclusion that it would be easier for me to upstream your target changes while I'm upstreaming/submitting all of the missing commits <cohenarthur> would that suit you? <cohenarthur> it would just be me sending in your commits, but I wouldn't be author on them or anything of course <cohenarthur> this would enable us to time them properly within the rest of the commits, so there'd be no conflicts or anything of the sort <cohenarthur> dmalcolm: same question to you, actually :) Can I go ahead and push my two commits to trunk, or do you want to do it? (and if so, do you want them e.g. as PRs against your github branch?) Dave > > All the best, ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gccrs: avoid printing to stderr in selftest::rust_flatten_list 2023-01-04 19:28 ` David Malcolm @ 2023-01-05 14:44 ` Arthur Cohen 2023-01-05 15:36 ` David Malcolm 0 siblings, 1 reply; 6+ messages in thread From: Arthur Cohen @ 2023-01-05 14:44 UTC (permalink / raw) To: David Malcolm, gcc-patches; +Cc: Iain Buclaw [-- Attachment #1.1.1: Type: text/plain, Size: 4279 bytes --] Hi David, On 1/4/23 20:28, David Malcolm wrote: > On Mon, 2023-01-02 at 13:47 +0100, Arthur Cohen wrote: >> Hi David, >> >> Sorry for the delayed reply! >> >> On 12/16/22 18:01, David Malcolm wrote: >>> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. >>> >>> OK for trunk? >>> >>> gcc/rust/ChangeLog: >>> * resolve/rust-ast-resolve-item.cc >>> (selftest::rust_flatten_list): >>> Remove output to stderr. > > For reference, the stderr spewage was: > > foo::bar::baz > foo::bar::bul > > >>> >>> Signed-off-by: David Malcolm <dmalcolm@redhat.com> >>> --- >>> gcc/rust/resolve/rust-ast-resolve-item.cc | 3 --- >>> 1 file changed, 3 deletions(-) >>> >>> diff --git a/gcc/rust/resolve/rust-ast-resolve-item.cc >>> b/gcc/rust/resolve/rust-ast-resolve-item.cc >>> index 0c38f28d530..1276e845acc 100644 >>> --- a/gcc/rust/resolve/rust-ast-resolve-item.cc >>> +++ b/gcc/rust/resolve/rust-ast-resolve-item.cc >>> @@ -1202,9 +1202,6 @@ rust_flatten_list (void) >>> auto paths = std::vector<Rust::AST::SimplePath> (); >>> Rust::Resolver::flatten_list (list, paths); >>> >>> - for (auto &path : paths) >>> - fprintf (stderr, "%s\n", path.as_string ().c_str ()); >>> - >>> ASSERT_TRUE (!paths.empty ()); >>> ASSERT_EQ (paths.size (), 2); >>> ASSERT_EQ (paths[0].get_segments ()[0].as_string (), "foo"); >> >> Looks good to me. OK for trunk :) >> >> Thanks for taking the time! > > I was about to push this and > https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608645.html > to trunk (after retesting against all the changes since before my > break), but you mentioned today on IRC something about merger issues: > > <cohenarthur> ibuclaw: I'm looking at the remaining issues for updating > GCC's master with our most recent gccrs commits. I've come to the > conclusion that it would be easier for me to upstream your target > changes while I'm upstreaming/submitting all of the missing commits > <cohenarthur> would that suit you? > <cohenarthur> it would just be me sending in your commits, but I > wouldn't be author on them or anything of course > <cohenarthur> this would enable us to time them properly within the > rest of the commits, so there'd be no conflicts or anything of the sort > <cohenarthur> dmalcolm: same question to you, actually :) Sorry for the confusion, and for disappearing from IRC before you got a chance to answer! In those messages, I was talking about the `error_meta` PR you had submitted to us on Github. Since we are in the process of updating upstream with the current state of our dev branch, we have to figure out what to do with these commits that are already present in our dev branch but not upstreamed yet. Since you and Iain have pushed commits to our dev branch, we are wondering whether you'd like us to upstream them during this updating process or if you'd like to do so on your own. Regarding the two new patches that you've submitted here and that aren't upstreamed or merged in our dev branch yet, it's a bit different. You can either go ahead and push them to trunk if that's what you'd like, and I'm assuming that when we merge upstream and our dev branch this won't cause any conflict. And if these two patches do, they are easy enough that we can fix them by hand. If you'd like, you can also submit a PR instead, and we'll upstream them when updating the rest of the frontend upstream, similarly to your `error_meta` patches. Last option, I can also take care of them and merge them directly in our dev branch, and we'll upstream them with the rest of the frontend. This way you don't have to deal with submitting a PR and so on. > Can I go ahead and push my two commits to trunk, or do you want to do > it? (and if so, do you want them e.g. as PRs against your github > branch?) > > Dave > > >> >> All the best, > Sorry about all of this. We are working hard on updating upstream so that there's no such problems anymore. We'll get that done as soon as possible, but winter break put quite the wrench in our plans :) Thank you for your understanding! All the best, Arthur [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 3195 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gccrs: avoid printing to stderr in selftest::rust_flatten_list 2023-01-05 14:44 ` Arthur Cohen @ 2023-01-05 15:36 ` David Malcolm 2023-01-05 16:36 ` Arthur Cohen 0 siblings, 1 reply; 6+ messages in thread From: David Malcolm @ 2023-01-05 15:36 UTC (permalink / raw) To: Arthur Cohen, gcc-patches; +Cc: Iain Buclaw On Thu, 2023-01-05 at 15:44 +0100, Arthur Cohen wrote: > Hi David, > > On 1/4/23 20:28, David Malcolm wrote: > > On Mon, 2023-01-02 at 13:47 +0100, Arthur Cohen wrote: > > > Hi David, > > > > > > Sorry for the delayed reply! > > > > > > On 12/16/22 18:01, David Malcolm wrote: > > > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > > > > > > > > OK for trunk? > > > > > > > > gcc/rust/ChangeLog: > > > > * resolve/rust-ast-resolve-item.cc > > > > (selftest::rust_flatten_list): > > > > Remove output to stderr. > > > > For reference, the stderr spewage was: > > > > foo::bar::baz > > foo::bar::bul > > > > > > > > > > > Signed-off-by: David Malcolm <dmalcolm@redhat.com> > > > > --- > > > > gcc/rust/resolve/rust-ast-resolve-item.cc | 3 --- > > > > 1 file changed, 3 deletions(-) > > > > > > > > diff --git a/gcc/rust/resolve/rust-ast-resolve-item.cc > > > > b/gcc/rust/resolve/rust-ast-resolve-item.cc > > > > index 0c38f28d530..1276e845acc 100644 > > > > --- a/gcc/rust/resolve/rust-ast-resolve-item.cc > > > > +++ b/gcc/rust/resolve/rust-ast-resolve-item.cc > > > > @@ -1202,9 +1202,6 @@ rust_flatten_list (void) > > > > auto paths = std::vector<Rust::AST::SimplePath> (); > > > > Rust::Resolver::flatten_list (list, paths); > > > > > > > > - for (auto &path : paths) > > > > - fprintf (stderr, "%s\n", path.as_string ().c_str ()); > > > > - > > > > ASSERT_TRUE (!paths.empty ()); > > > > ASSERT_EQ (paths.size (), 2); > > > > ASSERT_EQ (paths[0].get_segments ()[0].as_string (), > > > > "foo"); > > > > > > Looks good to me. OK for trunk :) > > > > > > Thanks for taking the time! > > > > I was about to push this and > > > > https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608645.html > > to trunk (after retesting against all the changes since before my > > break), but you mentioned today on IRC something about merger > > issues: > > > > <cohenarthur> ibuclaw: I'm looking at the remaining issues for > > updating > > GCC's master with our most recent gccrs commits. I've come to the > > conclusion that it would be easier for me to upstream your target > > changes while I'm upstreaming/submitting all of the missing commits > > <cohenarthur> would that suit you? > > <cohenarthur> it would just be me sending in your commits, but I > > wouldn't be author on them or anything of course > > <cohenarthur> this would enable us to time them properly within the > > rest of the commits, so there'd be no conflicts or anything of the > > sort > > <cohenarthur> dmalcolm: same question to you, actually :) > > Sorry for the confusion, and for disappearing from IRC before you got > a > chance to answer! In those messages, I was talking about the > `error_meta` PR you had submitted to us on Github. Since we are in > the > process of updating upstream with the current state of our dev > branch, > we have to figure out what to do with these commits that are already > present in our dev branch but not upstreamed yet. Since you and Iain > have pushed commits to our dev branch, we are wondering whether you'd > like us to upstream them during this updating process or if you'd > like > to do so on your own. For reference, presumably this is: https://github.com/Rust-GCC/gccrs/pull/1408 which was kind of an experimenal proof-of-concept on my part. As far as I can tell, that PR added some relatively trivial new stuff to gcc/diagnostic*, and otherwise just touched the gcc/rust subdirectory, so I hope it's relatively trivial to merge. I'd prefer to leave the responsibility for merging that work into trunk to you. > > Regarding the two new patches that you've submitted here and that > aren't > upstreamed or merged in our dev branch yet, it's a bit different. You > can either go ahead and push them to trunk if that's what you'd like, > and I'm assuming that when we merge upstream and our dev branch this > won't cause any conflict. And if these two patches do, they are easy > enough that we can fix them by hand. Thanks. I've gone ahead and pushed the two simple patches to trunk as: r13-5031-gb0edfa0ef02c0f and: r13-5032-gefce0caf2d75df Dave ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gccrs: avoid printing to stderr in selftest::rust_flatten_list 2023-01-05 15:36 ` David Malcolm @ 2023-01-05 16:36 ` Arthur Cohen 0 siblings, 0 replies; 6+ messages in thread From: Arthur Cohen @ 2023-01-05 16:36 UTC (permalink / raw) To: David Malcolm, gcc-patches; +Cc: Iain Buclaw [-- Attachment #1.1.1: Type: text/plain, Size: 4421 bytes --] On 1/5/23 16:36, David Malcolm wrote: > On Thu, 2023-01-05 at 15:44 +0100, Arthur Cohen wrote: >> Hi David, >> >> On 1/4/23 20:28, David Malcolm wrote: >>> On Mon, 2023-01-02 at 13:47 +0100, Arthur Cohen wrote: >>>> Hi David, >>>> >>>> Sorry for the delayed reply! >>>> >>>> On 12/16/22 18:01, David Malcolm wrote: >>>>> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. >>>>> >>>>> OK for trunk? >>>>> >>>>> gcc/rust/ChangeLog: >>>>> * resolve/rust-ast-resolve-item.cc >>>>> (selftest::rust_flatten_list): >>>>> Remove output to stderr. >>> >>> For reference, the stderr spewage was: >>> >>> foo::bar::baz >>> foo::bar::bul >>>> >>>>> >>>>> Signed-off-by: David Malcolm <dmalcolm@redhat.com> >>>>> --- >>>>> gcc/rust/resolve/rust-ast-resolve-item.cc | 3 --- >>>>> 1 file changed, 3 deletions(-) >>>>> >>>>> diff --git a/gcc/rust/resolve/rust-ast-resolve-item.cc >>>>> b/gcc/rust/resolve/rust-ast-resolve-item.cc >>>>> index 0c38f28d530..1276e845acc 100644 >>>>> --- a/gcc/rust/resolve/rust-ast-resolve-item.cc >>>>> +++ b/gcc/rust/resolve/rust-ast-resolve-item.cc >>>>> @@ -1202,9 +1202,6 @@ rust_flatten_list (void) >>>>> auto paths = std::vector<Rust::AST::SimplePath> (); >>>>> Rust::Resolver::flatten_list (list, paths); >>>>> >>>>> - for (auto &path : paths) >>>>> - fprintf (stderr, "%s\n", path.as_string ().c_str ()); >>>>> - >>>>> ASSERT_TRUE (!paths.empty ()); >>>>> ASSERT_EQ (paths.size (), 2); >>>>> ASSERT_EQ (paths[0].get_segments ()[0].as_string (), >>>>> "foo"); >>>> >>>> Looks good to me. OK for trunk :) >>>> >>>> Thanks for taking the time! >>> >>> I was about to push this and >>> >>> https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608645.html >>> to trunk (after retesting against all the changes since before my >>> break), but you mentioned today on IRC something about merger >>> issues: >>> >>> <cohenarthur> ibuclaw: I'm looking at the remaining issues for >>> updating >>> GCC's master with our most recent gccrs commits. I've come to the >>> conclusion that it would be easier for me to upstream your target >>> changes while I'm upstreaming/submitting all of the missing commits >>> <cohenarthur> would that suit you? >>> <cohenarthur> it would just be me sending in your commits, but I >>> wouldn't be author on them or anything of course >>> <cohenarthur> this would enable us to time them properly within the >>> rest of the commits, so there'd be no conflicts or anything of the >>> sort >>> <cohenarthur> dmalcolm: same question to you, actually :) >> >> Sorry for the confusion, and for disappearing from IRC before you got >> a >> chance to answer! In those messages, I was talking about the >> `error_meta` PR you had submitted to us on Github. Since we are in >> the >> process of updating upstream with the current state of our dev >> branch, >> we have to figure out what to do with these commits that are already >> present in our dev branch but not upstreamed yet. Since you and Iain >> have pushed commits to our dev branch, we are wondering whether you'd >> like us to upstream them during this updating process or if you'd >> like >> to do so on your own. > > For reference, presumably this is: > https://github.com/Rust-GCC/gccrs/pull/1408 > which was kind of an experimenal proof-of-concept on my part. > > As far as I can tell, that PR added some relatively trivial new stuff > to gcc/diagnostic*, and otherwise just touched the gcc/rust > subdirectory, so I hope it's relatively trivial to merge. > > I'd prefer to leave the responsibility for merging that work into trunk > to you. Sounds good! > >> >> Regarding the two new patches that you've submitted here and that >> aren't >> upstreamed or merged in our dev branch yet, it's a bit different. You >> can either go ahead and push them to trunk if that's what you'd like, >> and I'm assuming that when we merge upstream and our dev branch this >> won't cause any conflict. And if these two patches do, they are easy >> enough that we can fix them by hand. > > Thanks. I've gone ahead and pushed the two simple patches to trunk as: > r13-5031-gb0edfa0ef02c0f > and: > r13-5032-gefce0caf2d75df > > Dave > Great :) Thanks a lot! Arthur [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 3195 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-01-05 16:33 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-12-16 17:01 [PATCH] gccrs: avoid printing to stderr in selftest::rust_flatten_list David Malcolm 2023-01-02 12:47 ` Arthur Cohen 2023-01-04 19:28 ` David Malcolm 2023-01-05 14:44 ` Arthur Cohen 2023-01-05 15:36 ` David Malcolm 2023-01-05 16:36 ` Arthur Cohen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).