-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 #133788
Rollup of 6 pull requests #133788
Conversation
The deployment target environment variable is OS-specific, and if you're in a place where you're asking `rustc` for the deployment target, you're likely to also wanna know the environment variable.
…ution, r=onur-ozkan Unify `sysroot_target_{bin,lib}dir` handling Follow-up to rust-lang#131405 (comment) where `sysroot_target_bindir` had to do some dancing because the sysroot ensure logic embedded in `sysroot_target_libdir` returned `$sysroot/$relative_lib/rustlib/$target/lib` and not the `rustlib` parent `$sysroot/$relative_lib/rustlib/`. This PR pulls out the sysroot ensure logic into a helper, and return `$sysroot/$relative_lib/rustlib/` instead so `sysroot_target_bindir` doesn't have to do parent traversal from the path returned from `sysroot_target_libdir`, and also make them easier to follow in that they are now clearly closely related based on the common target sysroot ensure logic.
…v-var, r=davidtwco Print name of env var in `--print=deployment-target` The deployment target environment variable is OS-specific, and if you're in a place where you're asking `rustc` for the deployment target, you're likely to also wanna know the name of the environment variable. I myself wanted this for some code I'm working on in bootstrap, for example. Behaviour before this PR: ```console $ rustc --print=deployment-target --target=aarch64-apple-darwin deployment_target=11.0 $ rustc --print=deployment-target --target=aarch64-apple-visionos deployment_target=1.0 ``` Behaviour after this PR: ```console $ rustc --print=deployment-target --target=aarch64-apple-darwin MACOSX_DEPLOYMENT_TARGET=11.0 $ rustc --print=deployment-target --target=aarch64-apple-visionos XROS_DEPLOYMENT_TARGET=1.0 ``` My _belief_ is that this option is extremely rarely used in general, and a GitHub search for "rustc print deployment-target" seems to confirm this, it revealed only the following actual pieces of code using this: - https://github.com/PyO3/maturin/blob/b292ef69349f2a56cb8ab1b59fda0be3d3b9f138/src/build_context.rs#L1199-L1220 - https://github.com/rust-lang/cc-rs/blob/daab9244b03e244c4f2511944870d719c443f61f/src/lib.rs#L3422-L3426 `maturin` does `.split('=').last()`, so it will continue to work after this change, but `cc v1.0.84` did `.strip_prefix("deployment_target=")` since [this PR](rust-lang/cc-rs#848), so it would break. That's _probably_ fine though, it was broken in a lot of scenarios anyway, and [got](rust-lang/cc-rs#901) [reverted](rust-lang/cc-rs#943) in `v1.0.85`. So while this is _technically_ a breaking change, I really doubt that anyone is going to observe it, so it's probably fine. ``@BlackHoleFox`` wdyt? ``@rustbot`` label O-apple r? compiler
…,fee1-dead Reimplement `~const` trait specialization Reimplement const specialization. We need this for `PartialEq` constification :) r? lcnr
…workingjubilee Add simd_relaxed_fma intrinsic Adds compiler support for rust-lang/portable-simd#387 (comment) r? `@workingjubilee` cc `@RalfJung` is this kind of nondeterminism a problem for miri/opsem?
Deeply normalize when computing implied outlives bounds r? lcnr Unfortunately resolving regions is still slightly scuffed (though in an unrelated way). Specifically, we should be normalizing our param-env outlives when constructing the `OutlivesEnv`; otherwise, these assumptions (https://github.com/rust-lang/rust/blob/dd2837ec5de4301a692e05a7c4475e980af57a57/compiler/rustc_infer/src/infer/outlives/env.rs#L78) are not constructed correctly. Let me know if you want us to track that somewhere.
Add const evaluation error UI test. This closes rust-lang#78834
@bors r+ rollup=never p=6 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: efdd9e8020 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (ae3703c): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -2.0%, secondary 4.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 767.333s -> 767.254s (-0.01%) |
Successful merges:
sysroot_target_{bin,lib}dir
handling #132723 (Unifysysroot_target_{bin,lib}dir
handling)--print=deployment-target
#133041 (Print name of env var in--print=deployment-target
)~const
trait specialization #133325 (Reimplement~const
trait specialization)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup