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 6 pull requests #129370

Merged
merged 12 commits into from
Aug 21, 2024
Merged

Rollup of 6 pull requests #129370

merged 12 commits into from
Aug 21, 2024

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

RalfJung and others added 12 commits August 6, 2024 11:17
The neutral element used to be positive zero, but +0 + -0 = +0 so
-0 seems better indicated.
No functional changes intended.

Adapts llvm-wrapper for the LLVM commits llvm/llvm-project@0f22d47 and llvm/llvm-project@d6d8243.
Changes `.unwrap()`s to `?` to avoid ICEs. Adds ui tests.

Fixes rust-lang#129327
…ncompat, r=lcnr

bump conflicting_repr_hints lint to be shown in dependencies

This has been a future compatibility lint for years, let's bump it up to be shown in dependencies (so that hopefully we can then make it a hard error fairly soon).

Cc rust-lang#68585
Fix `thread::sleep` Duration-handling for ESP-IDF

Addresses the ESP-IDF specific aspect of rust-lang#129212

#### A short summary of the problems addressed by this PR:
================================================

1. **Problem 1** - the current implementation of `std::thread::sleep` does not properly round up the passed `Duration`

As per the documentation of `std::thread::sleep`, the implementation should sleep _at least_ for the provided duration, but not less. Since the minimum supported resolution of the `usleep` syscall which is used with ESP-IDF is one microsecond, this means that we need to round-up any sub-microsecond nanos to one microsecond. Moreover, in the edge case where the user had passed a duration of < 1000 nanos (i.e. less than one microsecond), the current implementation will _not_ sleep _at all_.

This is addressed by this PR.

2. **Problem 2** - the implementation of `usleep` on the ESP-IDF can overflow if the passed number of microseconds is >= `u32::MAX - 1_000_000`

This is also addressed by this PR.

Extra details for Problem 2:

`u32::MAX - 1_000_000` is chosen to accommodate for the longest possible systick on the ESP IDF which is 1000ms.

The systick duration is selected when compiling the ESP IDF FreeRTOS task scheduler itself, so we can't know it from within `STD`. The default systick duration is 10ms, and might be lowered down to 1ms. (Making it longer I have never seen, but in theory it can go up to a 1000ms max, even if obviously a one second systick is unrealistic - but we are paranoid in the PR.)

While the overflow is reported upstream in the ESP IDF repo[^1], I still believe we should workaround it in the Rust wrappers as well, because it might take time until it is fixed, and they might not fix it for all released ESP IDF versions.

For big durations, rather than calling `usleep` repeatedly on the ESP-IDF in chunks of `u32::MAX - 1_000_000`us, it might make sense to call instead with 1_000_000us (one second) as this is the max period that seems to be agreed upon as a safe max period in the `usleep` POSIX spec. On the other hand, that might introduce less precision (as we need to call more times `usleep` in a loop) and, we would be fighting a theoretical problem only, as I have big doubts the ESP IDF will stop supporting durations higher than 1_000_000us - ever - because of backwards compatibility with code which already calls `usleep` on the ESP IDF with bigger durations.

[^1]: espressif/esp-idf#14390
Change neutral element of <fNN as iter::Sum> to neg_zero

The neutral element used to be positive zero, but +0 + -0 = +0 so -0 seems better indicated.
llvm-wrapper: adapt for LLVM 20 API changes

No functional changes intended.

Adapts llvm-wrapper for the LLVM commits llvm/llvm-project@0f22d47 and llvm/llvm-project@d6d8243.

`@rustbot` label: +llvm-main
r? `@nikic`
Force `LC_ALL=C` for all run-make tests

This PR adds `LC_ALL=C` for all run-make tests so that they become locale independent.

Fixes rust-lang#129362
r? `@jieyouxu`
…ompiler-errors

safe transmute: gracefully bubble-up layout errors

Changes `.unwrap()`s to `?` to avoid ICEs. Adds ui tests.

Fixes rust-lang#129327

Tracking Issue: rust-lang#99571

r​? `@compiler-errors`
@rustbot rustbot added A-run-make Area: port run-make Makefiles to rmake.rs O-unix Operating system: Unix-like S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler 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 Aug 21, 2024
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=6

@bors
Copy link
Contributor

bors commented Aug 21, 2024

📌 Commit 00e109f 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 Aug 21, 2024
@bors
Copy link
Contributor

bors commented Aug 21, 2024

⌛ Testing commit 00e109f with merge a32d4a0...

@bors
Copy link
Contributor

bors commented Aug 21, 2024

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

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

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#128727 bump conflicting_repr_hints lint to be shown in dependencies 0db61a8a44ddcc4ddf910d1997405ceb1a7aadcd (link)
#129232 Fix thread::sleep Duration-handling for ESP-IDF 0e8b8c4bb19c179e96bb185f36b84075717c2d60 (link)
#129321 Change neutral element of to neg_zero 1cf4ed745bd8cb3f4055fc564b11f265645d7590 (link)
#129353 llvm-wrapper: adapt for LLVM 20 API changes fbb499d53ee0a79c04b91582e07618e970058e49 (link)
#129363 Force LC_ALL=C for all run-make tests 84c20be9b61003c6ce405a6971daa928861ef9c7 (link)
#129364 safe transmute: gracefully bubble-up layout errors dff62fcb08255dde0c6ad32c67c9c1d384adc8e0 (link)

previous master: 6b678c57b6

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 (a32d4a0): 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)
-1.2% [-1.6%, -0.7%] 2
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary 5.2%, secondary -2.7%)

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)
5.2% [5.2%, 5.2%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.7% [-2.7%, -2.7%] 1
All ❌✅ (primary) 5.2% [5.2%, 5.2%] 1

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: 749.513s -> 750.761s (0.17%)
Artifact size: 338.91 MiB -> 338.92 MiB (0.00%)

@matthiaskrgr matthiaskrgr deleted the rollup-g9117ee 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-run-make Area: port run-make Makefiles to rmake.rs merged-by-bors This PR was explicitly merged by bors. 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-compiler Relevant to the compiler 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