about summary refs log tree commit diff
path: root/src/libstd/sys/windows
AgeCommit message (Collapse)AuthorLines
2020-07-27mv std libs to library/mark-7710/+0
2020-07-23avoid implicitly returning ()Ralf Jung-1/+2
2020-07-23on Windows, use miri_static_root for TLS dtorsRalf Jung-1/+16
2020-07-15Rollup merge of #74291 - regexident:from-docs, r=GuillaumeGomezManish Goregaokar-0/+1
Added docs for `From<c_int>` for `ExitStatus` Partially addresses https://github.com/rust-lang/rust/issues/51430
2020-07-14Rollup merge of #74263 - RalfJung:thread-local, r=Mark-SimulacrumManish Goregaokar-3/+3
Slight reorganization of sys/(fast_)thread_local I was long confused by the `thread_local` and `fast_thread_local` modules in the `sys(_common)` part of libstd. The names make it *sound* like `fast_thread_local` is just a faster version of `thread_local`, but really these are totally different APIs: one provides thread-local "keys", which are non-addressable pointer-sized pieces of local storage with an associated destructor; the other (the "fast" one) provides just a destructor. So I propose we rename `fast_thread_local` to `thread_local_dtor`, and `thread_local` to `thread_local_key`. That's what this PR does.
2020-07-14Added docs for `From<c_int>` for `ExitStatus`Vincent Esche-0/+1
2020-07-12Reduce unsafe scopeLzu Tao-49/+48
2020-07-12Prefer empty OsStr over unsafe cast from [u8]Lzu Tao-1/+1
2020-07-12Rewrite parse_two_compsLzu Tao-10/+41
2020-07-12Make use of slice::strip_prefix and slice patternLzu Tao-27/+24
2020-07-12Make is_valid_drive_letter functionLzu Tao-2/+8
2020-07-12Move constants to top fileLzu Tao-2/+3
2020-07-12adjust remaining targetsRalf Jung-1/+1
2020-07-12rename fast_thread_local -> thread_local_dtor; thread_local -> thread_local_keyRalf Jung-3/+3
2020-07-06Rollup merge of #74074 - sunfishcode:windows-openoptionsext-return-type, ↵Manish Goregaokar-1/+1
r=LukasKalbertodt Fix the return type of Windows' `OpenOptionsExt::security_qos_flags`. This adjusts the return type of Windows' `OpenOptionsExt::security_qos_flags` to be consistent with the other functions in the trait.
2020-07-05Fix the return type of Windows' `OpenOptionsExt::security_qos_flags`.Dan Gohman-1/+1
This adjusts the return type of Windows' `OpenOptionsExt::security_qos_flags` to be consistent with the other functions in the trait.
2020-06-26Map ERROR_INVALID_PARAMETER to InvalidInputTyler Ruckinger-0/+1
2020-06-23Rollup merge of #71756 - carstenandrich:master, r=dtolnayDylan DPC-3/+33
add Windows system error codes that should map to io::ErrorKind::TimedOut closes #71646 **Disclaimer:** The author of this pull request has a negligible amount of experience (i.e., kinda zero) with the Windows API. This PR should _definitely_ be reviewed by someone familiar with the API and its error handling. While porting POSIX software using serial ports to Windows, I found that for many Windows system error codes, an `io::Error` created via `io::Error::from_raw_os_error()` or `io::Error::last_os_error()` is not `io::ErrorKind::TimedOut`. For example, when a (non-overlapped) write to a COM port via [`WriteFile()`](https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfile) times out, [`GetLastError()`](https://docs.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-getlasterror) returns `ERROR_SEM_TIMEOUT` ([121](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-)). However, an `io::Error` created from this error code will have `io::ErrorKind::Other`. Currently, only the error codes `ERROR_OPERATION_ABORTED` and `WSAETIMEDOUT` will instantiate `io::Error`s with kind `io::ErrorKind::TimedOut`. This makes `io::Error::last_os_error()` unsuitable for error handling of syscalls that could time out, because timeouts can not be caught by matching the error's kind against `io::ErrorKind::TimedOut`. Downloading the [list of Windows system error codes](https://gist.github.com/carstenandrich/c331d557520b8a0e7f44689ca257f805) and grepping anything that sounds like a timeout (`egrep -i "timed?.?(out|limit)"`), I've identified the following error codes that should also have `io::ErrorKind::TimedOut`, because they could be I/O-related: Name | Code | Description --- | --- | --- `ERROR_SEM_TIMEOUT` | [121](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-) | The semaphore timeout period has expired. `WAIT_TIMEOUT` | [258](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-) | The wait operation timed out. `ERROR_DRIVER_CANCEL_TIMEOUT` | [594](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--500-999-) | The driver %hs failed to complete a cancelled I/O request in the allotted time. `ERROR_COUNTER_TIMEOUT` | [1121](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--1000-1299-) | A serial I/O operation completed because the timeout period expired. The IOCTL_SERIAL_XOFF_COUNTER did not reach zero.) `ERROR_TIMEOUT` | [1460](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--1300-1699-) | This operation returned because the timeout period expired. `ERROR_CTX_MODEM_RESPONSE_TIMEOUT` | [7012](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--6000-8199-) | The modem did not respond to the command sent to it. Verify that the modem is properly cabled and powered on. `ERROR_CTX_CLIENT_QUERY_TIMEOUT` | [7040](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--6000-8199-) | The client failed to respond to the server connect message. `ERROR_DS_TIMELIMIT_EXCEEDED` | [8226](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--8200-8999-) | The time limit for this request was exceeded. `DNS_ERROR_RECORD_TIMED_OUT` | [9705](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--9000-11999-) | DNS record timed out. `ERROR_IPSEC_IKE_TIMED_OUT` | [13805](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--12000-15999-) | Negotiation timed out. The following errors are also timeouts, but they don't seem to be directly related to I/O or network operations: Name | Code | Description --- | --- | --- `ERROR_SERVICE_REQUEST_TIMEOUT` | [1053](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--1000-1299-) | The service did not respond to the start or control request in a timely fashion. `ERROR_RESOURCE_CALL_TIMED_OUT` | [5910](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--4000-5999-) | The call to the cluster resource DLL timed out. `FRS_ERR_SYSVOL_POPULATE_TIMEOUT` | [8014](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--6000-8199-) | The file replication service cannot populate the system volume because of an internal timeout. The event log may have more information. `ERROR_RUNLEVEL_SWITCH_TIMEOUT` | [15402](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--12000-15999-) | The requested run level switch cannot be completed successfully since one or more services will not stop or restart within the specified timeout. `ERROR_RUNLEVEL_SWITCH_AGENT_TIMEOUT` | [15403](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--12000-15999-) | A run level switch agent did not respond within the specified timeout. Please note that `ERROR_SEM_TIMEOUT` is the only timeout error I have [seen in action](https://gist.github.com/carstenandrich/10b3962fa1abc9e50816b6460010900b). The remainder of the error codes listed above is based purely on reading documentation. This pull request adds all of the errors listed in both tables, but I'm not sure whether adding all of them makes sense. Someone with actual Windows API experience should decide that. I expect these changes to be fairly backwards compatible, because only the error's [`.kind()`](https://doc.rust-lang.org/std/io/struct.Error.html#method.kind) will change, but matching the error's code via [`.raw_os_error()`](https://doc.rust-lang.org/std/io/struct.Error.html#method.raw_os_error) will not be affected. However, code expecting these errors to be `io::ErrorKind::Other` would break. Even though I personally do not think such an implementation would make sense, after all the docs say that `io::ErrorKind` is _intended to grow over time_, a residual risk remains, of course. I took the liberty to ammend the docstring of `io::ErrorKind::Other` with a remark that discourages matching against it. As per the contributing guidelines I'm adding @steveklabnik due to the changed documentation. Also @retep998 might have some valuable insights on the error codes. r? @steveklabnik cc @retep998 cc @Mark-Simulacrum
2020-06-13add link list of error codes on docs.microsoft.comCarsten Andrich-0/+2
2020-06-10Migrate to numeric associated constsLzu Tao-12/+12
2020-06-03Bump to 1.46Mark Rousskov-4/+1
2020-05-17abort_internal is safeRalf Jung-3/+6
2020-05-02Replace `cfg` macro with attribute.Markus Reiter-1/+0
2020-05-02fix formatting issues that fail tidy testCarsten Andrich-16/+16
2020-05-02use or pattern to match error codes that map to ErrorKind::TimedOutCarsten Andrich-15/+15
2020-05-01add Windows system error codes that map to io::ErrorKind::TimedOutCarsten Andrich-2/+30
2020-04-26Update nameSteven Fackler-12/+12
2020-04-26Add Read/Write::can_read/write_vectoredSteven Fackler-0/+40
When working with an arbitrary reader or writer, code that uses vectored operations may end up being slower than code that copies into a single buffer when the underlying reader or writer doesn't actually support vectored operations. These new methods allow you to ask the reader or witer up front if vectored operations are efficiently supported. Currently, you have to use some heuristics to guess by e.g. checking if the read or write only accessed the first buffer. Hyper is one concrete example of a library that has to do this dynamically: https://github.com/hyperium/hyper/blob/0eaf304644a396895a4ce1f0146e596640bb666a/src/proto/h1/io.rs#L582-L594
2020-04-14Add missing commaYoungsuk Kim-1/+1
2020-04-09Rollup merge of #67705 - lzutao:wmemchr, r=wesleywiserMazdak Farrokhzad-2/+46
Use unrolled loop for searching NULL in [u16] on Windows
2020-04-06Forward OsStr::clone_into to the inner VecJosh Stone-0/+4
Despite OS differences, they're all just `Vec<u8>` inside, so we can just forward `clone_into` calls to that optimized implementation.
2020-04-03Rollup merge of #70597 - vakaras:thread_new_double_free_bug_fix, r=AmanieuMazdak Farrokhzad-6/+11
Fix double-free and undefined behaviour in libstd::syn::unix::Thread::new While working on concurrency support for Miri, I found that the `libstd::syn::unix::Thread::new` method has two potential problems: double-free and undefined behaviour. **Double-free** could occur if the following events happened (credit for pointing this out goes to @RalfJung): 1. The call to `pthread_create` successfully launched a new thread that executed to completion and deallocated `p`. 2. The call to `pthread_attr_destroy` returned a non-zero value causing the `assert_eq!` to panic. 3. Since `mem::forget(p)` was not yet executed, the destructor of `p` would be executed and cause a double-free. As far as I understand, this code also violates the stacked-borrows aliasing rules and thus would result in **undefined behaviour** if these rules were adopted. The problem is that the ownership of `p` is passed to the newly created thread before the call to `mem::forget`. Since the call to `mem::forget` is still a call, it counts as a use of `p` and triggers UB. This pull request changes the code to use `mem::ManuallyDrop` instead of `mem::forget`. As a consequence, in case of a panic, `p` would be potentially leaked, which while undesirable is probably better than double-free or undefined behaviour.
2020-04-02Use unrolled looplzutao-9/+43
2020-04-02use of wmemchr for faster searching in [u16]Lzu Tao-2/+12
2020-04-01In Thread::new, add a comment that a panic could cause a memory leak.Vytautas Astrauskas-1/+1
2020-03-31Use Box::into_raw instead of ManuallyDrop in Thread::new.Vytautas Astrauskas-5/+4
2020-04-01Rollup merge of #70081 - lcnr:issue68387, r=varkorDylan DPC-3/+2
add `unused_braces` lint Add the lint `unused_braces` which is warn by default. `unused_parens` is also extended and now checks anon consts. closes #68387 r? @varkor
2020-03-31Inline start_thread into its callers.Vytautas Astrauskas-2/+6
2020-03-31Fix double-free and undefined behaviour in libstd::syn::unix::Thread::new.Vytautas Astrauskas-3/+5
2020-03-31fix internal lint falloutBastian Kauschke-3/+2
2020-03-30Rollup merge of #70479 - RalfJung:win-env, r=Mark-SimulacrumDylan DPC-1/+1
avoid creating unnecessary reference in Windows Env iterator Discovered in https://github.com/rust-lang/miri/pull/1225: the Windows `Env` iterator violates Stacked Borrows by creating an `&u16`, turning it into a raw pointer, and then accessing memory outside the range of that type. There is no need to create a reference here in the first place, so the fix is trivial. Cc @JOE1994 Cc https://github.com/rust-lang/unsafe-code-guidelines/issues/134
2020-03-29Rollup merge of #70510 - RalfJung:bool-vs-boolean, r=Mark-SimulacrumDylan DPC-1/+1
fix TryEnterCriticalSection return type Source: https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-tryentercriticalsection Fixes https://github.com/rust-lang/rust/issues/70504
2020-03-29Rollup merge of #69937 - TyPR124:osstr_ascii, r=dtolnayDylan DPC-5/+34
ASCII methods on OsStr Would close #69566 I don't know enough about encodings to know if this is a valid change, however the comment on the issue suggests it could be. This does two things: 1. Makes ASCII methods available on OsStr 2. Makes it possible to obtain a `&mut OsStr`. This is necessary to actually use `OsStr::make_ascii_*case` methods since they modify the underlying value. As far as I can tell, the only way to modify a `&mut OsStr` is via the methods I just added. My original hope was to have these methods on `OsStrExt` for Windows, since the standard library already assumes `make_ascii_uppercase` is valid in Windows (see the change I made to windows/process.rs). If it is found these are not valid changes on non-Windows platforms, I can move the methods to the ext trait instead.
2020-03-28use make_ascii_uppercase in windows/process.rsTyPR124-5/+4
2020-03-28ascii methods on osstrTyPR124-0/+30
2020-03-28fix TryEnterCriticalSection return typeRalf Jung-1/+1
2020-03-27avoid creating unnecessary reference in Windows Env iteratorRalf Jung-1/+1
2020-03-27Auto merge of #68404 - Amanieu:llvm-asm, r=estebankbors-1/+1
Rename asm! to llvm_asm! As per https://github.com/rust-lang/rfcs/pull/2843, this PR renames `asm!` to `llvm_asm!`. It also renames the compiler's internal `InlineAsm` data structures to `LlvmInlineAsm` in preparation for the new `asm!` functionality specified in https://github.com/rust-lang/rfcs/pull/2850. This PR doesn't actually deprecate `asm!` yet, it just makes it redirect to `llvm_asm!`. This is necessary because we first need to update the submodules (in particular stdarch) to use `llvm_asm!`.
2020-03-27Rollup merge of #70048 - TyPR124:mutable_osstr, r=dtolnayDylan DPC-0/+12
Allow obtaining &mut OsStr ```rust impl DerefMut for OsString {...} // type Target = OsStr impl IndexMut<RangeFull> for OsString {...} // type Output = OsStr ``` --- This change is pulled out of #69937 per @dtolnay This implements `DerefMut for OsString` to allow obtaining a `&mut OsStr`. This also implements `IndexMut for OsString`, which is used by `DerefMut`. This pattern is the same as is used by `Deref`. This is necessary to for methods like `make_ascii_lowercase` which need to mutate the underlying value.
2020-03-26Rename asm! to llvm_asm!Amanieu d'Antras-1/+1
asm! is left as a wrapper around llvm_asm! to maintain compatibility.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-14 12:00:44 +0000