rust/library/std/src/sys/windows, branch tryhttps://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=try2024-01-11T19:10:25+00:00std: begin moving platform support modules into `pal`2024-01-11T19:10:25+00:00joboetjonasboettiger@icloud.com2024-01-11T19:10:25+00:00urn:sha1:99128b7e45f8b95d962da2e6ea584767f0c85455Use FileEndOfFileInfo, not FileAllocationInfo2023-12-17T17:57:33+00:00Chris Dentonchris@chrisdenton.dev2023-12-17T17:54:20+00:00urn:sha1:e585b0ed58b8b5bd3dd3b549be7e7313bbd7ce25
This fixes WINE support
Auto merge of #118566 - klensy:cstr-new, r=WaffleLapkin2023-12-14T11:14:03+00:00borsbors@rust-lang.org2023-12-14T11:14:03+00:00urn:sha1:1aa6aefdc92555b3fbc5ae4c99365df9845a3e31
use c literals in compiler and library
Relands refreshed https://github.com/rust-lang/rust/pull/111647
Auto merge of #116438 - ChrisDenton:truncate, r=thomcc2023-12-13T02:27:12+00:00borsbors@rust-lang.org2023-12-13T02:27:12+00:00urn:sha1:77d16997566dfb2384bcbc504e2579c7ae973666
Windows: Allow `File::create` to work on hidden files
This makes `OpenOptions::new().write(true).create(true).truncate(true).open(&path)` work if the path exists and is a hidden file. Previously it would fail with access denied.
This makes it consistent with `OpenOptions::new().write(true).truncate(true).open(&path)` (note the lack of `create`) which does not have this restriction. It's also more consistent with other platforms.
Fixes #115745 (see that issue for more details).
library: fix comment about const assert in win api2023-12-06T10:52:30+00:00klensyklensy@users.noreply.github.com2023-12-06T10:45:46+00:00urn:sha1:7ff9648808921746dcd08c050c7ff8918c3551b9library: use c string literals2023-12-03T11:54:09+00:00klensyklensy@users.noreply.github.com2023-12-03T11:24:25+00:00urn:sha1:c0134887d2b4cbac421babcd40710cc9b755f931Rollup merge of #118060 - ChrisDenton:abs-device-path, r=thomcc2023-11-24T07:23:53+00:00Matthias Krügermatthias.krueger@famsik.de2023-11-24T07:23:53+00:00urn:sha1:b2d6480f536196b8075d5fd451a70fca8f04a3f5
Use an absolute path to the NUL device
While a bare "NUL" *should* be redirected to the NUL device, especially in this simple case, let's be explicit that we aren't opening a file called "NUL" and instead open it directly.
This will also set a good example for people copying std code.
r? libs
Rollup merge of #117656 - ChrisDenton:invalid, r=thomcc2023-11-24T07:23:52+00:00Matthias Krügermatthias.krueger@famsik.de2023-11-24T07:23:52+00:00urn:sha1:7e3ec1b0e25915fb16ae43223752a25d50e3ce0f
Update windows-bindgen and define `INVALID_HANDLE_VALUE` ourselves
We generate bindings to the Windows API via the `windows-bindgen` crate, which is ultimately what's also used to generate the `windows-sys` and `windows` crates. However, there currently is some custom sauce just for std which makes it a bit different from the vanilla bindings. I would love for us to reduce and eventually remove the differences entirely so that std is using the exact same bindings as everyone else. Maybe in the future we can even just have a normal dependency on `windows-sys`.
This PR removes one of those special things. Our definition of `INVALID_HANDLE_VALUE` relies on an experimental nightly feature for strict provenance, so lets bring that back in house. It also excludes it from the codegen step though that isn't strictly necessary as we override it in any case.
This PR also updates windows-bingen to 0.52.0.
x fmt library/std2023-11-22T13:17:02+00:00Chris Dentonchris@chrisdenton.dev2023-11-22T00:44:37+00:00urn:sha1:b9fe367b9993c33a022411fd08e3da0081abacfdredundant_slicing2023-11-22T13:17:02+00:00Chris Dentonchris@chrisdenton.dev2023-11-22T00:10:48+00:00urn:sha1:6c8ebf174c3201ec6333e8bf2df291b88e338d35