Re: [PATCH] gccrs: avoid printing to stderr in selftest::rust_flatten_list

[David Malcolm <dmalcolm@redhat.com>]

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