Commit Graph

5385 Commits

Author SHA1 Message Date
r0cky
c7519d42c2 Update tests 2024-02-07 10:42:01 +08:00
bors
ea37e8091f Auto merge of #117372 - Amanieu:stdarch_update, r=Mark-Simulacrum
Update stdarch submodule

Splits up #27731 into multiple tracking issues.

Closes #27731
2024-02-05 15:41:40 +00:00
Matthias Krüger
13ea09b22f
Rollup merge of #120657 - mu001999:clean, r=Nilstrieb
Remove unused struct

Detected by #118257
2024-02-05 11:07:28 +01:00
Matthias Krüger
d8e9ddc843
Rollup merge of #120607 - conradludgate:fix-120603, r=dtolnay
fix #120603 by adding a check in default_read_buf

Fixes #120603 by checking the returned read n is in-bounds of the cursor.

Interestingly, I noticed that `BorrowedBuf` side-steps this issue by using checked accesses. Maybe this can be switched to unchecked to mirror what BufReader does bf3c6c5bed/library/core/src/io/borrowed_buf.rs (L95)
2024-02-05 06:37:16 +01:00
Matthias Krüger
16200db7aa
Rollup merge of #120572 - pheki:update-libc, r=Mark-Simulacrum
Update libc to 0.2.153

Bumps libc dependency to 0.2.153, which includes this fix, required for building std for the vita: https://github.com/rust-lang/libc/pull/3552
2024-02-05 06:37:15 +01:00
r0cky
8266657338 Remove unused struct 2024-02-05 10:04:36 +08:00
Matthias Krüger
3e24351677
Rollup merge of #120528 - GnomedDev:atomicu8-backtrace-style, r=cuviper
Store SHOULD_CAPTURE as AtomicU8

`BacktraceStyle` easily fits into a u8, so `SHOULD_CAPTURE`, which is just `Atomic<Option<BacktraceStyle>>`, should be stored as `AtomicU8`
2024-02-03 22:25:16 +01:00
Matthias Krüger
a3ea64719b
Rollup merge of #120523 - a1phyr:improve_read_buf_exact, r=the8472
Improve `io::Read::read_buf_exact` error case

- Use `const_io_error` instead of `Error::new`
- Use the same message as `read_exact`
2024-02-03 22:25:15 +01:00
Conrad Ludgate
4c694db252 add another test to make sure it still works with full reads 2024-02-03 11:46:54 +00:00
Conrad Ludgate
a27e45a71b fix #120603 by adding a check in default_read_buf 2024-02-03 11:30:26 +00:00
Aphek
ee8703315e Update libc to 0.2.153 2024-02-01 23:58:42 -03:00
GnomedDev
7ea4dbbadb
Store SHOULD_CAPTURE as AtomicU8 2024-01-31 13:58:52 +00:00
Nadrieril
a7d5382e5c
Rollup merge of #120430 - devnexen:fix_tls_dtor_fbsd, r=cuviper
std: thread_local::register_dtor fix proposal for FreeBSD.

following-up 5d3d347 commit, rust started to spin
__cxa_thread_call_dtors warnings even without any TLS usage. using instead home made TLS destructor handler `register_dtor_fallback`.

close #120413
2024-01-31 12:10:51 +01:00
Benoît du Garreau
a158fb33ef Improve io::Read::read_buf_exact error case
- Use `const_io_error` instead of `Error::new`
- Use the same message as `read_exact`
2024-01-31 11:06:19 +01:00
Guillaume Gomez
27bc496564
Rollup merge of #120485 - chenyukang:yukang-add-query-instability-check, r=michaelwoerister
add missing potential_query_instability for keys and values in hashmap

From https://github.com/rust-lang/rust/pull/120435#discussion_r1468883787,

These API are also returning iterator, so we need add `potential_query_instability` for them?
2024-01-30 16:57:51 +01:00
Guillaume Gomez
d10f33a8d1
Rollup merge of #120434 - fmease:revert-speeder, r=petrochenkov
Revert outdated version of "Add the wasm32-wasi-preview2 target"

An outdated version of #119616 was merged in rollup #120309.
This reverts those changes to enable #119616 to “retain the intended diff” after a rebase.
```@rylev``` has agreed that this would be the cleanest approach with respect to the history.
Unblocks #119616.

r? ```@petrochenkov``` or compiler or libs
2024-01-30 16:57:49 +01:00
Guillaume Gomez
4f4ceefe16
Rollup merge of #120295 - reitermarkus:remove-ffi-nonzero, r=dtolnay
Remove `raw_os_nonzero` feature.

This feature is superseded by a generic `NonZero` type: https://github.com/rust-lang/rust/issues/120257

Closes https://github.com/rust-lang/rust/issues/82363.
2024-01-30 16:57:48 +01:00
Guillaume Gomez
d5e8d85249
Rollup merge of #120452 - alexcrichton:update-windows-seek-write-docs, r=ChrisDenton
std: Update documentation of seek_write on Windows

Currently the documentation of `FileExt::seek_write` on Windows indicates that writes beyond the end of the file leave intermediate bytes uninitialized. This commentary dates back to the original inclusion of these functions in #35704 (wow blast from the past!). At the time the functionality here was implemented using `WriteFile`, but nowadays the `NtWriteFile` method is used instead. The documentation for `NtWriteFile` explicitly states:

> If Length and ByteOffset specify a write operation past the current
> end-of-file mark, NtWriteFile automatically extends the file and updates
> the end-of-file mark; any bytes that are not explicitly written between
> such old and new end-of-file marks are defined to be zero.

This commentary has had a downstream impact in the `system-interface` crate where it tries to handle this by explicitly writing zeros, but I don't believe that's necessary any more. I'm sending a PR upstream here to avoid future confusion and codify that zeros are written in the intermediate bytes matching what Windows currently provides.
2024-01-30 11:19:18 +01:00
Guillaume Gomez
5db58538cf
Rollup merge of #119991 - kornelski:endless-read, r=the8472
Reject infinitely-sized reads from io::Repeat

These calls would always run out of memory.

Related to #117925
2024-01-30 11:19:12 +01:00
bors
5c9c3c7871 Auto merge of #117925 - kornelski:read-to-oom, r=Amanieu
Handle out of memory errors in io:Read::read_to_end()

#116570 got stuck due to a [procedural confusion](https://github.com/rust-lang/rust/pull/116570#issuecomment-1768271068). Retrying so that it can get FCP with the proper team now. cc `@joshtriplett` `@BurntSushi`

----

I'd like to propose handling of out-of-memory errors in the default implementation of `io::Read::read_to_end()` and `fs::read()`. These methods create/grow a `Vec` with a size that is external to the program, and could be arbitrarily large.

Due to being I/O methods, they can already fail in a variety of ways, in theory even including `ENOMEM` from the OS too, so another failure case should not surprise anyone.

While this may not help much Linux with overcommit, it's useful for other platforms like WASM. [Internals thread](https://internals.rust-lang.org/t/io-read-read-to-end-should-handle-oom/19662).

I've added documentation that makes it explicit that the OOM handling is a nice-to-have, and not a guarantee of the trait.

I haven't changed the implementation of `impl Read for &[u8]` and `VecDeque` out of caution, because in these cases users could assume `read` can't fail.

This code uses `try_reserve()` + `extend_from_slice()` which is optimized since #117503.
2024-01-30 05:10:11 +00:00
yukang
ad526d831e add missing potential_query_instability for keys and values in hashmap 2024-01-30 12:43:10 +08:00
Amanieu d'Antras
31007f51ed Add stdarch_wasm_atomic_wait feature in std 2024-01-30 03:34:30 +00:00
Amanieu d'Antras
9a39e41637 Update feature names for new stdarch 2024-01-30 03:33:12 +00:00
Amanieu d'Antras
f8d4b2a150 Update stdarch submodule 2024-01-30 03:33:12 +00:00
Kornel
60f46289cf Handle out of memory errors in fs::read/read_to_string 2024-01-29 23:53:45 +00:00
Kornel
03545161e6 Handle out of memory errors in io:Read::read_to_end() 2024-01-29 23:53:09 +00:00
Markus Reiter
bf4de3a874
Remove raw_os_nonzero feature. 2024-01-29 22:02:11 +01:00
Dylan DPC
c70c4cc708
Rollup merge of #120462 - mu001999:clean, r=Nilstrieb
Clean dead code

Detected by #118257
2024-01-29 12:56:55 +00:00
Dylan DPC
d04bede047
Rollup merge of #120373 - HTGAzureX1212:HTGAzureX1212/issue-120040, r=ChrisDenton
Adjust Behaviour of `read_dir` and `ReadDir` in Windows Implementation: Check Whether Path to Search In Exists

This pull request changes the `read_dir` function's and the `ReadDir` structure's internal implementations for the Windows operating system to make its behaviour more accurate.

It should be noted that `ERROR_FILE_NOT_FOUND` is returned by the `FindFirstFileW` function when *no matching files can be found*, not necessarily that the path to search in does not exist in the first place. Therefore, directly returning the "The system cannot find the file specified." may not be accurate.

An extra check for whether the path to search in exists is added, returning a constructed `ReadDir` iterator with its handle being an `INVALID_HANDLE_VALUE` returned by the `FindFirstFileW` function if `ERROR_FILE_NOT_FOUND` is indeed the last OS error. The `ReadDir` implementation for the Windows operating system is correspondingly updated to always return `None` if the handle it has is an `INVALID_HANDLE_VALUE` which can only be the case if and only if specifically constructed by the `read_dir` function in the aforementioned conditions.

It should also be noted that `FindFirstFileW` would have returned `ERROR_PATH_NOT_FOUND` if the path to search in does not exist in the first place.

Presumably fixes #120040.
2024-01-29 12:56:52 +00:00
r0cky
d3bf8b717b Clean dead code 2024-01-29 14:04:42 +08:00
Alex Crichton
b85b2a783b std: Update documentation of seek_write on Windows
Currently the documentation of `FileExt::seek_write` on Windows
indicates that writes beyond the end of the file leave intermediate
bytes uninitialized. This commentary dates back to the original
inclusion of these functions in #35704 (wow blast from the past!). At
the time the functionality here was implemented using `WriteFile`, but
nowadays the `NtWriteFile` method is used instead. The documentation for
`NtWriteFile` explicitly states:

> If Length and ByteOffset specify a write operation past the current
> end-of-file mark, NtWriteFile automatically extends the file and updates
> the end-of-file mark; any bytes that are not explicitly written between
> such old and new end-of-file marks are defined to be zero.

This commentary has had a downstream impact in the `system-interface`
crate where it tries to handle this by explicitly writing zeros, but I
don't believe that's necessary any more. I'm sending a PR upstream here
to avoid future confusion and codify that zeros are written in the
intermediate bytes matching what Windows currently provides.
2024-01-28 11:24:27 -08:00
León Orell Valerian Liehr
9199742339
Revert "Add the wasm32-wasi-preview2 target"
This reverts commit 31ecf34125.

Co-authored-by: Ryan Levick <me@ryanlevick.com>
2024-01-28 02:02:50 +01:00
David Carlier
4c010259ef std: thread_local::register_dtor fix proposal for FreeBSD.
following-up 5d3d347 commit, rust started to spin
__cxa_thread_call_dtors warnings even without any TLS usage.
using instead home made TLS destructor handler `register_dtor_fallback`.

close #120413
2024-01-27 19:14:31 +00:00
Kornel
2251e9abee Reject infinitely-sized reads from io::Repeat
Related to #117925
2024-01-27 18:52:41 +00:00
Markus Reiter
4f0ce6fca2
Switch NonZero alias direction. 2024-01-27 16:38:57 +01:00
HTGAzureX1212.
018bf305cd
add extra check for invalid handle in ReadDir::next 2024-01-27 12:43:38 +08:00
HTGAzureX1212.
e26f213050
make modifications as per reviews 2024-01-27 12:28:28 +08:00
Matthias Krüger
975a82b4e2
Rollup merge of #120205 - Berrysoft:windows-alloc-init, r=ChrisDenton
std: make `HEAP` initializer never inline

The system allocator for Windows calls `init_or_get_process_heap` every time allocating. It generates very much useless code and makes the binary larger. The `HEAP` only needs to initialize once before the main fn.

Concerns:
* I'm not sure if `init` will be properly called in cdylib.
* Do we need to ensure the allocator works if the user enables `no_main`?
* Should we panic if `GetProcessHeap` returns null?
2024-01-26 23:15:50 +01:00
Matthias Krüger
b09f2328d6
Rollup merge of #120117 - NobodyXu:99262/update-api-and-doc, r=m-ou-se
Update `std::io::Error::downcast` return type

and update its doc according to decision made by rust libs-api team in https://github.com/rust-lang/rust/issues/99262#issuecomment-1894246216
2024-01-26 14:43:30 +01:00
HTGAzureX1212.
2241d16189
fix 2024-01-26 20:34:13 +08:00
HTGAzureX1212.
8f89e57e9f
remove redundant call to Error::last_os_error 2024-01-26 20:27:20 +08:00
HTGAzureX1212.
3269513eb0
fix issue 120040 2024-01-26 20:15:30 +08:00
Matthias Krüger
cfa583b388
Rollup merge of #120053 - AldanTanneo:specialize-stdinlock-bytes, r=the8472
Specialize `Bytes` on `StdinLock<'_>`

I noticed recently, while profiling a little project, that I was spending a lot of time reading from stdin (even with locking). I was using the `.bytes()` iterator adaptor; I figured, since `StdinLock` is a `BufReader` internally, it would work just as fast. But this is not the case, as `Bytes` is only specialized for the raw `BufReader`, and not the `StdinLock`/`MutexGuard` wrapper. Performance improved significantly when I wrapped the lock in a new `BufReader`, but I was still a bit sore about the double buffer indirection.

This PR attempts to specialize it, by simply calling the already specialized implementation on `BufReader`.
2024-01-26 06:36:37 +01:00
Matthias Krüger
d7a9f51df7
Rollup merge of #120332 - mu001999:cleanup/dead_code, r=Nilstrieb
Remove unused struct

Detected by #118257
2024-01-25 17:39:30 +01:00
Matthias Krüger
8750bec42a
Rollup merge of #120306 - safinaskar:clone3-clean-up, r=petrochenkov
Clean up after clone3 removal from pidfd code (docs and tests)

https://github.com/rust-lang/rust/pull/113939 removed clone3 from pidfd code. This patchset does necessary clean up: fixes docs and tests
2024-01-25 17:39:28 +01:00
León Orell Valerian Liehr
e0a4f43903
Rollup merge of #119616 - rylev:wasm32-wasi-preview2, r=petrochenkov,m-ou-se
Add a new `wasm32-wasi-preview2` target

This is the initial implementation of the MCP https://github.com/rust-lang/compiler-team/issues/694 creating a new tier 3 target `wasm32-wasi-preview2`. That MCP has been seconded and will most likely be approved in a little over a week from now. For more information on the need for this target, please read the [MCP](https://github.com/rust-lang/compiler-team/issues/694).

There is one aspect of this PR that will become insta-stable once these changes reach a stable compiler:
* A new `target_family` named `wasi` is introduced. This target family incorporates all wasi targets including `wasm32-wasi` and its derivative `wasm32-wasi-preview1-threads`. The difference between `target_family = wasi` and `target_os = wasi` will become much clearer when `wasm32-wasi` is renamed to `wasm32-wasi-preview1` and the `target_os` becomes `wasm32-wasi-preview1`. You can read about this target rename in [this MCP](https://github.com/rust-lang/compiler-team/issues/695) which has also been seconded and will hopefully be officially approved soon.

Additional technical details include:
* Both `std::sys::wasi_preview2` and `std::os::wasi_preview2` have been created and mostly use `#[path]` annotations on their submodules to reach into the existing `wasi` (soon to be `wasi_preview1`) modules. Over time the differences between `wasi_preview1` and `wasi_preview2` will grow and most like all `#[path]` based module aliases will fall away.
* Building `wasi-preview2` relies on a [`wasi-sdk`](https://github.com/WebAssembly/wasi-sdk) in the same way that `wasi-preview1` does (one must include a `wasi-root` path in the `Config.toml` pointing to sysroot included in the wasi-sdk). The target should build against [wasi-sdk v21](https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-21) without modifications. However, the wasi-sdk itself is growing [preview2 support](https://github.com/WebAssembly/wasi-sdk/pull/370) so this might shift rapidly. We will be following along quickly to make sure that building the target remains possible as the wasi-sdk changes.
* This requires a [patch to libc](https://github.com/rylev/rust-libc/tree/wasm32-wasi-preview2) that we'll need to land in conjunction with this change. Until that patch lands the target won't actually build.
2024-01-24 15:43:12 +01:00
Askar Safin
df0c9c37c1 Finishing clone3 clean up 2024-01-24 17:23:51 +03:00
Askar Safin
1ee773e242 This commit is part of clone3 clean up. Merge tests from tests/ui/command/command-create-pidfd.rs
to library/std/src/sys/pal/unix/process/process_unix/tests.rs to remove code
duplication
2024-01-24 17:23:42 +03:00
Askar Safin
57f9d1f01a This commit is part of clone3 clean up. As part of clean up we will
remove tests/ui/command/command-create-pidfd.rs . But it contains
very useful comment, so let's move the comment to library/std/src/sys/pal/unix/rand.rs ,
which contains another instance of the same Docker problem
2024-01-24 15:22:00 +03:00
León Orell Valerian Liehr
1e5ec4d82a
Rollup merge of #120188 - devnexen:update_bsd_compiler_base_specs, r=wesleywiser
compiler: update freebsd and netbsd base specs.

both support thread local.
2024-01-23 21:19:53 +01:00