promote debug_assert to assert when possible and useful

[vincenzopalazzo]

This PR fixed a very old issue #94705 to clarify and improve the POSIX error checking, and some of the checks are skipped because can have no benefit, but I'm sure that this can open some interesting discussion.

Fixes #94705

cc: @tavianator
cc: @cuviper

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive 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

[Mark-Simulacrum]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 9c5fc6726f5744deafd45eb4dda5b1ab52cfa8bd with merge f5809960996c3d9abb4b32698a720c41a619be38...

[bors]

☀️ Try build successful - checks-actions
Build commit: f5809960996c3d9abb4b32698a720c41a619be38 (f5809960996c3d9abb4b32698a720c41a619be38)

[rust-timer]

Queued f5809960996c3d9abb4b32698a720c41a619be38 with parent 93ffde6, future comparison URL.

[rust-timer]

Finished benchmarking commit (f5809960996c3d9abb4b32698a720c41a619be38): comparison url.

Instruction count

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

Max RSS (memory usage)

Results

• Primary benchmarks: mixed results
• Secondary benchmarks: 😿 relevant regressions found

	mean1	max	count2
Regressions 😿 (primary)	1.4%	1.4%	1
Regressions 😿 (secondary)	2.8%	3.3%	5
Improvements 🎉 (primary)	-4.0%	-4.0%	1
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	-1.3%	-4.0%	2

Cycles

Results

• Primary benchmarks: mixed results
• Secondary benchmarks: 🎉 relevant improvement found

	mean1	max	count2
Regressions 😿 (primary)	2.7%	2.7%	1
Regressions 😿 (secondary)	N/A	N/A	0
Improvements 🎉 (primary)	-2.2%	-2.2%	1
Improvements 🎉 (secondary)	-3.2%	-3.2%	1
All 😿🎉 (primary)	0.2%	2.7%	2

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf -perf-regression

Footnotes

1. the arithmetic mean of the percent change ↩ ↩²

2. number of relevant changes ↩ ↩²

[Mark-Simulacrum]

r? @Amanieu for the interaction with panic-in-Drop = abort -- there's a few asserts here that are in Drop impls.

[Amanieu]

I would prefer keeping these as debug_assert: POSIX says that these functions cannot fail, so these asserts would only trigger if we made a mistake in the call arguments (EBADF, EFAULT) or the system is fundamentally broken (in which case it is outside the scope of Rust's safety anyways).

Since these asserts will never fire in practice, panic-in-drop is irrelevant here.

[bors]

⌛ Testing commit 6231d17513119ffbb2d7c4724b2fa28311e32fc5 with merge 548063328dc5e6d2435446a46dd13d7e85666777...

[bors]

💔 Test failed - checks-actions

[vincenzopalazzo]

@rustbot label -S-waiting-on-author +S-waiting-on-review

[Amanieu]

@bors r+

[bors]

📌 Commit d91dff3 has been approved by Amanieu

It is now in the queue for this repository.

[bors]

⌛ Testing commit d91dff3 with merge 569788e...

[bors]

☀️ Test successful - checks-actions
Approved by: Amanieu
Pushing 569788e to master...

[RalfJung]

POSIX says that these functions cannot fail

That's the thing, just because POSIX doesn't list an error doesn't mean the function cannot raise the error -- error lists are not exhaustive. See #94705.

[vincenzopalazzo]

I agree with you @RalfJung I do not care if the docs tell us that this will not fail at all, a sanity check is always good.

However the majority of the review point in the way to do not add this promotion assert! I'm open to discuss it, but I think before reopen the issue we need to converge on trusting the POSIX docs or not otherwise work on this simple change will be super confusing because i like a ping pong game you add and revert the change!

[rust-timer]

Finished benchmarking commit (569788e): comparison url.

Instruction count

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

Max RSS (memory usage)

Results

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: mixed results

	mean1	max	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.4%	3.4%	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.1%	-4.1%	1
All ❌✅ (primary)	-	-	0

Cycles

Results

• Primary benchmarks: ❌ relevant regression found
• Secondary benchmarks: no relevant changes found

	mean1	max	count2
Regressions ❌ (primary)	4.4%	4.4%	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	4.4%	4.4%	1

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Footnotes

1. the arithmetic mean of the percent change ↩ ↩²

2. number of relevant changes ↩ ↩²

[RalfJung]

The issue should remain open until we decided for good one way or the other, but I agree that things should be discussed on the issue before another PR is opened.

[vincenzopalazzo]

The issue should remain open until we decided for good one way or the other, but I agree that things should be discussed on the issue before another PR is opened.

Maybe it is good to create a zulip thread for this