r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@bors try

⌛ Trying commit c866959 with merge 0c4a7a4...

💔 Test failed - checks-actions

This PR modifies tests/run-make/. If this PR is trying to port a Makefile
run-make test to use rmake.rs, please update the
run-make port tracking issue
so we can track our progress. You can either modify the tracking issue
directly, or you can comment on the tracking issue and link this PR.

cc @jieyouxu

Some changes occurred in src/tools/compiletest

cc @jieyouxu

Invalid UTF-8 error. Maybe this will fare better, but I have doubts.

assert_contains(String::from_utf8_lossy(&rfs::read("my_crate_name.pdb")), env_var("RUSTC"));

@rustbot ready

Please run try again, if you think this stands a shot.

Invalid UTF-8 error. Maybe this will fare better, but I have doubts.

assert_contains(String::from_utf8_lossy(&rfs::read("my_crate_name.pdb")), env_var("RUSTC"));

Shouldn't we use something like assert_invalid_utf8_contains, because AFAIK pdb debug info files don't need to be UTF-8 (and it wouldn't make sense if it did).

Yeah. PDB is a binary format so it's highly unlikely to be valid UTF-8 and doing a lossy conversion seems like a lot of unnecessary work. Basically this should read the file as bytes (fs::read) then search within it using env_var("RUSTC").as_bytes() or some helper that does that.

EDIT: I think bstr would be ideal for this and is exported from run-make-support.

Yeah we could use something like bstr::ByteSlice::find_iter.

@rustbot author

☔ The latest upstream changes (presumably #128075) made this pull request unmergeable. Please resolve the merge conflicts.

Okay, I gave the bstr implementation a try, but I am of little faith - I tried to run this locally without the .pdb extension on a Linux system and failed at the RUSTC assertion. It's possible that the pdb file on MSVC is different and that this is the whole point of the test, though.

@rustbot review

@Oneirical github still says there is a conflict in allowed_run_make_makefiles (maybe another one merged?)

@Oneirical github still says there is a conflict in allowed_run_make_makefiles (maybe another one merged?)

Yes, it was caused by #128757 which just got merged.

Edit: I rebased it, it showed some conflicts which I deleted, and force pushed, but it doesn't seem that anything is appearing in this PR webpage? Maybe it just needs time.

This is very weird, my Github branch here is different from the files changed tab in this PR.

Note the run-make/pgo-gen-lto/Makefile.

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

HIR ty lowering was modified

cc @fmease

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

There are merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.

You can start a rebase with the following commands:

$ # rebase
$ git pull --rebase https://github.com/rust-lang/rust.git master
$ git push --force-with-lease

The following commits are merge commits:

• a05f187
• 888d157
• 920cb64
• 37dfe41
• c0efd51
• 8d00669
• 355eb9c
• f739c00
• a6cacee
• 493233c

???

I'm not too sure what happened there, but it seems like everything is back the way it should, and that the ghost merge conflict is gone.

Please re-approve.

Maybe you rebased onto the local master without pulling first? In any case, looks like it worked now.

@bors r=jieyouxu

📌 Commit 7d1a97f has been approved by jieyouxu

It is now in the queue for this repository.

⌛ Testing commit 7d1a97f with merge 86e7875...

This merged already, why did it get picked up?

@bors retry

@bors r-

Bors didn't correctly mark a couple PRs as merged, isn't r-ing merge conflicts (prints the message but didn't update the queue, #128407), and doesn't seem to be picking anything new up. I'm going to do a resync to see if it sorts things.

@bors treeclosed=100

edit: resync started
edit 2: guess the resync reopens the tree. Nothing else to do here then.