-
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 8 pull requests #130269
Rollup of 8 pull requests #130269
Conversation
The minimum that `rustc` encoded did not match the version in Clang, and that meant that that when linking, we ended up bumping the version. Specifically, this sets the correct deployment target of the following simulator and Mac Catalyst targets: - `aarch64-apple-ios-sim` from 10.0 to 14.0 - `aarch64-apple-tvos-sim` from 10.0 to 14.0 - `aarch64-apple-watchos-sim` from 5.0 to 7.0 - `aarch64-apple-ios-macabi` from 13.1 to 14.0 I have chosen to not document the simulator target versions in the platform support docs, as it is fundamentally uninteresting; the normal targets (e.g. `aarch64-apple-ios`, `aarch64-apple-tvos`) still have the same deployment target as before, and that's what developers should actually target.
pointer -> reference
Mention that some methods do not sanitize their input fully
…ingjubilee Expand documentation of PathBuf, discussing lack of sanitization Various methods in `PathBuf`, in particular `set_file_name` and `set_extension` accept strings which include path seperators (like `../../etc`). These methods just glue together strings, so you can end up with strange strings. This isn't reasonable to change/fix at this point, and might not even be fixable, but I think should be documented. In particular, you probably shouldn't blindly build paths using strings given by possibly malicious users.
…nt-targets, r=jieyouxu Fix default/minimum deployment target for Aarch64 simulator targets The minimum that `rustc` encoded did not match [the version in Clang](https://github.com/llvm/llvm-project/blob/llvmorg-18.1.8/llvm/lib/TargetParser/Triple.cpp#L1900-L1932), and that meant that that when linking, Clang ended up bumping the version. See rust-lang#129432 for more motivation behind this change. Specifically, this PR sets the correct deployment target of the following targets: - `aarch64-apple-ios-sim` from 10.0 to 14.0 - `aarch64-apple-tvos-sim` from 10.0 to 14.0 - `aarch64-apple-watchos-sim` from 5.0 to 7.0 - `aarch64-apple-ios-macabi` from 13.1 to 14.0 I have chosen not to document the `-sim` changes in the platform support docs, as it is fundamentally uninteresting; the normal targets (e.g. `aarch64-apple-ios`) still have the same deployment target, and that's what developers should actually target. r? compiler CC `@BlackHoleFox`
Add test for S_OBJNAME & update test for LF_BUILDINFO cl and cmd Update the unit test for checking cl and cmd in LF_BUILDINFO. With llvm-pdbutil we can now more specifically check if the string appears at the right location instead of just checking whether the string exists at all. Context: rust-lang#96475
…, r=Amanieu Fix `slice::first_mut` docs Changes `pointer` to `reference` since that's the actual type it returns. `slice::last_mut` does correctly say "reference"
…elwoerister Simplify some nested `if` statements Applies some but not all instances of `clippy::collapsible_if`. Some ended up looking worse afterwards, though, so I left those out. Also applies instances of `clippy::collapsible_else_if` Review with whitespace disabled please.
…, r=jieyouxu Fix `clippy::useless_conversion` Self-explanatory. Probably the last clippy change I'll actually put up since this is the only other one I've actually seen in the wild.
…ukang Properly report error on `const gen fn` Fixes rust-lang#130232 Also removes some (what I thought were unused) functions, and fixes a bug in clippy where we considered `gen fn` to be the same as `fn` because it was only built to consider asyncness.
Re-run coverage tests if `coverage-dump` was modified If the `coverage-dump` tool was modified, coverage tests should not be treated as up-to-date, because the tool's output might have changed. Bootstrap already handles rebuilding the tool itself if its sources were changed, so all compiletest needs to do here is include the binary in the list of files whose timestamps are checked. This should have no effect on non-coverage tests, because bootstrap won't pass the `--coverage-dump-path` flag, so the path in compiletest's config will be None.
@bors r+ rollup=never p=8 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: f753bc769b In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (394c406): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (secondary 1.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: 759.185s -> 758.82s (-0.05%) |
Successful merges:
slice::first_mut
docs #130160 (Fixslice::first_mut
docs)if
statements #130235 (Simplify some nestedif
statements)clippy::useless_conversion
#130250 (Fixclippy::useless_conversion
)const gen fn
#130252 (Properly report error onconst gen fn
)coverage-dump
was modified #130256 (Re-run coverage tests ifcoverage-dump
was modified)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup