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