-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Remove dependency on shell32.dll #56568
Conversation
r? @dtolnay (rust_highfive has picked a reviewer for you, use r? to override) |
It'd be good to also run this on Windows a couple times to attempt to ascertain performance impact on our tests, though we could also just land it and see what AppVeyor looks like over the next dozen builds. |
|
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this! Naturally my biggest worry here is that this may not be compatible with the previous API call, so we need to be super careful. The documentation for CommandLineToArgvW
says some things like:
However, if lpCmdLine starts with any amount of whitespace, CommandLineToArgvW will consider the first argument to be an empty string. Excess whitespace at the end of lpCmdLine is ignored.
but that may not be handled here?
I think this otherwise looks pretty equivalent though. Could this perhaps be tested locally more rigorously? Could the output of CommandLineToArgvW
be compared to this implementation for a number of procedurally generated inputs?
Does it help to compare the implementation in Wine and ReactOS? https://doxygen.reactos.org/da/da5/shell32__main_8c_source.html |
Seems like a great thing to throw at a fuzzer of some sort for a day or two, before it is merged. Among other things this would not only verify the correctness of the code, but also give considerable degree of confidence about the equivalence of the function(s). |
This comment has been minimized.
This comment has been minimized.
Okay, here's a test harness that I put together to compare the behavior of the two (it is exhaustive, rather than random, so it should be pretty thorough). https://gist.github.com/notriddle/dde431930c392e428055b2dc22e638f5 https://paste.gg/p/anonymous/47d6ed5f5bd549168b1c69c799825223 And, yeah, I've found several inconsistencies. The ReactOS code was also helpful for figuring out what was wrong; thanks @pitdicker ! |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Well, there's another thing I need to figure out. |
2de79c1
to
f6e7c37
Compare
This comment has been minimized.
This comment has been minimized.
The exhaustive test now finishes without producing any errors! |
It looks like some submodule updates may have snuck in here by accident? Otherwise this seems like it's likely good to go perhaps? |
@alexcrichton Fixed. |
@bors: r+ 💯 |
📌 Commit 83fe6e4 has been approved by |
⌛ Testing commit 83fe6e4 with merge a8aa87621b2bb1f806793c93b5eea25649b7e651... |
💔 Test failed - status-appveyor |
This comment has been minimized.
This comment has been minimized.
@bors: retry
|
@bors p=1 retry |
Remove dependency on shell32.dll Closes #56510 if it works on MinGW (I've only tested it on MSVC).
☀️ Test successful - status-appveyor, status-travis |
Just wanted to say this is also useful for getting Rust binaries running inside nanoserver containers, since those don't have (Might be worth advertising this in the 1.33 release post :) ) |
end += 1; | ||
} | ||
slice::from_raw_parts(lp_cmd_line, end as usize) | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be better to split this pointer manipulation into a separate function?
It looks like there's no actual unsafe
code below this point, but you wouldn't know that without digging through the whole implementation.
Before this change, FileDialogOptions::starting_directory had not been used on Windows and therefore had no influence on the starting directory of a FileDialog window. This has now been fixed. The use of `SHCreateItemFromParsingName` makes it mandatory to explicitly link against shell32.lib because this is not done automatically since Rust 1.33.0. See rust-lang/rust#56568 for details.
Before this change, FileDialogOptions::starting_directory had not been used on Windows and therefore had no influence on the starting directory of a FileDialog window. This has now been fixed. The use of `SHCreateItemFromParsingName` makes it mandatory to explicitly link against shell32.lib because this is not done automatically since Rust 1.33.0. See rust-lang/rust#56568 for details.
Before this change, FileDialogOptions::starting_directory had not been used on Windows and therefore had no influence on the starting directory of a FileDialog window. This has now been fixed. The use of `SHCreateItemFromParsingName` makes it mandatory to explicitly link against shell32.lib because this is not done automatically since Rust 1.33.0. See rust-lang/rust#56568 for details.
* Respect starting directory for dialogs on Windows Before this change, FileDialogOptions::starting_directory had not been used on Windows and therefore had no influence on the starting directory of a FileDialog window. This has now been fixed. The use of `SHCreateItemFromParsingName` makes it mandatory to explicitly link against shell32.lib because this is not done automatically since Rust 1.33.0. See rust-lang/rust#56568 for details. * Fix: Use winapi feature instead of build.rs As it turns out, the winapi crate already exposes shell32.lib via a cargo feature, so there is no need to link it manually.
Closes #56510 if it works on MinGW (I've only tested it on MSVC).