internal: Fix editorconfig glob
Had been testing Zed's editorconfig branch on r-a and noticed that something was odd with yaml files.
https://spec.editorconfig.org/#glob-expressions
> {s1,s2,s3}
> any of the strings given (separated by commas, can be nested) (But {s1} only matches {s1} literally.)
Update cargo
7 commits in 8c30ce53688e25f7e9d860b33cc914fb2957ca9a..cf53cc54bb593b5ec3dc2be4b1702f50c36d24d5
2024-10-15 16:43:16 +0000 to 2024-10-18 13:56:15 +0000
- feat: Stabilize MSRV-aware resolver config (rust-lang/cargo#14639)
- Help with `[patch.crates.io]` (rust-lang/cargo#14700)
- test: Migrate publish snapshotting to snapbox (rust-lang/cargo#14642)
- Bump to 0.85.0; update changelog (rust-lang/cargo#14695)
- Fix typo in faq.md (rust-lang/cargo#14696)
- fix(registry): `HttpRegistry` `block_until_ready` returns early when work is still pending (rust-lang/cargo#14694)
- fix(resolver): avoid cloning when iterating using RcVecIter (rust-lang/cargo#14690)
Clippy subtree update
One day late with the sync, as I was sick yesterday.
Cargo.lock update includes Clippy version bump and some deps cleanup we did in Clippy to match more versions used in the Rust repo.
r? `@Manishearth`
- Since in almost all cases, there will only be 1 UEFI shell, share the
shell handle between all functions that require it.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Rollup of 3 pull requests
Successful merges:
- #126207 (std::unix::stack_overflow::drop_handler addressing todo through libc …)
- #131864 (Never emit `vptr` for empty/auto traits)
- #131870 (compiletest: Store test collection context/state in two structs)
r? `@ghost`
`@rustbot` modify labels: rollup
Forbid cannot be overriden. When someome tries to do this anyways,
it results in a hard error. That makes sense.
Except it doesn't, because macros. Macros may reasonably use `#[deny]`
in their expansion to assert
that their expanded code follows the lint. This is doesn't work when the
output gets expanded into a `forbid()` context. This is pretty silly,
since both the macros and the code agree on the lint!
Therefore, we allow `#[deny(..)]`ing a lint that's already forbidden,
keeping the level at forbid.
compiletest: Store test collection context/state in two structs
This is another incremental cleanup that untangles some of the parameter passing during test collection, making it easier to see which pieces of context information are read-only, and making it easier to find where each field is used.
Never emit `vptr` for empty/auto traits
Emiting `vptr`s for empty/auto traits is unnecessary (#114942) and causes unsoundness in `trait_upcasting` (#131813). This PR should ensure that we never emit vtables for such traits. See the linked issues for more details.
I'm not sure if I can add tests for the vtable layout. So this PR only adds tests for the soundness hole (i.e., the segmentation fault will disappear after this PR).
Fixes#114942Fixes#131813
Cc #65991 (tracking issue for `trait_upcasting`)
r? `@WaffleLapkin` (per https://github.com/rust-lang/rust/issues/131813#issuecomment-2419969745)
Abstract the state type for futexes
In the same way that we expose `SmallAtomic` and `SmallPrimitive` to allow Windows to use a value other than an `AtomicU32` for its futex state, switch the primary futex state type from `AtomicU32` to `futex::Futex`. The `futex::Futex` type should be usable as an atomic value with underlying primitive type equal to `futex::Primitive`. (`SmallAtomic` is also renamed to `SmallFutex`).
This allows supporting the futex API on systems where the underlying kernel futex implementation requires more user state than simply an `AtomicU32`.
All in-tree futex implementations simply define {`Futex`,`Primitive`} directly as {`AtomicU32`,`u32`}.
LSP says about Position::character
> If the character value is greater than the line length it defaults back to the line length.
but from_proto::offset() doesn't implement this.
A client might for example request code actions for a whole line by sending
Position::character=99999. I don't think there is ever a reason (besides laziness) why the
client can't specify the line length instead but I guess we should not crash but follow protocol.
Technically it should be a warning, not an error but warning is not shown by default so keep
it at error I guess.
Fixes#18240
internal: fix lldb-dap unconditionally calling rustc
Fixes https://github.com/rust-lang/rust-analyzer/issues/18318. I also took the opportunity to refactor how `discoverSourceFileMap` worked—it now returns a type instead of mutating a map in place.
I tested this change using the LLDB DAP extension. I needed to set `"lldb-dap.executable-path": "/Applications/Xcode.app/Contents/Developer/usr/bin/lldb-dap"` for everything to work, however, but once I did, was able to successfully debug a test.
Clamp Position::character to line length
LSP says about Position::character
> If the character value is greater than the line length it defaults back to the line length.
but from_proto::offset() doesn't implement this.
A client might for example request code actions for a whole line by sending
Position::character=99999. I don't think there is ever a reason (besides laziness) why the
client can't specify the line length instead but I guess we should not crash but follow protocol.
Not sure how to update Cargo.lock (lib/README.md doesn't say how).
Fixes#18240
Rollup of 9 pull requests
Successful merges:
- #130136 (Partially stabilize const_pin)
- #131755 (Regression test for AVR `rjmp` offset)
- #131774 (Add getentropy for RTEMS)
- #131802 (Dont ICE when computing coverage of synthetic async closure body)
- #131809 (Fix predicate signatures in retain_mut docs)
- #131858 (Remove outdated documentation for `repeat_n`)
- #131866 (Avoid use imports in `thread_local_inner!`)
- #131874 (Default to the medium code model on OpenHarmony LoongArch target)
- #131877 (checktools.sh: add link to issue for more context about disabled Miri tests)
r? `@ghost`
`@rustbot` modify labels: rollup
Default to the medium code model on OpenHarmony LoongArch target
The context for this is #130266: setting the medium code model for the `loongarch64-linux-ohos` target.
r? ```@jieyouxu```
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#131863.
Remove outdated documentation for `repeat_n`
After #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
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.
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#131190
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 https://github.com/rust-lang/libc/pull/3975).
Regression test for AVR `rjmp` offset
This adds a regression test for #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](https://github.com/rust-lang/rust/pull/131755#issuecomment-2416469675) [below](https://github.com/rust-lang/rust/pull/131755#issuecomment-2417160045).
Closes#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 #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
