-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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 8 pull requests #83566
Rollup of 8 pull requests #83566
Commits on Mar 22, 2021
-
Configuration menu - View commit details
-
Copy full SHA for 6e9cea9 - Browse repository at this point
Copy the full SHA 6e9cea9View commit details
Commits on Mar 23, 2021
-
Android has the ability to supply an abort message [1]. This message is automatically included in the debug trace, which helps debugging [2]. Modify panic_abort to populate this message before calling abort(). [1] https://android.googlesource.com/platform/bionic/+/master/libc/include/android/set_abort_message.h [2] https://source.android.com/devices/tech/debug/native-crash
Configuration menu - View commit details
-
Copy full SHA for f41d0a4 - Browse repository at this point
Copy the full SHA f41d0a4View commit details
Commits on Mar 24, 2021
-
rustdoc: Use diagnostics for error when including sources
This error probably almost never happens, but we should still use the diagnostic infrastructure. My guess is that the error was added back before rustdoc used the rustc diagnostic infrastructure (it was all `println!` and `eprintln!` back then!) and since it likely rarely occurs and this code doesn't change that much, no one thought to transition it to using diagnostics. Note that the old error was actually a warning (it didn't stop the rest of doc building). It seems very unlikely that this would fail without the rest of the doc build failing, so it makes more sense for it to be a hard error. The error looks like this: error: failed to render source code for `src/test/rustdoc/smart-punct.rs`: "bar": foo --> src/test/rustdoc/smart-punct.rs:3:1 | 3 | / #![crate_name = "foo"] 4 | | 5 | | //! This is the "start" of the 'document'! How'd you know that "it's" ... 6 | | //! ... | 22 | | //! I say "don't smart-punct me -- please!" 23 | | //! ``` | |_______^ I wasn't sure how to trigger the error, so to create that message I temporarily made rustdoc always emit it. That's also why it says "bar" and "foo" instead of a real error message. Note that the span of the diagnostic starts at line 3 because line 1 of that file is a (non-doc) comment and line 2 is a blank line.
Configuration menu - View commit details
-
Copy full SHA for 3d8ce0a - Browse repository at this point
Copy the full SHA 3d8ce0aView commit details
Commits on Mar 25, 2021
-
ExitStatus: print "exit status: {}" rather than "exit code: {}"
Proper Unix terminology is "exit status" (vs "wait status"). "exit code" is imprecise on Unix and therefore unclear. (As far as I can tell, "exit code" is correct terminology on Windows.) This new wording is unfortunately inconsistent with the identifier names in the Rust stdlib. It is the identifier names that are wrong, as discussed at length in eg https://doc.rust-lang.org/nightly/std/process/struct.ExitStatus.html https://doc.rust-lang.org/nightly/std/os/unix/process/trait.ExitStatusExt.html Unfortunately for API stability reasons it would be a lot of work, and a lot of disruption, to change the names in the stdlib (eg to rename `std::process::ExitStatus` to `std::process::ChildStatus` or something), but we should fix the message output. Many (probably most) readers of these messages about exit statuses will be users and system administrators, not programmers, who won't even know that Rust has this wrong terminology. So I think the right thing is to fix the documentation (as I have already done) and, now, the terminology in the implementation. This is a user-visible change to the behaviour of all Rust programs which run Unix subprocesses. Hopefully no-one is matching against the exit status string, except perhaps in tests. Signed-off-by: Ian Jackson <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 11e40ce - Browse repository at this point
Copy the full SHA 11e40ceView commit details
Commits on Mar 26, 2021
-
Configuration menu - View commit details
-
Copy full SHA for addc51a - Browse repository at this point
Copy the full SHA addc51aView commit details -
Configuration menu - View commit details
-
Copy full SHA for 5ac917d - Browse repository at this point
Copy the full SHA 5ac917dView commit details
Commits on Mar 27, 2021
-
Always preserve
None
-delimited groups in a capturedTokenStream
Previously, we would silently remove any `None`-delimiters when capturing a `TokenStream`, 'flattenting' them to their inner tokens. This was not normally visible, since we usually have `TokenKind::Interpolated` (which gets converted to a `None`-delimited group during macro invocation) instead of an actual `None`-delimited group. However, there are a couple of cases where this becomes visible to proc-macros: 1. A cross-crate `macro_rules!` macro has a `None`-delimited group stored in its body (as a result of being produced by another `macro_rules!` macro). The cross-crate `macro_rules!` invocation can then expand to an attribute macro invocation, which needs to be able to see the `None`-delimited group. 2. A proc-macro can invoke an attribute proc-macro with its re-collected input. If there are any nonterminals present in the input, they will get re-collected to `None`-delimited groups, which will then get captured as part of the attribute macro invocation. Both of these cases are incredibly obscure, so there hopefully won't be any breakage. This change will allow more agressive 'flattenting' of nonterminals in rust-lang#82608 without losing `None`-delimited groups.
Configuration menu - View commit details
-
Copy full SHA for f94360f - Browse repository at this point
Copy the full SHA f94360fView commit details -
Configuration menu - View commit details
-
Copy full SHA for 229d199 - Browse repository at this point
Copy the full SHA 229d199View commit details -
format macro argument parsing fix
When the character next to `{}` is "shifted" (when mapping a byte index in the format string to span) we should avoid shifting the span end index, so first map the index of `}` to span, then bump the span, instead of first mapping the next byte index to a span (which causes bumping the end span too much). Regression test added. Fixes rust-lang#83344
Configuration menu - View commit details
-
Copy full SHA for 5b9bac2 - Browse repository at this point
Copy the full SHA 5b9bac2View commit details -
Configuration menu - View commit details
-
Copy full SHA for 77a5fe9 - Browse repository at this point
Copy the full SHA 77a5fe9View commit details -
Rollup merge of rust-lang#81469 - tweksteen:android_set_message, r=m-…
…ou-se android: set abort message Android has the ability to supply an abort message [1]. This message is automatically included in the debug trace, which helps debugging [2]. Modify panic_abort to populate this message before calling abort(). [1] https://android.googlesource.com/platform/bionic/+/master/libc/include/android/set_abort_message.h [2] https://source.android.com/devices/tech/debug/native-crash
Configuration menu - View commit details
-
Copy full SHA for caa1c0e - Browse repository at this point
Copy the full SHA caa1c0eView commit details -
Rollup merge of rust-lang#82626 - lcnr:encode_with_shorthandb, r=este…
…bank update array missing `IntoIterator` msg fixes rust-lang#82602 r? ``@estebank`` do you know whether we can use the expr span in `rustc_on_unimplemented`? The label isn't too great rn
Configuration menu - View commit details
-
Copy full SHA for c572f14 - Browse repository at this point
Copy the full SHA c572f14View commit details -
Rollup merge of rust-lang#82993 - camelid:source-use-diag, r=jyn514
rustdoc: Use diagnostics for error when including sources This error probably almost never happens, but we should still use the diagnostic infrastructure. My guess is that the error was added back before rustdoc used the rustc diagnostic infrastructure (it was all `println!` and `eprintln!` back then!) and since it likely rarely occurs and this code doesn't change that much, no one thought to transition it to using diagnostics. Note that the old error was actually a warning (it didn't stop the rest of doc building). It seems very unlikely that this would fail without the rest of the doc build failing, so it makes more sense for it to be a hard error. The error looks like this: error: failed to render source code for `src/test/rustdoc/smart-punct.rs`: "bar": foo --> src/test/rustdoc/smart-punct.rs:3:1 | 3 | / #![crate_name = "foo"] 4 | | 5 | | //! This is the "start" of the 'document'! How'd you know that "it's" ... 6 | | //! ... | 22 | | //! I say "don't smart-punct me -- please!" 23 | | //! ``` | |_______^ I wasn't sure how to trigger the error, so to create that message I temporarily made rustdoc always emit it. That's also why it says "bar" and "foo" instead of a real error message. Note that the span of the diagnostic starts at line 3 because line 1 of that file is a (non-doc) comment and line 2 is a blank line.
Configuration menu - View commit details
-
Copy full SHA for 0a8441f - Browse repository at this point
Copy the full SHA 0a8441fView commit details -
Rollup merge of rust-lang#83130 - clarfonthey:escape, r=m-ou-se
escape_ascii take 2 The previous PR, rust-lang#73111 was closed for inactivity; since I've had trouble in the past reopening closed PRs, I'm just making a new one. I'm still running the tests locally but figured I'd open the PR in the meantime. Will fix whatever errors show up so we don't have to wait again for this. r? ``@m-ou-se``
Configuration menu - View commit details
-
Copy full SHA for 07d6ce4 - Browse repository at this point
Copy the full SHA 07d6ce4View commit details -
Rollup merge of rust-lang#83348 - osa1:issue83344, r=jackh726
format macro argument parsing fix When the character next to `{}` is "shifted" (when mapping a byte index in the format string to span) we should avoid shifting the span end index, so first map the index of `}` to span, then bump the span, instead of first mapping the next byte index to a span (which causes bumping the end span too much). Regression test added. Fixes rust-lang#83344 --- r? ``@estebank``
Configuration menu - View commit details
-
Copy full SHA for 09a1a8c - Browse repository at this point
Copy the full SHA 09a1a8cView commit details -
Rollup merge of rust-lang#83462 - ijackson:exitstatus-message-wording…
…, r=joshtriplett ExitStatus: print "exit status: {}" rather than "exit code: {}" on unix Proper Unix terminology is "exit status" (vs "wait status"). "exit code" is imprecise on Unix and therefore unclear. (As far as I can tell, "exit code" is correct terminology on Windows.) This new wording is unfortunately inconsistent with the identifier names in the Rust stdlib. It is the identifier names that are wrong, as discussed at length in eg https://doc.rust-lang.org/nightly/std/process/struct.ExitStatus.html https://doc.rust-lang.org/nightly/std/os/unix/process/trait.ExitStatusExt.html Unfortunately for API stability reasons it would be a lot of work, and a lot of disruption, to change the names in the stdlib (eg to rename `std::process::ExitStatus` to `std::process::ChildStatus` or something), but we should fix the message output. Many (probably most) readers of these messages about exit statuses will be users and system administrators, not programmers, who won't even know that Rust has this wrong terminology. So I think the right thing is to fix the documentation (as I have already done) and, now, the terminology in the implementation. This is a user-visible change to the behaviour of all Rust programs which run Unix subprocesses. Hopefully no-one is matching against the exit status string, except perhaps in tests.
Configuration menu - View commit details
-
Copy full SHA for b62de54 - Browse repository at this point
Copy the full SHA b62de54View commit details -
Rollup merge of rust-lang#83526 - klensy:lazy-too, r=petrochenkov
lazily calls some fns Replaced some fn's with it's lazy variants.
Configuration menu - View commit details
-
Copy full SHA for 0556e2d - Browse repository at this point
Copy the full SHA 0556e2dView commit details -
Rollup merge of rust-lang#83548 - Aaron1011:capture-none-delims, r=pe…
…trochenkov Always preserve `None`-delimited groups in a captured `TokenStream` Previously, we would silently remove any `None`-delimiters when capturing a `TokenStream`, 'flattenting' them to their inner tokens. This was not normally visible, since we usually have `TokenKind::Interpolated` (which gets converted to a `None`-delimited group during macro invocation) instead of an actual `None`-delimited group. However, there are a couple of cases where this becomes visible to proc-macros: 1. A cross-crate `macro_rules!` macro has a `None`-delimited group stored in its body (as a result of being produced by another `macro_rules!` macro). The cross-crate `macro_rules!` invocation can then expand to an attribute macro invocation, which needs to be able to see the `None`-delimited group. 2. A proc-macro can invoke an attribute proc-macro with its re-collected input. If there are any nonterminals present in the input, they will get re-collected to `None`-delimited groups, which will then get captured as part of the attribute macro invocation. Both of these cases are incredibly obscure, so there hopefully won't be any breakage. This change will allow more agressive 'flattenting' of nonterminals in rust-lang#82608 without losing `None`-delimited groups.
Configuration menu - View commit details
-
Copy full SHA for a2c1a9e - Browse repository at this point
Copy the full SHA a2c1a9eView commit details