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.
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.
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 :)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?) DaveAll the best,
Thank you for your understanding! All the best, Arthur
OpenPGP_0x1B3465B044AD9C65.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
