Rollup of 9 pull requests #131887
Merged
Rollup of 9 pull requests #131887
+287
−60
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit introduces a minimal `![no_core]`-test case running on AVR, that contains the MCWE mentioned in [129301]. The test case itself does not have any assertions yet, but it shows the minimal set an language items necessary within the test case. [129301]: rust-lang#129301 (comment)
The issue was, that the disassembled label was placed one instruction further down than expected. Therefore the test annotations check, that the label is placed above the loop-contents (writing the one value, then writing the other one).
Since the `tests/assembly` use `emit=asm`, the issue is not observable as reported in the linked issue. Therefore the existing test case is converted and a simple `rmake`-test is added. The test only checks, if the correct `rjmp`-offset is used.
The new `rmake`-content asserts the exact assembly sequence for the loop preventing false-negatives if some instructions would change and thus the label offset might need to change.
This fixes the [build error] caused by the `avr-gcc` (used as linker) not being available in the Rust CI. This is a viable solution, which shows the wrong/right behavior and, since no functions from `libgcc` are called, does not produce errors. This was discussed [here]. Another small problem is, that `lld` doesn't link the correct startup-code by default. This is not a problem for this test (since it does not actually use anything the startup code is needed for (no variables, no stack, no interrupts)), but this causes the `main`-function to be removed by the default flag `--gc-sections`. Therefore the `rmake`-driver also adds the linker flag `--entry=main` to mark the `main`-function as the entry point and thus preventing it from getting removed. The code would work on a real AVR device. [build error]: rust-lang#131755 (comment) [here]: rust-lang#131755 (comment)
After rust/rust-lang#106943 the part about `ExactSizeIterator` is no longer valid
By using qualified imports, i.e. `$crate::...::LocalKey`.
The context for this is rust-lang#130266: setting the medium code model for the 'loongarch64-linux-ohos' target.
Partially stabilize const_pin Tracking issue rust-lang#76654. Eight of these methods can be made const-stable. The remainder are blocked on rust-lang#73255.
…n-test, r=jieyouxu Regression test for AVR `rjmp` offset This adds a regression test for rust-lang#129301 by minimizing the code in the linked issue and putting it into a `#![no_core]`-compatible format, so that it can easily be used within an `rmake`-test. This needs to be a `rmake` test (opposed to a `tests/assembly` one), since the linked issue describes, that the problem only occurs if the code is directly compiled. Note, that `lld` is used instead of `avr-gcc`; see the [comments](rust-lang#131755 (comment)) [below](rust-lang#131755 (comment)). Closes rust-lang#129301. To show, that the test actually catches the wrong behavior, this can be tested with a faulty rustc: ```bash $ rustup install nightly-2024-08-19 $ rustc +nightly-2024-08-19 -C opt-level=s -C panic=abort --target avr-unknown-gnu-atmega328 -Clinker=build/x86_64-unknown-linux-gnu/ci-llvm/bin/lld -Clink-arg='--entry=main' -o compiled tests/run-make/avr-rjmp-offset/avr-rjmp-offsets.rs $ llvm-objdump -d compiled | grep '<main>' -A 6 000110b4 <main>: 110b4: 81 e0 ldi r24, 0x1 110b6: 92 e0 ldi r25, 0x2 110b8: 85 b9 out 0x5, r24 110ba: 95 b9 out 0x5, r25 110bc: fe cf rjmp .-4 ``` One can see, that the wrong label offset (`4` instead of `6`) is produced, which would trigger an assertion in the test case. This would be a good candidate for using the `minicore` proposed in rust-lang#130693. Since this is not yet merged, there is a FIXME. r? Patryk27 I think, you are the yet-to-be official target maintainer, hence I'll assign to you. `@rustbot` label +O-AVR
…joboet Add getentropy for RTEMS RTEMS provides the `getentropy` function. Use this for providing random data. This PR enables the `getentropy` function for the RTEMS operating system to get random data. It is exposed via libc (see rust-lang/libc#3975).
…=Zalathar Dont ICE when computing coverage of synthetic async closure body I'm not totally certain if this is *right*, but at least it doesn't ICE. The issue is that we end up generating two MIR bodies for each async closure, since the `FnOnce` and `Fn`/`FnMut` implementations have different borrowing behavior of their captured variables. They should ideally both contribute to the coverage, since those MIR bodies are (*to the user*) the same code and should have no behavioral differences. This PR at least suppresses the ICEs, and then I guess worst case we can fix this the right way later. r? Zalathar or re-roll Fixes rust-lang#131190
…pratt Fix predicate signatures in retain_mut docs This is my first PR here so let me know if I'm doing anything wrong. The docs for `retain_mut` in `LinkedList` and `VecDeque` say the predicate takes `&e`, but it should be `&mut e` to match the actual signature. `Vec` [has it documented](https://doc.rust-lang.org/std/vec/struct.Vec.html#method.retain_mut) correctly already.
…s-not-that-special-anymore, r=jhpratt Remove outdated documentation for `repeat_n` After rust-lang#106943, which made `Take<Repeat<I>>` implement `ExactSizeIterator`, part of documentation about difference from `repeat(x).take(n)` is no longer valid. ````@rustbot```` labels: +A-docs, +A-iterators
Avoid use imports in `thread_local_inner!` Previously, the use imports in `thread_local_inner!` can shadow user-provided types or type aliases of the names `Storage`, `EagerStorage`, `LocalStorage` and `LocalKey`. This PR fixes that by dropping the use imports and instead refer to the std-internal types via fully qualified paths. A basic test is added to ensure `thread_local!`s with static decls with type names that match the aforementioned std-internal type names can successfully compile. Fixes rust-lang#131863.
Default to the medium code model on OpenHarmony LoongArch target The context for this is rust-lang#130266: setting the medium code model for the `loongarch64-linux-ohos` target. r? ```@jieyouxu```
…isDenton checktools.sh: add link to issue for more context about disabled Miri tests Adds some context for the changes made in rust-lang#130072.
rustbot
added
A-run-make
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: acfdb8dd1f In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (1350eea): 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 (primary 6.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: 780.68s -> 782.585s (0.24%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
rjmpoffset #131755 (Regression test for AVRrjmpoffset)repeat_n#131858 (Remove outdated documentation forrepeat_n)thread_local_inner!#131866 (Avoid use imports inthread_local_inner!)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup