| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Windows: Use WriteFile to write to a UTF-8 console
If the console code page is UTF-8 then we can simply write to it without needing to convert to UTF-16 and calling `WriteConsole`.
|
|
ptr::copy: fix docs for the overlapping case
Fixes https://github.com/rust-lang/unsafe-code-guidelines/issues/549
As discussed in that issue, it doesn't make any sense for `copy` to read a byte via `src` after it was already written via `dst`. The entire point of this method is that is copies correctly even if they overlap, and that requires always reading any given location before writing it.
Cc `@rust-lang/opsem`
|
|
|
|
|
|
|
|
Rather than always needing to exclude `cb` when running `cargo clippy`,
just disable Clippy for the included module.
|
|
[1] extends Clippy's `precedence` lint to cover `&`, `|`, and bitshifts.
Update cases that are flagged by this in the most recent nightly.
[1]: https://github.com/rust-lang/rust-clippy/pull/13743
|
|
Fix renaming symlinks on Windows
Previously we only detected mount points and not other types of links when determining reparse point behaviour.
Also added some tests to avoid this regressing again in the future.
|
|
Previously we only detected mount points and not other types of links when determining reparse point behaviour.
|
|
|
|
docs: inline `std::ffi::c_str` types to `std::ffi`
Rustdoc has no way to show that an item is stable, but only at a different path. `std::ffi::c_str::NulError` is not stable, but `std::ffi::NulError` is.
To avoid marking these types as unstable when someone just wants to follow a link from `CString`, inline them into their stable paths.
Fixes #134702
r? `@tgross35`
|
|
r=Mark-Simulacrum
unwinding: bump version to fix naked_asm on Xous
With #80608 the `unwinding` crate no longer builds. The upstream crate has been updated to build by manually adding directives to the naked_asm stream.
Bump the dependency in Rust to get this newer version. This fixes the build for Xous, and closes #134403.
|
|
Update Code Example for `Iterator::rposition`
Added an additional assertion to the example to show the behavior of `iter.next_back` after using `iter.rposition`.
|
|
Use scoped threads in `std::sync::Barrier` examples
This removes boilerplate around `Arc`s and makes the code more clear.
|
|
Fix forgetting to save statx availability on success
Looks like we forgot to save the statx state on success which means the first failure (common when checking if a file exists) will always require spending an invalid statx to confirm the failure is real.
r? `@thomcc`
|
|
Document collection `From` and `FromIterator` impls that drop duplicate keys.
This behavior is worth documenting because there are other plausible alternatives, such as panicking when a duplicate is encountered, and it reminds the programmer to consider whether they should, for example, coalesce duplicate keys first.
Followup to #89869.
|
|
Add `into_array` conversion destructors for `Box`, `Rc`, and `Arc`.
Tracking issue: #133508
This PR adds the `into_array` destructor for `alloc::boxed::Box<[T]>`, `alloc::rc::Rc<[T]>`, and `alloc::sync::Arc<[T]>`.
Note that this PR assumes the initial proposal of these functions returning `Option`. It is still an open question whether this should instead be `Result`. We can, however, easily change this in a follow-up PR with the necessary consensus.
|
|
|
|
Rustdoc has no way to show that an item is stable,
but only at a different path. `std::ffi::c_str::NulError` is
not stable, but `std::ffi::NulError` is.
To avoid marking these types as unstable when someone just
wants to follow a link from `CString`, inline them into their
stable paths.
|
|
With #80608 the `unwinding` crate no longer builds. The upstream crate
has been updated to build by manually adding directives to the naked_asm
stream.
Bump the dependency in Rust to get this newer version. This fixes the
build for Xous, and closes #134403.
Signed-off-by: Sean Cross <sean@xobs.io>
|
|
|
|
|
|
|
|
|
|
|
|
`compiler_builtins` fails to compile to amdgpu if f128 is enabled.
The reason seems to be that compiler_builtins uses libcalls in the
implementation. I’m not really familiar with what libcalls are, but the
LLVM amdgpu backend explicitly does not support them.
Error message:
```
LLVM ERROR: unsupported libcall legalization
```
|
|
|
|
|
|
|
|
chore: fix typos
Fix some typos, thank you very much.
|
|
Windows: Use FILE_ALLOCATION_INFO for truncation
We use `FILE_END_OF_FILE_INFO` here only because WINE does not support `FILE_ALLOCATION_INFO`. Instead of going with the one with broadest support, let's just use that as fallback only.
|
|
Bump `stdarch`
This bumps `stdarch` to https://github.com/rust-lang/stdarch/commit/684de0d6fef708cae08214fef9643dd9ec7296e1 to get in https://github.com/rust-lang/stdarch/pull/1677 (tracked in https://github.com/rust-lang/rust/issues/133908).
From the [commit history](https://github.com/rust-lang/stdarch/compare/e5e00aab0a8c8fa35fb7865e88fa82366f615c53...684de0d6fef708cae08214fef9643dd9ec7296e1) I deduced that there shouldn't be any changes to Rust necessary.
From past PRs I'm assuming that bumping `stdarch` like this is fine, but please let me know if this is somehow inappropriate or requires something more to be done!
try-job: arm-android
try-job: armhf-gnu
|
|
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
|
|
|
|
|
|
This removes boilerplate around `Arc`s and makes the code more clear.
|
|
But fallback to FILE_END_OF_FILE_INFO for WINE
|
|
core: fix const ptr::swap_nonoverlapping when there are pointers at odd offsets
Ensure that the pointer gets swapped correctly even if it is not stored at an aligned offset. This rules out implementations that copy things in a `usize` loop -- so our implementation needs to be adjusted to avoid such a loop when running in const context.
Part of https://github.com/rust-lang/rust/issues/133668
|
|
Fix safety docs for `dyn Any + Send {+ Sync}`
Fixes the `# Safety` docs for `dyn Any + Send`'s `downcast_{mut/ref}_unchecked` to show the direct instructions , where previously the would tell the user to find the docs on `dyn Any` themselves.
This also adds them for `downcast_{mut/ref}_unchecked` on `dyn Any + Send + Sync`
|
|
|
|
offsets in the type
|
|
Use `#[derive(Default)]` instead of manual `impl` when possible
While working on #134175 I noticed a few manual `Default` `impl`s that could be `derive`d instead. These likely predate the existence of the `#[default]` attribute for `enum`s.
|
|
This reflects the currently available set of sysctl values as of macOS 15, on 2024-12-21. Features not (yet) exposed by `is_aarch64_feature_detected` have been left in comments to document their existence for the future.
|
|
Revert stabilization of the `#[coverage(..)]` attribute
Due to a process mixup, the PR to stabilize the `#[coverage(..)]` attribute (#130766) was merged while there are still outstanding concerns. The default action in that situation is to revert, and the feature is not sufficiently urgent or uncontroversial to justify special treatment, so this PR reverts that stabilization.
---
- A key point that came up in offline discussions is that unlike most user-facing features, this one never had a proper RFC, so parts of the normal stabilization process that implicitly rely on an RFC break down in this case.
- As the implementor and de-facto owner of the feature in its current form, I would like to think that I made good choices in designing and implementing it, but I don't feel comfortable proceeding to stabilization without further scrutiny.
- There hasn't been a clear opportunity for T-compiler to weigh in or express concerns prior to stabilization.
- The stabilization PR cites a T-lang FCP that occurred in the tracking issue, but due to the messy design and implementation history (and lack of a clear RFC), it's unclear what that FCP approval actually represents in this case.
- At the very least, we should not proceed without a clear statement from T-lang or the relevant members about the team's stance on this feature, especially in light of the other concerns listed here.
- The existing user-facing documentation doesn't clearly reflect which parts of the feature are stable commitments, and which parts are subject to change. And there doesn't appear to be a clear consensus anywhere about where that line is actually drawn, or whether the chosen boundary is acceptable to the relevant teams and individuals.
- For example, the [stabilization report comment](https://github.com/rust-lang/rust/issues/84605#issuecomment-2166514660) mentions that some aspects are subject to change, but that text isn't consistent with my earlier comments, and there doesn't appear to have been any explicit discussion or approval process.
- [The current reference text](https://github.com/rust-lang/reference/blob/4dfaa4f/src/attributes/coverage-instrumentation.md) doesn't mention this distinction at all, and instead simply describes the current implementation behaviour.
- When the implementation was changed to its current form, the associated user-facing error messages were not updated, so they still refer to the attribute only being allowed on functions and closures.
- On its own, this might have been reasonable to fix-forward in the absence of other concerns, but the fact that it never came up earlier highlights the breakdown in process that has occurred here.
---
Apologies to everyone who was excited for this stabilization to land, but unfortunately it simply isn't ready yet.
|
|
|
|
r=wesleywiser"
This reverts commit 1d35638dc38dbfbf1cc2a9823135dfcf3c650169, reversing
changes made to f23a80a4c2fbca593b64e70f5970368824b4c5e9.
|
|
Rollup of 6 pull requests
Successful merges:
- #130289 (docs: Permissions.readonly() also ignores root user special permissions)
- #134583 (docs: `transmute<&mut T, &mut MaybeUninit<T>>` is unsound when exposed to safe code)
- #134611 (Align `{i686,x86_64}-win7-windows-msvc` to their parent targets)
- #134629 (compiletest: Allow using a specific debugger when running debuginfo tests)
- #134642 (Implement `PointerLike` for `isize`, `NonNull`, `Cell`, `UnsafeCell`, and `SyncUnsafeCell`.)
- #134660 (Fix spacing of markdown code block fences in compiler rustdoc)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Change the names to make them less ambiguous. Additionally add `OpITy`
for accessing the same-sized integer of an operation's float type.
|
|
The ambiguous associated types error sometimes fires in cases where it
shouldn't be ambiguous ([1]), which can make things clunky when working
with chained associated types (e.g. `Op::FTy::Int::*` does not work).
Add helper types that we can use instead of the full syntax.
There aren't too many cases in-crate now but this is relevant for some
open PRs.
[1]: https://github.com/rust-lang/rust/issues/38078
|
|
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 15 packages to latest compatible versions
Updating clap_complete v4.5.39 -> v4.5.40
Updating env_filter v0.1.2 -> v0.1.3
Updating env_logger v0.11.5 -> v0.11.6
Updating expect-test v1.5.0 -> v1.5.1
Updating foldhash v0.1.3 -> v0.1.4
Updating miniz_oxide v0.8.1 -> v0.8.2
Updating object v0.36.5 -> v0.36.7
Updating serde_json v1.0.133 -> v1.0.134
Updating thiserror v2.0.7 -> v2.0.9
Updating thiserror-impl v2.0.7 -> v2.0.9
Updating tinyvec v1.8.0 -> v1.8.1
Updating wasm-encoder v0.221.2 -> v0.222.0
Removing wasmparser v0.218.0
Removing wasmparser v0.221.2
Adding wasmparser v0.222.0
Updating wast v221.0.2 -> v222.0.0
Updating wat v1.221.2 -> v1.222.0
note: pass `--verbose` to see 35 unchanged dependencies behind latest
library dependencies:
Locking 1 package to latest compatible version
Updating object v0.36.5 -> v0.36.7
note: pass `--verbose` to see 6 unchanged dependencies behind latest
rustbook dependencies:
Locking 9 packages to latest compatible versions
Updating cc v1.2.0 -> v1.2.5
Updating clap_complete v4.5.39 -> v4.5.40
Updating env_filter v0.1.2 -> v0.1.3
Updating env_logger v0.11.5 -> v0.11.6
Updating libc v0.2.168 -> v0.2.169
Updating miniz_oxide v0.8.1 -> v0.8.2
Updating serde_json v1.0.133 -> v1.0.134
Updating thiserror v2.0.7 -> v2.0.9
Updating thiserror-impl v2.0.7 -> v2.0.9
```
|
