-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Rollup of 12 pull requests #39876
Rollup of 12 pull requests #39876
Conversation
frewsxcv
commented
Feb 16, 2017
- Successful merges: book: don’t use GNU extensions in the example unnecessarily #39775, Allow more Cell methods for non-Copy types #39793, Show five traits implementation in help when there are exactly five #39804, static recursion test added to compile-fail test suite #39834, fix types in to_owned doctest #39836, make doc consistent with var name #39839, Update procedural-macros.md #39840, Vec, LinkedList, VecDeque, String, and Option NatVis visualizations #39843, sys/mod doc update and mod import order adjust #39844, Fix typo #39846, use bash when invoking dist shell scripts on solaris #39857, Fix parameter to GetUserProfileDirectoryW #39861
- Failed merges:
Contributes to rust-lang#39264
Contributes to rust-lang#39264
Fix typo
The use of a GNU C extension for bloc expressions is immaterial to the actual problem with C macros that the section tries to show so don’t use it and instead use a plain C way of writing the macro.
book: don’t use GNU extensions in the example unnecessarily The use of a GNU C extension for bloc expressions is immaterial to the actual problem with C macros that the section tries to show so don’t use it and instead use a plain C way of writing the macro which has added benefit of being better C code (since the macro now behaves like a function, syntax-wise).
Allow more Cell methods for non-Copy types Clearly, `get_mut` is safe for any `T`. The other two only provide unsafe pointers anyway. The only remaining inherent method with `Copy` bound is `get`, which sounds about right to me. I found the order if `impl` blocks in the file a little weird (first inherent impl, then some trait impls, then another inherent impl), but didn't change it to keep the diff small. Contributes to rust-lang#39264
…jonathandturner Show five traits implementation in help when there are exactly five Fixes rust-lang#39802
…n, r=est31 static recursion test added to compile-fail test suite Issue rust-lang#39059 r? @est31
fix types in to_owned doctest Fixes rust-lang#39831.
make doc consistent with var name
Update procedural-macros.md Fix typo
Vec, LinkedList, VecDeque, String, and Option NatVis visualizations I've added some basic [NatVis](https://msdn.microsoft.com/en-us/library/jj620914.aspx) visualizations for core Rust collections and types. This helps address a need filed in issue rust-lang#36503. NatVis visualizations are similar to gdb/lldb pretty printers, but for windbg and the Visual Studio debugger on Windows. For example, Vec without the supplied NatVis looks like this in windbg using the "dx" command: ``` 0:000> dx some_64_bit_vec some_64_bit_vec [Type: collections::vec::Vec<u64>] [+0x000] buf [Type: alloc::raw_vec::RawVec<u64>] [+0x010] len : 0x4 [Type: unsigned __int64] ``` With the NatVis, the elements of the Vec are displayed: ``` 0:000> dx some_64_bit_vec some_64_bit_vec : { size=0x4 } [Type: collections::vec::Vec<u64>] [<Raw View>] [Type: collections::vec::Vec<u64>] [size] : 0x4 [Type: unsigned __int64] [capacity] : 0x4 [Type: unsigned __int64] [0] : 0x4 [Type: unsigned __int64] [1] : 0x4f [Type: unsigned __int64] [2] : 0x1a [Type: unsigned __int64] [3] : 0x184 [Type: unsigned __int64] ``` In fact, the vector can be treated as an array by the NatVis expression evaluator: ``` 0:000> dx some_64_bit_vec[2] some_64_bit_vec[2] : 0x1a [Type: unsigned __int64] ``` In general, it works with any NatVis command that understands collections, such as NatVis LINQ expressions: ``` 0:000> dx some_64_bit_vec.Select(x => x * 2) some_64_bit_vec.Select(x => x * 2) [0] : 0x8 [1] : 0x9e [2] : 0x34 [3] : 0x308 ``` std::string::String is implemented, as well: ``` 0:000> dv hello_world = "Hello, world!" empty = "" new = "" 0:000> dx hello_world hello_world : "Hello, world!" [Type: collections::string::String] [<Raw View>] [Type: collections::string::String] [size] : 0xd [Type: unsigned __int64] [capacity] : 0xd [Type: unsigned __int64] [0] : 72 'H' [Type: char] [1] : 101 'e' [Type: char] ... [12] : 33 '!' [Type: char] 0:000> dx empty empty : "" [Type: collections::string::String] [<Raw View>] [Type: collections::string::String] [size] : 0x0 [Type: unsigned __int64] [capacity] : 0x0 [Type: unsigned __int64] ``` VecDeque and LinkedList are also implemented. My biggest concern is the implementation for Option due to the different layouts it can receive based on whether the sentinel value can be embedded with-in the Some value or must be stored separately. It seems to work, but my testing isn't exhaustive: ``` 0:000> dv three = { Some 3 } none = { None } no_str = { None } some_str = { Some "Hello!" } 0:000> dx three three : { Some 3 } [Type: core::option::Option<i32>] [<Raw View>] [Type: core::option::Option<i32>] [size] : 0x1 [Type: ULONG] [value] : 3 [Type: int] [0] : 3 [Type: int] 0:000> dx none none : { None } [Type: core::option::Option<i32>] [<Raw View>] [Type: core::option::Option<i32>] [size] : 0x0 [Type: ULONG] [value] : 4 [Type: int] 0:000> dx no_str no_str : { None } [Type: core::option::Option<collections::string::String>] [<Raw View>] [Type: core::option::Option<collections::string::String>] [size] : 0x0 [Type: ULONG] 0:000> dx some_str some_str : { Some "Hello!" } [Type: core::option::Option<collections::string::String>] [<Raw View>] [Type: core::option::Option<collections::string::String>] [size] : 0x1 [Type: ULONG] [value] : 0x4673df710 : "Hello!" [Type: collections::string::String *] [0] : "Hello!" [Type: collections::string::String] ``` For now all of these visualizations work in windbg, but I've only gotten the visualizations in libcore.natvis working in the VS debugger. My priority is windbg, but somebody else may be interested in investigating the issues related to VS. You can load these visualizations into a windbg sessions using the .nvload command: ``` 0:000> .nvload ..\rust\src\etc\natvis\libcollections.natvis; .nvload ..\rust\src\etc\natvis\libcore.natvis Successfully loaded visualizers in "..\rust\src\etc\natvis\libcollections.natvis" Successfully loaded visualizers in "..\rust\src\etc\natvis\libcore.natvis" ``` There are some issues with the symbols that Rust and LLVM conspire to emit into the PDB that inhibit debugging in windbg generally, and by extension make writing visualizations more difficult. Additionally, there are some bugs in windbg itself that complicate or disable some use of the NatVis visualizations for Rust. Significantly, due to NatVis limitations in windbg around allowable type names, you cannot write a visualization for [T] or str. I'll report separate issues as I isolate them. In the near term, I hope to fill out these NatVis files with more of Rust's core collections and types. In the long run, I hope that we can ship NatVis files with crates and streamline their deployment when debugging Rust programs on windows.
sys/mod doc update and mod import order adjust * Some doc updates. * Racer currently use the first mod it finds regardless of cfg attrs. Moving #[cfg(unix)] up should be a temporary tweak that works as expected for more people.
use bash when invoking dist shell scripts on solaris Partially fixes rust-lang#25845 A separate, trivial fix is needed to the rust-installer scripts to completely resolve this issue.
Fix parameter to GetUserProfileDirectoryW
@bors r+ p=10 |
📌 Commit c6edfdb has been approved by |
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
☀️ Test successful - status-appveyor, status-travis |