Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 3 pull requests #75654

Merged
merged 6 commits into from
Aug 18, 2020
Merged

Rollup of 3 pull requests #75654

merged 6 commits into from
Aug 18, 2020

Conversation

tmandry
Copy link
Member

@tmandry tmandry commented Aug 18, 2020

Successful merges:

Failed merges:

r? @ghost

mati865 and others added 6 commits August 16, 2020 21:56
Make sure to test for file types against the non-canonicalized name
to avoid detecting the wrong type.  Some systems save build artifacts
into associative file stores that do not preserve extensions, and
then link to those using conventionally-named symbolic links that
are the arguments to `rustc` et al.  If we canonicalize before
testing the type, we resolve the symlink, the extension is lost and
we might treat rlibs and rmetas as dylibs.

The fix is to introduce a temporary to hold the canonicalized name,
compare against the non-canonical name, and add a comment
explaining what's going on for the would-be maintainer who sees a
potential cleanup.

Signed-off-by: Dan Cross <dcross@google.com>
librustc_metadata::locator: Properly detect file type.

Make sure to test file types against the non-canonicalized name to
avoid detecting the wrong type.  Some systems save build artifacts
into associate file stores that do not preserve extensions, and
then link to those using conventionally-named symbolic links, that
are the arguments to `rustc` et al.  If we canonicalize before
testing the type, we resolve the symlink, the extension is
lost and we might treat rlibs and rmetas as dylibs.

The fix is to tntroduce a temporary to hold the canonicalized name,
compare against the non-canonical name, and add a comment
explaining what's going on for the would-be mainter who sees a
potential cleanup.

Signed-off-by: Dan Cross <dcross@google.com>
…oli-obk

Use more compatible out-implib style

When calling `rust-lld` directly it accepts only `--out-implib {}` or `--out-implib={}` not `--out-implib,{}`.
…crum

update stacker to 0.1.11 to unbreak build for wasm32-unknown-unknown

Like rust-lang#72079, this updates stacker. The related problem is stacker is here rust-lang/stacker#42. It was fixed by switching from `libc::c_void` to `std::ffi::c_void` https://github.com/rust-lang/stacker/pull/43/files.
@tmandry
Copy link
Member Author

tmandry commented Aug 18, 2020

@bors r+ p=3 rollup=never
@rustbot modify labels: +rollup

@bors
Copy link
Contributor

bors commented Aug 18, 2020

📌 Commit 14c0e4c has been approved by tmandry

@rustbot rustbot added the rollup A PR which is a rollup label Aug 18, 2020
@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Aug 18, 2020
@bors
Copy link
Contributor

bors commented Aug 18, 2020

⌛ Testing commit 14c0e4c with merge b97e9b5...

@bors
Copy link
Contributor

bors commented Aug 18, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: tmandry
Pushing b97e9b5 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 18, 2020
@bors bors merged commit b97e9b5 into rust-lang:master Aug 18, 2020
@tmandry tmandry deleted the rollup-ej0oezi branch August 18, 2020 17:34
@cuviper cuviper added this to the 1.47.0 milestone May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants