move personality to sys

[devsnek]

this moves personality to sys, removing another PAL exception

[rustbot]

r? @Mark-Simulacrum

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[workingjubilee]

So the only problem here is that this now results in a bunch of cfg being done separately in the "platform" file and also this personality file. I am half-inclined to say we should approve this anyway, since that was a preexisting condition and it really helps to have "move these files" as a separate commit in git.

However, I would still prefer a followup commit that restructures the personality code so that at least the cfg selection of which personality implementation is inside the "platform file". You don't have to do anything on top of that, just thinning out the cfgoo from personality/mod.rs

[bors]

☔ The latest upstream changes (presumably #108934) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[Mark-Simulacrum]

r? workingjubilee

[bors]

☔ The latest upstream changes (presumably #109346) made this pull request unmergeable. Please resolve the merge conflicts.

[ChrisDenton]

@devsnek You need to rebase on master rather than having a merge commit. Also would you mind adding a commit that addresses @workingjubilee's concerns, specifically:

I would still prefer a followup commit that restructures the personality code so that at least the cfg selection of which personality implementation is inside the "platform file". You don't have to do anything on top of that, just thinning out the cfgoo from personality/mod.rs

Feel free to ask for clarification if needed.

[bors]

☔ The latest upstream changes (presumably #110214) made this pull request unmergeable. Please resolve the merge conflicts.

[devsnek]

@workingjubilee i'm not entirely sure what code you want moved where.

[workingjubilee]

Hm, I'm not entirely sure I can do a good job explaining it, but it's mostly about how ideally, the "top level" cfg for sys... the one in library/std/src/sys/mod.rs... is the thing that picks which implementation of things to use and for the rest it's hypothetically "small" differences (but we've both seen inside library/std/src/sys/unix/ so we both know that's a damn lie... but it's nice when it's truer).

If you still feel uncertain about what I mean then just rebase this and I'll approve it and figure out the followup on my own time, I have an idea for how things should be restructured in sys in general based on some recent forays.

[workingjubilee]

I took care of the rebase.
@bors r+ rollup

[bors]

📌 Commit 90e11a2 has been approved by workingjubilee

It is now in the queue for this repository.

[bors]

⌛ Testing commit 90e11a2 with merge 743333f...

[bors]

☀️ Test successful - checks-actions
Approved by: workingjubilee
Pushing 743333f to master...

[bors]

☀️ Test successful - checks-actions
Approved by: workingjubilee
Pushing 743333f to master...

[rust-timer]

Finished benchmarking commit (743333f): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results

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)	1.8%	[1.8%, 1.8%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.9%	[-2.9%, -2.9%]	1
Improvements ✅ (secondary)	-4.4%	[-4.4%, -4.4%]	1
All ❌✅ (primary)	-0.6%	[-2.9%, 1.8%]	2

Cycles

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

Binary size

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

Bootstrap: 658.446s -> 656.93s (-0.23%)