Skip to content

Rollup of 4 pull requests - #66656

Merged
bors merged 8 commits into
rust-lang:masterfrom
Centril:rollup-fivygwz
Nov 23, 2019
Merged

Rollup of 4 pull requests#66656
bors merged 8 commits into
rust-lang:masterfrom
Centril:rollup-fivygwz

Conversation

@Centril

Copy link
Copy Markdown
Contributor

Successful merges:

Failed merges:

r? @ghost

lcnrand others added 8 commits November 19, 2019 10:18
…ed vec.
I based this solution on my reading of:
https://rethinkdb.com/blog/make-debugging-easier-with-custom-pretty-printers#what-is-still-to-be-done
That post claims that there is no clean way to check for garbage pointers, and
so this PR adopts the same solution of tentatively attempting to convert a
dererence to a string, which throws a clean exception on garbage that we can
catch and recover from.
I only made the change to vec and not the other pretty printers because I wanted
to focus my effort on the simplest thing that would resolve issue rust-lang#64343. In
particular, I *considered* generalizing this fix to work on the other datatypes
in the pretty-printing support library, but I don't want to invest effort in
that until after we resolve our overall debugging support strategy; see also
issues rust-lang#60826 and rust-lang#65564.
While the redesign is in progress (rust-lang#62886), clarify the purpose of replace_zero and replace_one.
add fn type_name_of_val
This function is often useful during testing and mirrors `align_of_val` and `size_of_val`.
# Example
Showing the default type of integers.
```rust
let x = 7;
println!("per default, integers have the type: {}", std::any::type_name_of_val(&x));
```
To my knowledge this can currently not be done without defining a function similar to `type_name_of_val`.
…-check, r=Mark-Simulacrum
Update tidy check for error codes testing
Now that all the error codes have been grouped into one file, we moved the long error explanations into markdown files, which means that we need to read those markdown file to also count their code blocks as well.
So 2 "big" things happened here:
* No more need to keep the current error code when reading the `error_codes.rs` file since it's been put into the equivalent markdown file.
* Need to instead read the markdown file (but it's simpler since I can just look for code blocks directly).
…r, r=alexcrichton
made gdb pretty-printing more robust when printing uninitialized vec
made gdb pretty-printing more robust when printing uninitialized vec
I based this solution on my reading of:
https://rethinkdb.com/blog/make-debugging-easier-with-custom-pretty-printers#what-is-still-to-be-done
That post claims that there is no clean way to check for garbage pointers, and
so this PR adopts the same solution of tentatively attempting to convert a
dererence to a string, which throws a clean exception on garbage that we can
catch and recover from.
I only made the change to vec and not the other pretty printers because I wanted
to focus my effort on the simplest thing that would resolve issue rust-lang#64343. In
particular, I *considered* generalizing this fix to work on the other datatypes
in the pretty-printing support library, but I don't want to invest effort in
that until after we resolve our overall debugging support strategy; see also
issues rust-lang#60826 and rust-lang#65564.
Fixrust-lang#64343
Clarify Step Documentation
While the redesign is in progress (rust-lang#62886), clarify the purpose of replace_zero and replace_one.
First, "returning itself" is technically impossible due to the function signature of &mut self -> Self. A clone or copy operation must be used. So this is now explicitly stated in the documentation.
Second, the added docs give some guidance about the actual contract around implementation of replace_zero and replace one. Specifically, the only usage is to create a range with no more steps, by setting start to replace_one and end to replace_zero. So the only property that is actually used is `replace_one > replace_zero`. See rust-lang#42168 (comment)
The new documentation does not say that is the *only* contract, and so it should not be considered an api change. It just highlights the most important detail for implementors.
The redesign doesn't seem to be landing any time soon, so this is a stopgap measure to reduce confusion in the meantime.
@CentrilCentril added the rollup A PR which is a rollup label Nov 23, 2019
@Centril

Copy link
Copy Markdown
ContributorAuthor

@bors r+ p=4 rollup=never

@bors

bors commented Nov 23, 2019

Copy link
Copy Markdown
Collaborator

📌 Commit 8024e0d has been approved by Centril

@borsbors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Nov 23, 2019
@bors

bors commented Nov 23, 2019

Copy link
Copy Markdown
Collaborator

⌛ Testing commit 8024e0d with merge d902539...

bors added a commit that referenced this pull request Nov 23, 2019
Rollup of 4 pull requests
Successful merges:
- #65961 (add fn type_name_of_val)
- #66574 (Update tidy check for error codes testing)
- #66576 (made gdb pretty-printing more robust when printing uninitialized vec)
- #66583 (Clarify Step Documentation)
Failed merges:
r? @ghost
@bors

bors commented Nov 23, 2019

Copy link
Copy Markdown
Collaborator

☀️ Test successful - checks-azure
Approved by: Centril
Pushing d902539 to master...

@borsbors added the merged-by-bors This PR was explicitly merged by bors. label Nov 23, 2019
@bors
bors merged commit 8024e0d into rust-lang:masterNov 23, 2019
@Centril
Centril deleted the rollup-fivygwz branch November 23, 2019 07:28
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merged-by-borsThis PR was explicitly merged by bors.rollupA PR which is a rollupS-waiting-on-borsStatus: Waiting on bors to run and complete tests. Bors will change the label on completion.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@Centril@bors@lcnr@pnkfelix@Phlosioneer@GuillaumeGomez