Fix compile error in solid's remove_dir_all
Before this PR, `x check library/std --target=aarch64-kmc-solid_asp3` will fail with:
```
error[E0382]: use of partially moved value: `result`
--> std/src/sys/pal/solid/fs.rs:544:20
|
541 | if let Err(err) = result
| --- value partially moved here
...
544 | return result;
| ^^^^^^ value used here after partial move
|
= note: partial move occurs because value has type `io::error::Error`, which does not implement the `Copy` trait
help: borrow this binding in the pattern to avoid moving the value
|
541 | if let Err(ref err) = result
| +++
```
cc `@kawadakk` I think this will clear up https://solid-rs.github.io/toolstate/ :)
Clarify language around ptrs in slice::raw
More specifically we explicitly mention that the pointer should be non-null as a top level requirement. Nullptrs are always valid for zero sized operations, so just validity (and alignment) does not guarantee non-nullness as implied in the existing docs.
We also explicitly call out ZSTs as an additional example where perhaps unintuitively alignment and non-nullness still have to hold.
Finally we change `data` in the range functions to `start`, which seems like a typo to me.
Touches docs for #89792
r? RalfJung
compiler_fence documentation: emphasize synchronization, not reordering
Our `fence` docs have at some point been update to explain that they are about synchronization, not about "preventing reordering". This updates the `compiler_fence` docs n the same vein, mostly by referring to the `fence` docs.
The old docs make it sound like I can put a compiler_fence in the middle of a bunch of non-atomic operations and that would achieve any kind of guarantee. It does not, atomic operations are still required to do synchronization.
I also slightly tweaked the `fence` docs, to put the synchronization first and the "prevent reordering" second.
Cc `@rust-lang/opsem` `@chorman0773` `@m-ou-se`
Fixes https://github.com/rust-lang/rust/issues/129189
Fixes https://github.com/rust-lang/rust/issues/54962
Make decoding non-optional `LazyArray` panic if not set
Tables may be [defined](9649706ead/compiler/rustc_metadata/src/rmeta/mod.rs (L377)) as `optional:` or `defaulted:`. If optional, if we try to read a value from a key that was never encoded, we should panic. This has high value in ensuring correctness over a defaulted table, so the tradeoff is worth considering, since it signals the compiler has a buggy encode impl, rather than just defaulting to a value.
HOWEVER, `optional:` arrays were side-stepping this. So this PR fixes that, and makes `optional:` tables of `LazyArray` act like `LazyValue`, and panic if it's not assigned a value during encoding.
During this PR, I found that `deduced_param_attrs` has buggy (?? i think??) implementation where it will refuse to encode cross-crate `deduced_param_attrs` unless we're codegening, we're optimizing the library, and incremental is disabled. This seems incredibly wrong, but I don't want to fix it in this PR.
9649706ead/compiler/rustc_metadata/src/rmeta/encoder.rs (L1733-L1747)
Rollup of 9 pull requests
Successful merges:
- #127474 (doc: Make block of inline Deref methods foldable)
- #129678 (Deny imports of `rustc_type_ir::inherent` outside of type ir + new trait solver)
- #129738 (`rustc_mir_transform` cleanups)
- #129793 (add extra linebreaks so rustdoc can identify the first sentence)
- #129804 (Fixed some typos in the standard library documentation/comments)
- #129837 (Actually parse stdout json, instead of using hacky contains logic.)
- #129842 (Fix LLVM ABI NAME for riscv64imac-unknown-nuttx-elf)
- #129843 (Mark myself as on vacation for triagebot)
- #129858 (Replace walk with visit so we dont skip outermost expr kind in def collector)
Failed merges:
- #129777 (Add `unreachable_pub`, round 4)
- #129868 (Remove kobzol vacation status)
r? `@ghost`
`@rustbot` modify labels: rollup
Update cargo
9 commits in 8f40fc59fb0c8df91c97405785197f3c630304ea..c1fa840a85eca53818895901a53fae34247448b2
2024-08-21 22:37:06 +0000 to 2024-08-29 21:03:53 +0000
- fix(resolve): With `latest` message, differentiate actionable updates (rust-lang/cargo#14461)
- fix(pkgid): Allow open namespaces in PackageIdSpec's (rust-lang/cargo#14467)
- feat(resolve): Report incompatible-with-rustc when MSRV-resolver is disabled (rust-lang/cargo#14459)
- fix(resolve): Report incompatible packages with precise Rust version (rust-lang/cargo#14457)
- fix(resolve): Dont show locking workspace members (rust-lang/cargo#14445)
- Log details of failure if no errors were seen (rust-lang/cargo#14453)
- More helpful missing feature error message (rust-lang/cargo#14436)
- feat: Add matches_prerelease semantic (rust-lang/cargo#14305)
- refactor(update): Prepare for smarter update messages (rust-lang/cargo#14440)
r? ghost
Replace walk with visit so we dont skip outermost expr kind in def collector
This affects async closures with macros as their body expr. Fixes#129855.
r? ``@cjgillot`` or anyone else
Fix LLVM ABI NAME for riscv64imac-unknown-nuttx-elf
This patch fix https://github.com/rust-lang/rust/issues/129825
For the riscv64imac target, the LLVM ABI NAME should be "lp64", which is the default ABI if not specified for the riscv64imac target.
Actually parse stdout json, instead of using hacky contains logic.
Fixes up the test added in #128963, to actually parse the stdout to JSON, instead of just checking that it contains `{"`.
CC ``@GuillaumeGomez``
r? ``@jieyouxu``
add extra linebreaks so rustdoc can identify the first sentence
there should probably be a lint against this in rustdoc, it causes too many lines to be shown in the short documentation overviews
expecially noticable for the slice primative type: https://doc.rust-lang.org/std/index.html
Deny imports of `rustc_type_ir::inherent` outside of type ir + new trait solver
We shouldn't encourage using `rustc_type_ir::inherent` outside of the new solver[^1], though this can happen by accident due to rust-analyzer, for example. See https://github.com/rust-lang/rust/pull/127537#discussion_r1733813842 for an example in practice.
r? fmease
[^1]: Unless we go the fully radical approach of always using these inherent methods everywhere in favor of inherent methods, which would be a major overhaul of the compiler, IMO. I don't really want to consider that possibility right now, tho.
Apply size optimizations to panic machinery and some cold functions
* std dependencies gimli and addr2line are now built with opt-level=s
* various panic-related methods and `#[cold]` methods are now marked `#[optimize(size)]`
Panics should be cold enough that it doesn't make sense to optimize them for speed. The only tradeoff here is if someone does a lot of backtrace captures (without panics) and printing then the opt-level change might impact their perf.
Seems to be the first use of the optimize attribute. Tracking issue #54882
lcnr