Stabilize version output for rustc and rustdoc #13816
Conversation
| if matches.opt_present("version") { | ||
| match matches.opt_str("version").as_ref().map(|s| s.as_slice()) { | ||
| None | ||
| | Some("short") => version(binary, VdShort), |
There was a problem hiding this comment.
We probably don't need a short option. I think I'd prefer just matching on Some("verbose") and None. You can pass a bool to version function.
There was a problem hiding this comment.
actually, given that this match is duplicated in rustdoc. What about moving it into the version function?
|
Thanks for stabbing this. Could you please add a |
|
Sure thing. Thanks for your help. Any idea why the build failed? I ran a |
|
The travis failure looks like a fluke. The travis boxes often don't have quite enough memory to run the test suite, and it looks like that build suffered from a similar problem. |
|
I think @alexcrichton closed this PR accidentally. |
|
Oops, sorry! I didn't even realize... |
|
No problem. Thanks for reopening @flaper87 . |
|
This updated patch includes @pnkfelix suggestion (partially) of outputting debug and optimize flags, but it only does that for the rustc crate. I couldn't find a good alternative to include those flags for all the crates, the only decent option I saw was to embed the flags in each crate, then include each one directly in librustc....but I couldn't think of a reason to mix crate flags. Is that a common scenario? Also, running |
|
@anemator Thanks for working on this. Can you change the way |
|
This may also wish to include #14162 in that |
|
Oh, yeah. Replacing |
|
I went ahead and reopened and approved #14162. |
|
@brson Thanks for the tip on adding a macro. I chose to do it with the BUILD_FLAGS variable initially to avoid potentially inserting user info into the binary via CFG_ARGS and to be certain of the builder's debug and optimize flags since they can be enabled in multiple ways (not necessarily via CFG_ARGS). However, I removed BUILD_FLAGS for now since as mentioned, it may be flaky and there also seem to be differing opinions as to what should be included. |
|
Sorry for the delay. |
|
No problem. For reference, the normal format is and the verbose is |
|
@brson @alexcrichton can this patch be approved? Is it blocked by something else? |
|
I canceled the build to get the rollup running (this PR is in the rollup). I have also marked this PR with |
…, r=Veykril Postfix adjustment hints # Basic Description This PR implements "postfix" adjustment hints:  They are identical to normal adjustment hints, but are rendered _after_ the expression. E.g. `expr.*` instead of `*expr`. ~~This mirrors "postfix deref" feature that I'm planning to eventually propose to the compiler.~~ # Motivation The advantage of being postfix is that you need to add parentheses less often:   This is because a lot of "reborrow" hints are caused by field access or method calls, both of which are postfix and have higher "precedence" than prefix `&` and `*`. Also IMHO it just looks nicer and it's more clear what is happening (order of operations). # Modes However, there are some cases where postfix hints need parentheses but prefix don't (for example `&x` being turned into `(&x).*.*.&` or `&**&x`). This PR allows users to choose which look they like more. There are 4 options (`rust-analyzer.inlayHints.expressionAdjustmentHints.mode` setting): - `prefix` — always use prefix hints (default, what was used before that PR) - `postfix` — always use postfix hints - `prefer_prefix` — try to minimize number of parentheses, breaking ties in favor of prefix - `prefer_postfix` — try to minimize number of parentheses, breaking ties in favor of postfix Comparison of all modes:     # Edge cases Where are some rare cases where chain hints weirdly interact with adjustment hints, for example (note `SourceAnalyzer.&`):  This is pre-existing, you can get the same effect with prefix hints (`SourceAnalyzer)`). ---- Another weird thing is this:  Here `.&` is a hint and `?` is written in the source code. It looks like `?` is part of the hint because `?.` is ligature in my font. IMO this is a bug in vscode, but still worth mentioning (I'm also too lazy to report it there...). # Fixed bugs I've used the "needs parens" API and this accidentally fixed a bug with parens around `as`, see the test diff: ```diff,rust let _: *const u32 = &mut 0u32 as *mut u32; //^^^^^^^^^^^^^^^^^^^^^<mut-ptr-to-const-ptr> + //^^^^^^^^^^^^^^^^^^^^^( + //^^^^^^^^^^^^^^^^^^^^^) ... let _: *const u32 = &mut 0u32 as *mut u32; //^^^^^^^^^^^^^^^^^^^^^<mut-ptr-to-const-ptr> + //^^^^^^^^^^^^^^^^^^^^^( + //^^^^^^^^^^^^^^^^^^^^^) ``` # Changelog changelog feature Add an option to make adjustment hints (aka reborrow hints) postfix changelog fix Fix placement of parentheses around `as` casts for adjustment hints
Fixes #13582