Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for ExitCodeExt on Windows #111688

Open
3 of 5 tasks
AronParker opened this issue May 17, 2023 · 2 comments
Open
3 of 5 tasks

Tracking Issue for ExitCodeExt on Windows #111688

AronParker opened this issue May 17, 2023 · 2 comments
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@AronParker
Copy link
Contributor

AronParker commented May 17, 2023

Feature gate: #![feature(windows_process_exit_code_from)]

This is a tracking issue for implementing additional ExitCodes for Windows.

Motivation

On Windows it is common for applications to return HRESULT (i32) or DWORD (u32) values. These stem from COM based components (HRESULTS), Win32 errors (GetLastError), GUI applications (WM_QUIT) and more. The newly stabilized ExitCode provides an excellent fit for propagating these values, because std::process::exit does not run deconstructors which can result in errors. However, ExitCode currently only implements From<u8> for ExitCode, which disallows the full range of i32/u32 values. This pull requests attempts to address that shortcoming by providing windows specific extensions that accept a u32 value (which covers all possible HRESULTS and Win32 errors) analog to ExitStatusExt::from_raw.

This was also intended by the original Stabilization #93840 (comment) as pointed out by @eggyal in #97914 (comment):

Issues around platform specific representations: We resolved this issue by changing the return type of report from i32 to the opaque type ExitCode. That way we can change the underlying representation without affecting the API, letting us offer full support for platform specific exit code APIs in the future.

[Emphasis added]

Public API

/// Windows-specific extensions to [`process::ExitCode`].
///
/// This trait is sealed: it cannot be implemented outside the standard library.
/// This is so that future additional methods are not breaking changes.
#[stable(feature = "windows_process_exit_code_from", since = "1.63.0")]
pub trait ExitCodeExt: Sealed {
    /// Creates a new `ExitCode` from the raw underlying `u32` return value of
    /// a process.
    #[stable(feature = "windows_process_exit_code_from", since = "1.63.0")]
    fn from_raw(raw: u32) -> Self;
}

#[stable(feature = "windows_process_exit_code_from", since = "1.63.0")]
impl ExitCodeExt for process::ExitCode {
    fn from_raw(raw: u32) -> Self {
        process::ExitCode::from_inner(From::from(raw))
    }
}

Steps / History

Unresolved Questions

  • None yet.

Additional Links

Footnotes

  1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html

@AronParker AronParker added C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels May 17, 2023
@eggyal
Copy link
Contributor

eggyal commented May 18, 2023

Kind of you to credit me for quoting that comment, but really it would make more sense to attribute it to the original author @yaahc (both to provide better context and also to draw their attention to this issue).

@AronParker
Copy link
Contributor Author

Right sorry, I updated the link. It's just what I had in mind at the time that's why I made the link, but of course crediting @yaahc makes a lot more sense.

bors added a commit to rust-lang-ci/rust that referenced this issue Nov 23, 2023
Fix tracking issue of Windows ExitCodeExt

Tracking issue: rust-lang#111688

This was left out of the initial ExitCodeExt implementation in rust-lang#97917.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants