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 7 pull requests #125358

Merged
merged 36 commits into from
May 21, 2024
Merged

Rollup of 7 pull requests #125358

merged 36 commits into from
May 21, 2024

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

madsmtm and others added 30 commits May 5, 2024 22:49
- Fixed std support in top-level docs.
- Added `*-apple-darwin` docs.
- Added `i686-apple-darwin` docs.
- Moved `aarch64-apple-ios-sim` to `*-apple-ios` and document all the
  iOS targets there.
- Added `*-apple-ios-macabi` docs.
- Add myself (madsmtm) as co-maintainer of most of these targets.
If we're comfortable using `_NSGetEnviron` from `crt_externs.h`, there shouldn't be an issue with using these either, and then we can merge with the macOS implementation.

This also fixes two test cases on Mac Catalyst:
- `tests/ui/command/command-argv0.rs`, maybe because `[[NSProcessInfo processInfo] arguments]` somehow converts the name of the first argument?
- `tests/ui/env-funky-keys.rs` since we no longer link to Foundation.
And remove an unnecessary `feature(try_blocks)`.
The comment was originally in `src/librustc_mir/lib.rs`, but now that
it's in `compiler/rustc_const_eval/src/lib.rs` it's no longer
appropriate.
As is already done in several other crates, such as `rustc_errors`.
…elwoerister

Miscellaneous cleanups

A mix of small cleanups made while looking at various things.

r? `@wesleywiser`
…s, r=oli-obk

Refactor documentation for Apple targets

Refactor the documentation for Apple targets in `rustc`'s platform support page to make it clear what the supported OS version is and which environment variables are being read (`*_DEPLOYMENT_TARGET` and `SDKROOT`). This fixes rust-lang#124215.

Note that I've expanded the `aarch64-apple-ios-sim` maintainers `@badboy` and `@deg4uss3r` to include being maintainer of all `*-apple-ios-*` targets. If you do not wish to be so, please state that, then I'll explicitly note that in the docs.

Additionally, I've added myself as co-maintainer of most of these targets.

r? `@thomcc`

I think the documentation you've previously written on tvOS is great, have mostly modified it to have a more consistent formatting with the rest of the Apple target.

I recognize that there's quite a few changes here, feel free to ask about any of them!

---

CC `@simlay` `@Nilstrieb`

`@rustbot` label O-apple
…,kobzol

Add opt-for-size core lib feature flag

Adds a feature flag to the core library that enables the possibility to have smaller implementations for certain algorithms.

So far, the core lib has traded performance for binary size. This is likely what most people want since they have big simd-capable machines. However, people on small machines, like embedded devices, don't enjoy the potential speedup of the bigger algorithms, but do have to pay for them. These microcontrollers often only have 16-1024kB of flash memory.

This PR is the result of some talks with project members like `@Amanieu` at RustNL.
There are some open questions of how this is eventually stabilized, but it's a similar question as with the existing `panic_immediate_abort` feature.

Speaking as someone from the embedded side, we'd rather have this unstable for a while as opposed to not having it at all. In the meantime we can try to use it and also add additional PRs to the core lib that uses the feature flag in areas where we find benefit.

Open questions from my side:
- Is this a good feature name?
  - `panic_immediate_abort` is fairly verbose, so I went with something equally verbose
  - It's easy to refactor later
- I've added the feature to `std` and `alloc` as well as they might benefit too. Do we agree?
  - I expect these to get less usage out of the flag since most size-constraint projects don't use these libraries often.
…ieyouxu

Migrate `run-make/no-intermediate-extras` to new `rmake.rs`

Part of rust-lang#121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
…ngjubilee

Use functions from `crt_externs.h` on iOS/tvOS/watchOS/visionOS

Use `_NSGetEnviron`, `_NSGetArgc` and `_NSGetArgv` on iOS/tvOS/watchOS/visionOS, see each commit and the code comments for details. This allows us to unify more code with the macOS implementation, as well as avoiding linking to the `Foundation` framework (which is good for startup performance).

The biggest problem with doing this would be if it lead to App Store rejections. After doing a bunch of research on this, while [it did happen once in 2009](https://blog.unity.com/engine-platform/unity-app-store-submissions-problem-solved), I find it fairly unlikely to happen nowadays, especially considering that Apple has later _added_ `crt_externs.h` to the iOS/tvOS/watchOS/visionOS SDKs, strongly signifying the functions therein is indeed supported on those platforms (even though they lack an availability attribute).

That we've been overly cautious here has also been noted by `@thomcc` in rust-lang#117910 (comment).

r? `@workingjubilee`

`@rustbot` label O-apple
…, r=RalfJung,nikic

compiler: add simd_ctpop intrinsic

Fairly straightforward addition.

cc `@rust-lang/opsem` new (extremely boring) intrinsic
@rustbot rustbot added A-testsuite Area: The testsuite used to check the correctness of rustc O-macos Operating system: macOS O-unix Operating system: Unix-like S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. 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. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels May 21, 2024
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=7

@bors
Copy link
Contributor

bors commented May 21, 2024

📌 Commit e6e05d5 has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 21, 2024
@bors
Copy link
Contributor

bors commented May 21, 2024

⌛ Testing commit e6e05d5 with merge 6715446...

@bors
Copy link
Contributor

bors commented May 21, 2024

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 6715446 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 21, 2024
@bors bors merged commit 6715446 into rust-lang:master May 21, 2024
7 checks passed
@rustbot rustbot added this to the 1.80.0 milestone May 21, 2024
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#124570 Miscellaneous cleanups 5cd82b8c4fdebfdcb0e46c127d4288de5a215d71 (link)
#124772 Refactor documentation for Apple targets de11e6f68334f28592d79b1e0a74a1fdd6a7d2b1 (link)
#125011 Add opt-for-size core lib feature flag 14d3f631881680f28727da3b44b680b33ea1e677 (link)
#125218 Migrate run-make/no-intermediate-extras to new rmake.rs da44e866baa7d1ffae2e74ae258388fe66969b9c (link)
#125225 Use functions from crt_externs.h on iOS/tvOS/watchOS/visi… ebcd5581aba6df50f7adf99ec9171d26ce6bef95 (link)
#125266 compiler: add simd_ctpop intrinsic 2572ba93e68b969999311079d3047556d2939ff4 (link)
#125348 Small fixes to std::path::absolute docs bbe1e230711f43bdc2c9209f02e6ece0e5445d1f (link)

previous master: e8fbd99128

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (6715446): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.5% [-0.6%, -0.4%] 4
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary 2.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.

mean range count
Regressions ❌
(primary)
2.0% [2.0%, 2.0%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.0% [2.0%, 2.0%] 1

Cycles

Results (primary 6.3%)

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.

mean range count
Regressions ❌
(primary)
6.3% [6.3%, 6.3%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 6.3% [6.3%, 6.3%] 1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 671.391s -> 673.673s (0.34%)
Artifact size: 315.47 MiB -> 315.38 MiB (-0.03%)

@matthiaskrgr matthiaskrgr deleted the rollup-mx841tg branch September 1, 2024 17:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc merged-by-bors This PR was explicitly merged by bors. O-macos Operating system: macOS O-unix Operating system: Unix-like 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. 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. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants