Commit Graph

7167 Commits

Author SHA1 Message Date
Martin Pool
93e9f5e966 Document Linux kernel handoff in std::io::copy and std::fs::copy 2022-03-24 21:44:39 -07:00
bors
9280445570 Auto merge of #94901 - fee1-dead:destructable, r=oli-obk
Rename `~const Drop` to `~const Destruct`

r? `@oli-obk`

Completely switching to `~const Destructible` would be rather complicated, so it seems best to add it for now and wait for it to be backported to beta in the next release.

The rationale is to prevent complications such as #92149 and #94803 by introducing an entirely new trait. And `~const Destructible` reads a bit better than `~const Drop`. Name Bikesheddable.
2022-03-23 14:04:38 +00:00
bors
c99b42cf14 Auto merge of #95235 - asquared31415:ptr_eq_typo, r=Dylan-DPC
Fix `core::ptr::guaranteed_eq` and `guaranteed_ne` docs typo
2022-03-23 11:21:04 +00:00
asquared31415
0b81628aba ptr::guaranteed_eq doc typo 2022-03-23 04:51:59 -04:00
bors
36748cf814 Auto merge of #95173 - m-ou-se:sys-locks-module, r=dtolnay
Move std::sys::{mutex, condvar, rwlock} to std::sys::locks.

This cleans up the the std::sys modules a bit by putting the locks in a single module called `locks` rather than spread over the three modules `mutex`, `condvar`, and `rwlock`. This makes it easier to organise lock implementations, which helps with https://github.com/rust-lang/rust/issues/93740.
2022-03-23 06:01:48 +00:00
bors
7b0bf9efc9 Auto merge of #95223 - Dylan-DPC:rollup-idpb7ka, r=Dylan-DPC
Rollup of 6 pull requests

Successful merges:

 - #91608 (Fold aarch64 feature +fp into +neon)
 - #92955 (add perf side effect docs to `Iterator::cloned()`)
 - #94713 (Add u16::is_utf16_surrogate)
 - #95212 (Replace `this.clone()` with `this.create_snapshot_for_diagnostic()`)
 - #95219 (Modernize `alloc-no-oom-handling` test)
 - #95222 (interpret/validity: improve clarity)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2022-03-23 03:31:20 +00:00
Dylan DPC
25acd9331e
Rollup merge of #94713 - clarfonthey:is_char_surrogate, r=scottmcm
Add u16::is_utf16_surrogate

Right now, there are methods in the standard library for encoding and decoding UTF-16, but at least for the moment, there aren't any methods specifically for `u16` to help work with UTF-16 data. Since the full logic already exists, this wouldn't really add any code, just expose what's already there.

This method in particular is useful for working with the data returned by Windows `OsStrExt::encode_wide`. Initially, I was planning to also offer a `TryFrom<u16> for char`, but decided against it for now. There is plenty of code in rustc that could be rewritten to use this method, but I only checked within the standard library to replace them.

I think that offering more UTF-16-related methods to u16 would be useful, but I think this one is a good start. For example, one useful method might be `u16::is_pattern_whitespace`, which would check if something is the Unicode `Pattern_Whitespace` category. We can get away with this because all of the `Pattern_Whitespace` characters are in the basic multilingual plane, and hence we don't need to check for surrogates.
2022-03-23 03:05:31 +01:00
Dylan DPC
0e86cabdce
Rollup merge of #92955 - llogiq:cloned-side-effect-doc, r=yaahc
add perf side effect docs to `Iterator::cloned()`

Now that #90209 has been closed, as the current state of affairs is neither here nor there, this at least adds a paragraph + example on what to expect performance-wise and how to deal with it to the .cloned() docs.

cc `@the8472`
2022-03-23 03:05:28 +01:00
Dylan DPC
67d6cc6ef3
Rollup merge of #91608 - workingjubilee:fold-neon-fp, r=nagisa,Amanieu
Fold aarch64 feature +fp into +neon

Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON

In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a

In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.

"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.

I am... pretty sure no one is relying on this.

An argument could be made that, as we are not an "entirely proprietary" toolchain, we should not support AArch64 without floats at all. I think that's a bit excessive. However, I want to recognize the intent: programming for AArch64 should be simplified where possible. For x86-64, programmers regularly set up illegal feature configurations because it's hard to understand them, see https://github.com/rust-lang/rust/issues/89586. And per the above notes, plus the discussion in https://github.com/rust-lang/rust/issues/86941, there should be no real use cases for leaving these features split: the two should in fact always go together.

- Fixes rust-lang/rust#95002.
- Fixes rust-lang/rust#95064.
- Fixes rust-lang/rust#95122.
2022-03-23 03:05:28 +01:00
bors
2b50739b49 Auto merge of #95088 - bjorn3:fix_test_variadic_fnptr, r=dtolnay
Don't declare test_variadic_fnptr with two conflicting signatures

It is UB for LLVM and results in a compile error for Cranelift.

cc https://github.com/bjorn3/rustc_codegen_cranelift/issues/806
Fixes https://github.com/rust-lang/rust/issues/66690
2022-03-23 00:50:33 +00:00
Jubilee Young
b807d5970b Fold aarch64 feature +fp into +neon
Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON

In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a

In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.

"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.
2022-03-22 15:14:33 -07:00
bjorn3
4af755baf5 Limit test_variadic_fnptr to unix 2022-03-22 22:27:13 +01:00
Andre Bogus
1fb43f6662 add perf side effect docs to Iterator::cloned() 2022-03-22 19:07:23 +01:00
Mara Bos
733153f2e5 Move std::sys::{mutex, condvar, rwlock} to std::sys::locks. 2022-03-22 18:19:47 +01:00
ZHANGWENTAI
71e34231e0 add some fix
Signed-off-by: ZHANGWENTAI <2092913428@qq.com>
2022-03-22 23:33:08 +08:00
ZHANGWENTAI
161b01a9ac fix the lint problem
Signed-off-by: ZHANGWENTAI <2092913428@qq.com>
2022-03-22 23:10:00 +08:00
ZHANGWENTAI
6e971a8bc2 update Termination trait docs 2022-03-22 22:37:17 +08:00
bors
3ea44938e2 Auto merge of #95107 - r00ster91:fmt, r=joshtriplett
Improve formatting in macro

CC `@dtolnay`
2022-03-22 08:47:16 +00:00
bors
b9c4067417 Auto merge of #95158 - sunfishcode:sunfishcode/windows-8, r=joshtriplett
Preserve the Windows `GetLastError` error in `HandleOrInvalid`.

In the `TryFrom<HandleOrInvalid> for OwnedHandle` and
`TryFrom<HandleOrNull> for OwnedHandle` implemenations, `forget` the
owned handle on the error path, to avoid calling `CloseHandle` on an
invalid handle. It's harmless, except that it may overwrite the
thread's `GetLastError` error.

r? `@joshtriplett`
2022-03-22 05:48:49 +00:00
ltdk
d5803678c1 Add u16::is_utf16_surrogate 2022-03-21 22:51:32 -04:00
Mara Bos
ac6996345d Move pthread locks to own module. 2022-03-21 15:51:25 +01:00
Deadbeef
1f3ee7f32e
Rename ~const Drop to ~const Destruct 2022-03-21 17:04:03 +11:00
Deadbeef
4df2a28aee
Add Destructible for replacing ~const Drop 2022-03-21 17:04:02 +11:00
Dan Gohman
6c407d0592 Add a testcase. 2022-03-20 15:56:25 -07:00
Dan Gohman
95e1702284 Preserve the Windows GetLastError error in HandleOrInvalid.
In the `TryFrom<HandleOrInvalid> for OwnedHandle` and
`TryFrom<HandleOrNull> for OwnedHandle` implemenations, `forget` the
owned handle on the error path, to avoid calling `CloseHandle` on an
invalid handle. It's harmless, except that it may overwrite the
thread's `GetLastError` error.
2022-03-20 15:37:31 -07:00
bjorn3
56939ffe7d Don't declare test_variadic_fnptr with two conflicting signatures
It is UB for LLVM and results in a compile error for Cranelift
2022-03-20 21:09:35 +01:00
Matthias Krüger
3c02b5192e
Rollup merge of #95114 - ChrisDenton:symlink-test, r=the8472
Skip a test if symlink creation is not possible

If someone running tests on Windows does not have Developer Mode enabled then creating symlinks will fail which in turn would cause this test to fail. This can be a stumbling block for contributors.
2022-03-20 20:42:43 +01:00
bors
c7ce69faf2 Auto merge of #92962 - frank-king:btree_entry_no_insert, r=Amanieu
BTreeMap::entry: Avoid allocating if no insertion

This PR allows the `VacantEntry` to borrow from an empty tree with no root, and to lazily allocate a new root node when the user calls `.insert(value)`.
2022-03-20 11:20:26 +00:00
Matthias Krüger
9725caf9e9
Rollup merge of #95110 - wmstack:patch-1, r=Dylan-DPC
Provide more useful documentation of conversion methods

I thought that the documentation for these methods needed to be a bit more explanatory for new users. For advanced users, the comments are relatively unnecessary. I think it would be useful to explain precisely what the method does. As a new user, when you see the `into` method, where the type is inferred, if you are new you don't even know what you convert to, because it is implicit. I believe this can help new users understand.
2022-03-20 09:15:01 +01:00
Matthias Krüger
24a7aad082
Rollup merge of #94989 - compiler-errors:stream-alias, r=Dylan-DPC
Add Stream alias for AsyncIterator

Fixes #94965
2022-03-20 09:15:00 +01:00
Matthias Krüger
acb7ed141b
Rollup merge of #94749 - RalfJung:remove-dir-all-miri, r=cuviper
remove_dir_all: use fallback implementation on Miri

Fixes https://github.com/rust-lang/miri/issues/1966

The new implementation requires `openat`, `unlinkat`, and `fdopendir`. These cannot easily be shimmed in Miri since libstd does not expose APIs corresponding to them. So for now it is probably easiest to just use the fallback code in Miri. Nobody should run Miri as root anyway...
2022-03-20 09:14:58 +01:00
bors
f2661cfe34 Auto merge of #94372 - erikdesjardins:asrefinl, r=dtolnay
Add #[inline] to trivial AsRef/AsMut impls

These appeared uninlined in some perf runs, but they're trivial.

r? `@ghost`
2022-03-19 22:32:28 +00:00
Chris Denton
68c03cd386
Skip a test if symlink creation is not possible 2022-03-19 15:09:36 +00:00
Dylan DPC
6a73024661
Rollup merge of #94991 - CAD97:const-weak-new, r=dtolnay
Make Weak::new const

Simple enough. This is const creation of an allocating container, but no actual allocation is done, because it's defined to.
2022-03-19 14:50:25 +01:00
Dylan DPC
d1ef570a2f
Rollup merge of #94650 - ChrisDenton:windows-absolute-fix, r=dtolnay
Relax tests for Windows dos device names

Windows 11 no longer turn paths ending with dos device names into device paths.

E.g. `C:\path\to\COM1.txt` used to get turned into `\\.\COM1`. Whereas now this path is left as is.

Note though that if the given path is an exact (case-insensitive) match for the string `COM1` then it'll still be converted to `\\.\COM1`.
2022-03-19 14:50:24 +01:00
Dylan DPC
3545003b29
Rollup merge of #93858 - krallin:process-process_group, r=dtolnay
Add a `process_group` method to UNIX `CommandExt`

- Tracking issue: #93857
- RFC: https://github.com/rust-lang/rfcs/pull/3228

Add a `process_group` method to `std::os::unix::process::CommandExt` that
allows setting the process group id (i.e. calling `setpgid`) in the child, thus
enabling users to set process groups while leveraging the `posix_spawn` fast
path.
2022-03-19 14:50:24 +01:00
r00ster91
7e3fd5957b Improve formatting in macro 2022-03-19 09:44:52 +01:00
Waleed Dahshan
edee46e257
Provide more useful documentation of conversion methods
I thought that the documentation for these methods needed to be a bit more explanatory for new users. For advanced users, the comments are relatively unnecessary. I think it would be useful to explain precisely what the method does. As a new user, when you see the `into` method, where the type is inferred, if you are new you don't even know what you convert to, because it is implicit. I believe this can help new users understand.
2022-03-19 18:52:30 +11:00
Dylan DPC
30b4182fa7
Rollup merge of #94984 - ericseppanen:cstr_from_bytes, r=Mark-Simulacrum
add `CStr` method that accepts any slice containing a nul-terminated string

I haven't created an issue (tracking or otherwise) for this yet; apologies if my approach isn't correct. This is my first code contribution.

This change adds a member fn that converts a slice into a `CStr`; it is intended to be safer than `from_ptr` (which is unsafe and may read out of bounds), and more useful than `from_bytes_with_nul` (which requires that the caller already know where the nul byte is).

The reason I find this useful is for situations like this:
```rust
let mut buffer = [0u8; 32];
unsafe {
    some_c_function(buffer.as_mut_ptr(), buffer.len());
}
let result = CStr::from_bytes_with_nul(&buffer).unwrap();
```

This code above returns an error with `kind = InteriorNul`, because `from_bytes_with_nul` expects that the caller has passed in a slice with the NUL byte at the end of the slice. But if I just got back a nul-terminated string from some FFI function, I probably don't know where the NUL byte is.

I would wish for a `CStr` constructor with the following properties:
- Accept `&[u8]` as input
- Scan for the first NUL byte and return the `CStr` that spans the correct sub-slice (see [future note below](https://github.com/rust-lang/rust/pull/94984#issuecomment-1070754281)).
- Return an error if no NUL byte is found within the input slice

I asked on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/CStr.20from.20.26.5Bu8.5D.20without.20knowing.20the.20NUL.20location.3F) whether this sounded like a good idea, and got a couple of positive-sounding responses from ``@joshtriplett`` and ``@AzureMarker.``

This is my first draft, so feedback is welcome.

A few issues that definitely need feedback:

1. Naming. ``@joshtriplett`` called this `from_bytes_with_internal_nul` on Zulip, but after staring at all of the available methods, I believe that this function is probably what end users want (rather than the existing fn `from_bytes_with_nul`). Giving it a simpler name (**`from_bytes`**) implies that this should be their first choice.
2. Should I add a similar method on `CString` that accepts `Vec<u8>`? I'd assume the answer is probably yes, but I figured I'd try to get early feedback before making this change bigger.
3. What should the error type look like? I made a unit struct since `CStr::from_bytes` can only fail in one obvious way, but if I need to do this for `CString` as well then that one may want to return `FromVecWithNulError`. And maybe that should dictate the shape of the `CStr` error type also?

Also, cc ``@poliorcetics`` who wrote #73139 containing similar fns.
2022-03-19 02:02:02 +01:00
Dylan DPC
463e516b0c
Rollup merge of #93692 - mfrw:mfrw/document-keyword-in, r=dtolnay
keyword_docs: document use of `in` with `pub` keyword

Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com>

Fixes: #93609
2022-03-19 02:02:02 +01:00
Dylan DPC
fe55eee9a5
Rollup merge of #93263 - sunfishcode:sunfishcode/detatched-console-handle, r=dtolnay
Consistently present absent stdio handles on Windows as NULL handles.

This addresses #90964 by making the std API consistent about presenting
absent stdio handles on Windows as NULL handles. Stdio handles may be
absent due to `#![windows_subsystem = "windows"]`, due to the console
being detached, or due to a child process having been launched from a
parent where stdio handles are absent.

Specifically, this fixes the case of child processes of parents with absent
stdio, which previously ended up with `stdin().as_raw_handle()` returning
`INVALID_HANDLE_VALUE`, which was surprising, and which overlapped with an
unrelated valid handle value. With this patch, `stdin().as_raw_handle()`
now returns null in these situation, which is consistent with what it
does in the parent process.

And, document this in the "Windows Portability Considerations" sections of
the relevant documentation.
2022-03-19 02:02:01 +01:00
Dylan DPC
e9f63fdf86
Rollup merge of #92663 - cuviper:generic-write-cursor, r=dtolnay
Implement `Write for Cursor<[u8; N]>`, plus `A: Allocator` cursor support

This implements `Write for Cursor<[u8; N]>`, and also adds support for generic `A: Allocator` in `Box` and `Vec` cursors.

This was inspired by a user questioning why they couldn't write a `Cursor<[u8; N]>`:
https://users.rust-lang.org/t/why-vec-and-not-u8-makes-cursor-have-write/68210

Related history:
- #27197 switched `AsRef<[u8]>` for reading and seeking
- #67415 tried to use `AsMut<[u8]>` for writing, but did not specialize `Vec`.
2022-03-19 02:02:00 +01:00
Dylan DPC
a87590e34e
Rollup merge of #92612 - atopia:update-lib-l4re, r=dtolnay
Update stdlib for the l4re target

This PR contains the work by ``@humenda`` and myself to update standard library support for the x86_64-unknown-l4re-uclibc tier 3 target, split out from  humenda/rust as requested in #85967. The changes have been rebased on current master and updated in follow up commits by myself. The publishing of the changes is authorized and preferred by the original author. To preserve attribution, when standard library changes were introduced as part of other changes to the compiler, I have kept the changes concerning the standard library and altered the commit messages as indicated. Any incompatibilities have been remedied in follow up commits, so that the PR as a whole should result in a clean update of the target.
2022-03-19 02:01:59 +01:00
Dylan DPC
ba2d5ede70
Rollup merge of #92519 - ChrisDenton:command-maybe-verbatim, r=dtolnay
Use verbatim paths for `process::Command` if necessary

In #89174, the standard library started using verbatim paths so longer paths are usable by default. However, `Command` was originally left out because of the way `CreateProcessW` was being called. This was changed as a side effect of #87704 so now `Command` paths can be converted to verbatim too (if necessary).
2022-03-19 02:01:59 +01:00
CAD97
a358ad2aff Make Weak::new const 2022-03-18 17:47:36 -05:00
Eric Seppanen
d5fe4cad5a add CStr::from_bytes_until_nul
This adds a member fn that converts a slice into a CStr; it is intended
to be safer than from_ptr (which is unsafe and may read out of bounds),
and more useful than from_bytes_with_nul (which requires that the caller
already know where the nul byte is).

feature gate: cstr_from_bytes_until_nul

Also add an error type FromBytesUntilNulError for this fn.
2022-03-18 15:46:49 -07:00
David Tolnay
7d44316bcf
Bump impl Write for Cursor<[u8; N]> to 1.61 2022-03-18 15:04:37 -07:00
Matthias Krüger
9c40db22ff
Rollup merge of #95083 - danielhenrymantilla:patch-2, r=RalfJung
Document that `Option<extern "abi" fn>` discriminant elision applies for any ABI

The current phrasing was not very clear on that aspect.

r? `@RalfJung`

`@rustbot` modify labels: A-docs A-ffi
2022-03-18 21:50:50 +01:00
Matthias Krüger
c8cf9e3a8f
Rollup merge of #95058 - wcampbell0x2a:use-then-in-unix-process, r=dtolnay
Add use of bool::then in sys/unix/process

Remove `else { None }` in favor of using `bool::then()`
2022-03-18 21:50:49 +01:00
Matthias Krüger
4ead6d9dc7
Rollup merge of #95017 - zachs18:cmp_ordering_derive_eq, r=Dylan-DPC
Derive Eq for std::cmp::Ordering, instead of using manual impl.

This allows consts of type Ordering to be used in patterns, and with feature(adt_const_params) allows using `Ordering` as a const generic parameter.

Currently, `std::cmp::Ordering` implements `Eq` using a manually written `impl Eq for Ordering {}`, instead of `derive(Eq)`. This means that it does not implement `StructuralEq`.

This commit removes the manually written impl, and adds `derive(Eq)` to `Ordering`, so that it will implement `StructuralEq`.
2022-03-18 21:50:48 +01:00