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 <dmalc...@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