-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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 6 pull requests #137989
Closed
Closed
Rollup of 6 pull requests #137989
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
raw-dylib is a link kind that allows rustc to link against a library without having any library files present. This currently only exists on Windows. rustc will take all the symbols from raw-dylib link blocks and put them in an import library, where they can then be resolved by the linker. While import libraries don't exist on ELF, it would still be convenient to have this same functionality. Not having the libraries present at build-time can be convenient for several reasons, especially cross-compilation. With raw-dylib, code linking against a library can be cross-compiled without needing to have these libraries available on the build machine. If the libc crate makes use of this, it would allow cross-compilation without having any libc available on the build machine. This is not yet possible with this implementation, at least against libc's like glibc that use symbol versioning. The raw-dylib kind could be extended with support for symbol versioning in the future. This implementation is very experimental and I have not tested it very well. I have tested it for a toy example and the lz4-sys crate, where it was able to successfully link a binary despite not having a corresponding library at build-time.
On mips64-openwrt-linux-musl target.
Support raw-dylib link kind on ELF raw-dylib is a link kind that allows rustc to link against a library without having any library files present. This currently only exists on Windows. rustc will take all the symbols from raw-dylib link blocks and put them in an import library, where they can then be resolved by the linker. While import libraries don't exist on ELF, it would still be convenient to have this same functionality. Not having the libraries present at build-time can be convenient for several reasons, especially cross-compilation. With raw-dylib, code linking against a library can be cross-compiled without needing to have these libraries available on the build machine. If the libc crate makes use of this, it would allow cross-compilation without having any libc available on the build machine. This is not yet possible with this implementation, at least against libc's like glibc that use symbol versioning. The raw-dylib kind could be extended with support for symbol versioning in the future. This implementation is very experimental and I have not tested it very well. I have tested it for a toy example and the lz4-sys crate, where it was able to successfully link a binary despite not having a corresponding library at build-time. I was inspired by Björn's comments in https://internals.rust-lang.org/t/bundle-zig-cc-in-rustup-by-default/22096/27 Tracking issue: rust-lang#135694 r? bjorn3 try-job: aarch64-apple try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: test-various
…ieyouxu Set `target_vendor = "openwrt"` on `mips64-openwrt-linux-musl` OpenWRT is a Linux distribution for embedded network devices. The target name contains `openwrt`, so we should set `cfg(target_vendor = "openwrt")`. This is similar to what other Linux distributions do (the only one in-tree is `x86_64-unikraft-linux-musl`, but that sets `target_vendor = "unikraft"`). Motivation: To make correctly [parsing target names](rust-lang/cc-rs#1413) simpler. Fixes rust-lang#131165. CC target maintainer ``@Itus-Shield``
…lt-generic, r=BoxyUwU Allow struct field default values to reference struct's generics Right now, the default field value feature (rust-lang#132162) lowers anon consts whose types may reference ADT params that the const doesn't inherit. This PR fixes this, so that these defaults can reference ADTs' generics, and sets the `generics_of` parenting up correctly. There doesn't seem to be a good reason not to support this, since the anon const has a well-defined type from the field, and the anon const doesn't interact with the type system like generic parameter defaults do. r? ```@boxyuwu``` or reassign I could also make this into an error if this seems problematic (https://github.com/rust-lang/rust/compare/master...compiler-errors:rust:default-field-value-implicit-param?expand=1)...... but I'd rather make this work and register an open question on the tracking issue about validating that this is well-vetted. Fixes rust-lang#137896
…nton Update MSVC INSTALL.md instructions to recommend VS 2022 + recent Windows 10/11 SDK This is generally iffy because we don't consistently [document the exact minimum versions of build tools required to build a given Rust toolchain](rust-lang#129307). cc rust-lang#129307, *maybe* rustup docs are outdated? Anyway, I updated this because I was on a slightly older VS toolchain and I couldn't `./x build library` on MSVC (even though maybe a month ago I could) due to CI `rustc_llvm` using stuff from newer Windows 11 SDK maybe. I updated the VS toolchain + Windows 11 SDK, and then I could build. I'm not 100% sure the requirements here are accurate. It might be too high? r? ``@ChrisDenton``
Add ``dyn`` keyword to `E0373` examples Closes rust-lang#137962
Remove unused `PpMode::needs_hir` This method was added in rust-lang#99360 to avoid an overzealous `span_delayed_bug` ICE in specific circumstances, but the only caller was subsequently removed in rust-lang#136603, which presumably avoids the problem in a more principled way.
Small rollup adding a few @bors r+ rollup=never p=5 |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 4, 2025
Rollup of 6 pull requests Successful merges: - rust-lang#135695 (Support raw-dylib link kind on ELF) - rust-lang#137836 (Set `target_vendor = "openwrt"` on `mips64-openwrt-linux-musl`) - rust-lang#137913 (Allow struct field default values to reference struct's generics) - rust-lang#137949 (Update MSVC INSTALL.md instructions to recommend VS 2022 + recent Windows 10/11 SDK) - rust-lang#137963 (Add ``dyn`` keyword to `E0373` examples) - rust-lang#137975 (Remove unused `PpMode::needs_hir`) r? `@ghost` `@rustbot` modify labels: rollup
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-compiletest
Area: The compiletest test runner
A-meta
Area: Issues & PRs about the rust-lang/rust repository itself
A-run-make
Area: port run-make Makefiles to rmake.rs
A-rustc-dev-guide
Area: rustc-dev-guide
A-testsuite
Area: The testsuite used to check the correctness of rustc
CI-spurious-fail-mingw
CI spurious failure: target env mingw
rollup
A PR which is a rollup
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
target_vendor = "openwrt"
onmips64-openwrt-linux-musl
#137836 (Settarget_vendor = "openwrt"
onmips64-openwrt-linux-musl
)dyn
keyword toE0373
examples #137963 (Adddyn
keyword toE0373
examples)PpMode::needs_hir
#137975 (Remove unusedPpMode::needs_hir
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup