summary refs log tree commit diff
path: root/library/std/src/sys
AgeCommit message (Collapse)AuthorLines
2023-05-15Add creation time support to `FileTimes` on apple and windowsbeetrees-19/+55
2023-05-12Auto merge of #109732 - Urgau:uplift_drop_forget_ref_lints, r=davidtwcobors-4/+14
Uplift `clippy::{drop,forget}_{ref,copy}` lints This PR aims at uplifting the `clippy::drop_ref`, `clippy::drop_copy`, `clippy::forget_ref` and `clippy::forget_copy` lints. Those lints are/were declared in the correctness category of clippy because they lint on useless and most probably is not what the developer wanted. ## `drop_ref` and `forget_ref` The `drop_ref` and `forget_ref` lint checks for calls to `std::mem::drop` or `std::mem::forget` with a reference instead of an owned value. ### Example ```rust let mut lock_guard = mutex.lock(); std::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex // still locked operation_that_requires_mutex_to_be_unlocked(); ``` ### Explanation Calling `drop` or `forget` on a reference will only drop the reference itself, which is a no-op. It will not call the `drop` or `forget` method on the underlying referenced value, which is likely what was intended. ## `drop_copy` and `forget_copy` The `drop_copy` and `forget_copy` lint checks for calls to `std::mem::forget` or `std::mem::drop` with a value that derives the Copy trait. ### Example ```rust let x: i32 = 42; // i32 implements Copy std::mem::forget(x) // A copy of x is passed to the function, leaving the // original unaffected ``` ### Explanation Calling `std::mem::forget` [does nothing for types that implement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the value will be copied and moved into the function on invocation. ----- Followed the instructions for uplift a clippy describe here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751 cc `@m-ou-se` (as T-libs-api leader because the uplifting was discussed in a recent meeting)
2023-05-11Improve code around SGX waitqueueUrgau-3/+13
Followed up of d36e390d8176babedcf326581959958d447170cd See https://github.com/rust-lang/rust/pull/109732#issuecomment-1543574908 for more details. Co-authored-by: Jethro Beekman <jethro@fortanix.com>
2023-05-10Remove and fix useless drop of referenceUrgau-2/+2
2023-05-09Don't force include Windows goop when documentingChris Denton-25/+0
2023-05-09Auto merge of #110152 - ChrisDenton:windows-sys, r=thomccbors-3097/+7088
Start using `windows sys` for Windows FFI bindings in std Switch to using windows-sys for FFI. In order to avoid some currently contentious issues, this uses windows-bindgen to generate a smaller set of bindings instead of using the full crate. Unlike the windows-sys crate, the generated bindings uses `*mut c_void` for handle types instead of `isize`. This to sidestep opsem concerns about mixing pointer types and integers between languages. Note that `SOCKET` remains defined as an integer but instead of being a usize, it's changed to fit the [standard library definition](https://github.com/rust-lang/rust/blob/a41fc00eaf352541008965fec0dee811e44373b3/library/std/src/os/windows/raw.rs#L12-L16): ```rust #[cfg(target_pointer_width = "32")] pub type SOCKET = u32; #[cfg(target_pointer_width = "64")] pub type SOCKET = u64; ``` The generated bindings also customizes the `#[link]` imports. I hope to switch to using raw-dylib but I don't want to tie that too closely with the switch to windows-sys. --- Changes outside of the bindings are, for the most part, fairly minimal (e.g. some differences in `*mut` vs. `*const` or a few types differ). One issue is that our own bindings sometimes mix in higher level types, like `BorrowedHandle`. This is pretty adhoc though.
2023-05-07PS Vita std supportNikolay Arhipov-22/+58
2023-05-06Rollup merge of #111139 - ↵Yuki Okushi-1/+5
fortanix:raoul/fix_mxcsr_configuration_dependent_timing, r=thomcc Fix MXCSR configuration dependent timing Dependent on the (potentially secret) data some vector instructions operate on, and the content in MXCSR, instruction retirement may be delayed by one cycle. This is a potential side channel. This PR fixes this vulnerability for the `x86_64-fortanix-unknown-sgx` platform by loading MXCSR with `0x1fbf` through an `xrstor` instruction when the enclave is entered and executing an `lfence` immediately after. Other changes of the MXCSR happen only when the enclave is about to be exited and no vector instructions will be executed before it will actually do so. Users of EDP who change the MXCSR and do wish to defend against this side channel, will need to implement the software mitigation described [here](https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/mxcsr-configuration-dependent-timing.html). cc: `@jethrogb` `@monokles`
2023-05-06Rollup merge of #110830 - Freaky:freebsd-cpuset, r=thomccYuki Okushi-0/+19
Add FreeBSD cpuset support to `std::thread::available_concurrency` Use libc::cpuset_getaffinity to determine the CPUs available to the current process. The existing sysconf and sysctl paths are left as fallback.
2023-05-05Sort windows_sys.lst alphabeticallyChris Denton-614/+617
2023-05-05Use new bindingsChris Denton-52/+69
2023-05-05Generate windows-sys bindingsChris Denton-3045/+7016
2023-05-05Rollup merge of #103056 - beetrees:timespec-bug-fix, r=thomccDylan DPC-24/+8
Fix `checked_{add,sub}_duration` incorrectly returning `None` when `other` has more than `i64::MAX` seconds Use `checked_{add,sub}_unsigned` in `checked_{add,sub}_duration` so that the correct result is returned when adding/subtracting durations with more than `i64::MAX` seconds.
2023-05-05Rollup merge of #110946 - RalfJung:tls-realstd, r=m-ou-seYuki Okushi-1/+6
avoid duplicating TLS state between test std and realstd This basically re-lands https://github.com/rust-lang/rust/pull/100201 and https://github.com/rust-lang/rust/pull/106638, which got reverted by https://github.com/rust-lang/rust/pull/110861. This works around 2 Miri limitations: - Miri doesn't support the magic linker section that our Windows TLS support relies on, and instead knows where in std to find the symbol that stores the thread callback. - For macOS, Miri only supports at most one destructor to be registered per thread. The 2nd would not be very hard to fix (though the intended destructor order is unclear); the first would be a lot of work to fix. Neither of these is a problem for regular Rust code, but in the std test suite we have essentially 2 copies of the std code and then these both become issues. To avoid that we have the std test crate import the TLS code from the real std instead of having its own copy. r? ``````@m-ou-se``````
2023-05-03Rollup merge of #105695 - joboet:remove_generic_parker, r=m-ou-seManish Goregaokar-0/+16
Replace generic thread parker with explicit no-op parker With #98391 merged, all platforms supporting threads now have their own parking implementations. Therefore, the generic implementation can be removed. On the remaining platforms (really just WASM without atomics), parking is not supported, so calls to `thread::park` now return instantly, which is [allowed by their API](https://doc.rust-lang.org/nightly/std/thread/fn.park.html). This is a change in behaviour, as spurious wakeups do not currently occur since all platforms guard against them. It is invalid to depend on this, but I'm still going to tag this as libs-api for confirmation. ````@rustbot```` label +T-libs +T-libs-api +A-atomic r? rust-lang/libs
2023-05-03Fix MXCSR configuration dependent timingRaoul Strackx-1/+5
Some data-independent timing vector instructions may have subtle data-dependent timing due to MXCSR configuration; dependent on (potentially secret) data instruction retirement may be delayed by one cycle.
2023-05-03Use `from_wide_to_user_path` in `read_link`Chris Denton-4/+7
2023-05-03Correctly convert an NT path to a Win32 pathChris Denton-11/+16
This can be done by simply changing the `\??\` prefix to `\\?\` and then attempting to convert to a user path. Currently it simply strips off the prefix which could lead to the wrong path being returned (e.g. if it's not a drive path or if the path contains trailing spaces, etc).
2023-05-02Rollup merge of #110895 - Ayush1325:thread-local-fix, r=thomccDylan DPC-1/+1
Remove `all` in target_thread_local cfg I think it was left there by mistake after the previous refactoring. I just came across it while rebasing to master.
2023-05-01Rollup merge of #111057 - xfix:tcpstream-as-raw-fd-inline, r=m-ou-seMatthias Krüger-0/+43
Make sure the implementation of TcpStream::as_raw_fd is fully inlined Currently the following function: ```rust use std::os::fd::{AsRawFd, RawFd}; use std::net::TcpStream; pub fn as_raw_fd(socket: &TcpStream) -> RawFd { socket.as_raw_fd() } ``` Is optimized to the following: ```asm example::as_raw_fd: push rax call qword ptr [rip + <std::net::tcp::TcpStream as std::sys_common::AsInner<std::sys_common::net::TcpStream>>::as_inner@GOTPCREL] mov rdi, rax call qword ptr [rip + std::sys_common::net::TcpStream::socket@GOTPCREL] mov rdi, rax pop rax jmp qword ptr [rip + _ZN73_$LT$std..sys..unix..net..Socket$u20$as$u20$std..os..fd..raw..AsRawFd$GT$9as_raw_fd17h633bcf7e481df8bbE@GOTPCREL] ``` I think it would make more sense to inline trivial functions used within `TcpStream::AsRawFd`.
2023-05-01Rollup merge of #110093 - beetrees:set-times-32-bit, r=joshtriplettMatthias Krüger-2/+39
Add 64-bit `time_t` support on 32-bit glibc Linux to `set_times` Add support to `set_times` for 64-bit `time_t` on 32-bit glibc Linux platforms which have a 32-bit `time_t`. Split from #109773. Tracking issue: #98245
2023-05-01Inline AsRawFd implementationsKonrad Borowski-0/+10
2023-05-01Inline socket function implementationsKonrad Borowski-0/+6
2023-05-01Inline AsInner implementationsKonrad Borowski-0/+27
2023-04-28handle cfg(bootstrap)Pietro Albini-3/+3
2023-04-28avoid duplicating TLS state between test std and realstdRalf Jung-1/+6
2023-04-28remove_dir_all: delete directory with fewer permsChris Denton-19/+22
If opening a directory with `FILE_LIST_DIRECTORY` access fails then we should try opening without requesting that access. We may still be able to delete it if it's empty or a link.
2023-04-27Remove all in target_thread_local cfgAyush Singh-1/+1
I think it was left there by mistake after previous refactoring. Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
2023-04-26Auto merge of #110861 - m-ou-se:thread-local-restructure, r=workingjubileebors-305/+274
Restructure and rename std thread_local internals to make it less of a maze Every time I try to work on std's thread local internals, it feels like I'm trying to navigate a confusing maze made of macros, deeply nested modules, and types with multiple names/aliases. Time to clean it up a bit. This PR: - Exports `Key` with its own name (`Key`), instead of `__LocalKeyInner` - Uses `pub macro` to put `__thread_local_inner` into a (unstable, hidden) module, removing `#[macro_export]`, removing it from the crate root. - Removes the `__` from `__thread_local_inner`. - Removes a few unnecessary `allow_internal_unstable` features from the macros - Removes the `libstd_thread_internals` feature. (Merged with `thread_local_internals`.) - And removes it from the unstable book - Gets rid of the deeply nested modules for the `Key` definitions (`mod fast` / `mod os` / `mod statik`). - Turns a `#[cfg]` mess into a single `cfg_if`, now that there's no `#[macro_export]` anymore that breaks with `cfg_if`. - Simplifies the `cfg_if` conditions to not repeat the conditions. - Removes useless `normalize-stderr-test`, which were left over from when the `Key` types had different names on different platforms. - Removes a seemingly unnecessary `realstd` re-export on `cfg(test)`. This PR changes nothing about the thread local implementation. That's for a later PR. (Which should hopefully be easier once all this stuff is a bit cleaned up.)
2023-04-26Restructure and rename thread local things in std.Mara Bos-305/+274
2023-04-26Rollup merge of #110419 - jsoref:spelling-library, r=jyn514Matthias Krüger-4/+4
Spelling library Split per https://github.com/rust-lang/rust/pull/110392 I can squash once people are happy w/ the changes. It's really uncommon for large sets of changes to be perfectly acceptable w/o at least some changes. I probably won't have time to respond until tomorrow or the next day
2023-04-26Rollup merge of #110587 - tomaka:fix-109727, r=jyn514jyn-2/+7
Fix `std` compilation error for wasi+atomics Fix https://github.com/rust-lang/rust/issues/109727 It seems that the `unsupported/once.rs` module isn't meant to exist at the same time as the `futex` module, as they have conflicting definitions. I've solved this by defining the `once` module only if `not(target_feature = "atomics")`. The `wasm32-unknown-unknown` target [similarly only defines the `once` module if `not(target_feature = "atomics")`](https://github.com/tomaka/rust/blob/01c4f319276da912dd2be768ae0ce9857ad6bb63/library/std/src/sys/wasm/mod.rs#L69-L70). As show in [this block of code](https://github.com/tomaka/rust/blob/01c4f319276da912dd2be768ae0ce9857ad6bb63/library/std/src/sys_common/once/mod.rs#L10-L34), the `sys::once` module doesn't need to exist if `all(target_arch = "wasm32", target_feature = "atomics")`.
2023-04-26Spelling library/Josh Soref-4/+4
* advance * aligned * borrowed * calculate * debugable * debuggable * declarations * desugaring * documentation * enclave * ignorable * initialized * iterator * kaboom * monomorphization * nonexistent * optimizer * panicking * process * reentrant * rustonomicon * the * uninitialized Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
2023-04-25Add FreeBSD cpuset support to std::thread::available_concurrencyThomas Hurst-0/+19
Use libc::cpuset_getaffinity to determine the CPUs available to the current process. The existing sysconf and sysctl paths are left as fallback.
2023-04-20More `mem::take` in `library`Scott McMurray-1/+1
A bunch of places were using `replace(…, &mut [])`, but that can just be `take`.
2023-04-20Fix `std` compilation error for wasi+atomicsPierre Krieger-2/+7
2023-04-16Windows: map a few more error codes to ErrorKindChris Denton-3/+6
NotFound errors: * `ERROR_INVALID_DRIVE`: The system cannot find the drive specified * `ERROR_BAD_NETPATH`: The network path was not found * `ERROR_BAD_NET_NAME`: The network name cannot be found. InvalidFilename: * `ERROR_BAD_PATHNAME`: The specified path is invalid.
2023-04-14Rollup merge of #110244 - kadiwa4:unnecessary_imports, r=JohnTitorMatthias Krüger-6/+0
Remove some unneeded imports / qualified paths Continuation of #105537.
2023-04-14Rollup merge of #110154 - DaniPopes:library-typos, r=JohnTitorMatthias Krüger-2/+2
Fix typos in library I ran [`typos -w library`](https://github.com/crate-ci/typos) to fix typos in the `library` directory. Refs #110150
2023-04-14Auto merge of #105007 - dlaugt:solaris-fs-link, r=ChrisDentonbors-3/+4
linkat() not available in the system headers of Solaris 10 I've installed rustup on x86_64-unknown-linux-gnu and would like to use the target sparcv9-sun-solaris. For this, I have built a gcc from the source code for cross-compiling to sparcv9-sun-solaris2.10 with system headers of Solaris 10. With the following hello word example: main.rs: ```rust fn main() { println!("Hello, world!"); } ``` I had a compilation error: ``` $ rustc -v --target sparcv9-sun-solaris -C linker=/opt/cross-solaris/gcc730/bin/sparcv9-sun-solaris2.10-gcc main.rs error: linking with `/opt/cross-solaris/gcc730/bin/sparcv9-sun-solaris2.10-gcc` failed: exit status: 1 | = note: "/opt/cross-solaris/gcc730/bin/sparcv9-sun-solaris2.10-gcc" "-m64" "/tmp/rustcgebYgj/symbols.o" "main.main.89363361-cgu.0.rcgu.o" "main.main.89363361-cgu.1.rcgu.o" "main.main.89363361-cgu.2.rcgu.o" "main.main.89363361-cgu.3.rcgu.o" "main.main.89363361-cgu.4.rcgu.o" "main.main.89363361-cgu.5.rcgu.o" "main.csypsau9u2r8348.rcgu.o" "-Wl,-z,ignore" "-L" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib" "-Wl,-Bstatic" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libstd-fa47c8247d587714.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libpanic_unwind-5c87bbe223e6c2a3.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libobject-d484934062ff9fbb.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libmemchr-e8dbd5835abcbf43.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libaddr2line-909ad09329bde2f9.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libgimli-4d74a3be929697ac.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/librustc_demangle-47cbe1d7f7271ae1.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libstd_detect-239fd2d25fb32a00.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libhashbrown-c4a7ce45fb9dec19.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libminiz_oxide-fa6bc3d9bfb4e402.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libadler-419f5a82ddd339a3.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/librustc_std_workspace_alloc-7672b378962c11be.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libunwind-0f9e07f0a032c000.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libcfg_if-ede7757c356dfb28.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/liblibc-808d56fbc668148a.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/liballoc-784767fe059ad3fe.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/librustc_std_workspace_core-aa31d7ef0556bbe1.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libcore-81d07df07db18847.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libcompiler_builtins-313a510e63006db2.rlib" "-Wl,-Bdynamic" "-lsocket" "-lposix4" "-lpthread" "-lresolv" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lsendfile" "-llgrp" "-L" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib" "-o" "main" "-nodefaultlibs" = note: /opt/cross-solaris/gcc730/lib/gcc/sparcv9-sun-solaris2.10/7.3.0/../../../../sparcv9-sun-solaris2.10/bin/ld: warning: -z ignore ignored. /home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libstd-fa47c8247d587714.rlib(std-fa47c8247d587714.std.5c42d2c1-cgu.0.rcgu.o): In function `std::sys::unix::fs::link::h3683dfbfbb4995cb': /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/sys/unix/fs.rs:1407: undefined reference to `linkat' collect2: error: ld returned 1 exit status = help: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified = note: use the `-l` flag to specify native libraries to link = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname) ``` linkat() is not available in the system headers of Solaris 10. The hello word example works fine when I build/use rust with this PR change.
2023-04-13Auto merge of #108283 - the8472:remove-splice-into-pipe, r=ChrisDentonbors-16/+88
don't splice from files into pipes in io::copy This fixes potential data ordering issue where a write performed after a copy operation could become visible in the copy even though it signaled completion. I assumed that by not setting `SPLICE_F_MOVE` we would be safe and the kernel would do a copy in kernel space and we could avoid the read-write syscall and copy-to/from-userspace costs. But apparently that flag only makes a difference when splicing from a pipe, but not when splicing into it. Context: https://lkml.org/lkml/2023/2/9/673
2023-04-12remove some unneeded importsKaDiWa-6/+0
2023-04-11Rollup merge of #110173 - solid-rs:patch/kmc-solid/socket-read-buf, r=cuviperMichael Goulet-6/+17
kmc-solid: Implement `Socket::read_buf` Follow-up to #108326. Implements `Socket::read_buf` for the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets.
2023-04-11Rollup merge of #96971 - zhaixiaojuan:master, r=wesleywiserMichael Goulet-0/+1
Initial support for loongarch64-unknown-linux-gnu Hi, We hope to add a new port in rust for LoongArch. LoongArch intro LoongArch is a RISC style ISA which is independently designed by Loongson Technology in China. It is divided into two versions, the 32-bit version (LA32) and the 64-bit version (LA64). LA64 applications have application-level backward binary compatibility with LA32 applications. LoongArch is composed of a basic part (Loongson Base) and an expanded part. The expansion part includes Loongson Binary Translation (LBT), Loongson VirtualiZation (LVZ), Loongson SIMD EXtension (LSX) and Loongson Advanced SIMD EXtension(LASX). Currently the LA464 processor core supports LoongArch ISA and the Loongson 3A5000 processor integrates 4 64-bit LA464 cores. LA464 is a four-issue 64-bit high-performance processor core. It can be used as a single core for high-end embedded and desktop applications, or as a basic processor core to form an on-chip multi-core system for server and high-performance machine applications. Documentations: ISA: https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html ABI: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html More docs can be found at: https://loongson.github.io/LoongArch-Documentation/README-EN.html Since last year, we have locally adapted two versions of rust, rust1.41 and rust1.57, and completed the test locally. I'm not sure if I'm submitting all the patches at once, so I split up the patches and here's one of the commits
2023-04-11kmc-solid: Implement `Socket::read_buf`Tomoaki Kawada-6/+17
2023-04-10Fix typos in libraryDaniPopes-2/+2
2023-04-08Add 64-bit `time_t` support on 32-bit glibc Linux to `set_times`beetrees-2/+39
2023-04-07Rollup merge of #109960 - thomcc:symlink-junction-buffer-overrun, r=ChrisDentonMatthias Krüger-9/+25
Fix buffer overrun in bootstrap and (test-only) symlink_junction I don't think these can be hit in practice, due to their inputs being valid paths. It's also not security-sensitive code, but just... bad vibes. I think this is still not really the right way to do this (in terms of path correctness), but is no worse than it was. r? `@ChrisDenton`
2023-04-07Rollup merge of #109806 - Zoxc:gnu-tls, r=pnkfelixMatthias Krüger-1/+3
Workaround #109797 on windows-gnu The addition of `#[inline]` here in https://github.com/rust-lang/rust/pull/108089 caused an unrelated linking issue (https://github.com/rust-lang/rust/issues/109797). This PR removes this attribute again on Windows to avoid regressions.
2023-04-05Fix buffer overrun in (test-only) symlink_junctionThom Chiovoloni-9/+25
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-23 17:06:40 +0000