Skip to content
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

Closed
wants to merge 18 commits into from

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

clarfonthey and others added 18 commits March 22, 2021 15:43
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
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.
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]>
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.
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
…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
…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
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.
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``
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``
…, 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.
lazily calls some fns

Replaced some fn's with it's lazy variants.
…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.
@rustbot rustbot added the rollup A PR which is a rollup label Mar 27, 2021
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Mar 27, 2021

📌 Commit a2c1a9e has been approved by Dylan-DPC

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Mar 27, 2021
@bors
Copy link
Contributor

bors commented Mar 27, 2021

⌛ Testing commit a2c1a9e with merge 685ddabc825f39c1cbce1461cc656ec81c586b66...

@rust-log-analyzer
Copy link
Collaborator

The job dist-android failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
   Compiling hashbrown v0.11.0
   Compiling miniz_oxide v0.4.0
[RUSTC-TIMING] rustc_std_workspace_alloc test:false 0.032
[RUSTC-TIMING] panic_abort test:false 0.215
rustc exited with signal: 11
error: could not compile `panic_abort`
Caused by:
Caused by:
  process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustc --crate-name panic_abort --edition=2018 library/panic_abort/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -C codegen-units=1 -C debuginfo=1 -C metadata=7a1100c4e225862e -C extra-filename=-7a1100c4e225862e --out-dir /checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/arm-linux-androideabi/release/deps --target arm-linux-androideabi -C linker=/android/ndk/arm-14/bin/arm-linux-androideabi-clang -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/arm-linux-androideabi/release/deps -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/release/deps --extern alloc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/arm-linux-androideabi/release/deps/liballoc-845ee545bbe426da.rmeta --extern cfg_if=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/arm-linux-androideabi/release/deps/libcfg_if-9aa210456737e445.rmeta --extern compiler_builtins=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/arm-linux-androideabi/release/deps/libcompiler_builtins-e88007c334f43f3a.rmeta --extern core=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/arm-linux-androideabi/release/deps/libcore-474b270852438406.rmeta --extern libc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/arm-linux-androideabi/release/deps/liblibc-8d79781e4daf5d39.rmeta -Zmacro-backtrace '-Clink-args=-Wl,-rpath,$ORIGIN/../lib' -Zsave-analysis -Cprefer-dynamic -Cembed-bitcode=yes -Z binary-dep-depinfo -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/arm-linux-androideabi/release/build/compiler_builtins-4d7b48d5a2760790/out` (exit code: 254)
[RUSTC-TIMING] panic_unwind test:false 0.239
[RUSTC-TIMING] hashbrown test:false 0.762
[RUSTC-TIMING] alloc test:false 3.212
[RUSTC-TIMING] miniz_oxide test:false 2.523
[RUSTC-TIMING] miniz_oxide test:false 2.523
[RUSTC-TIMING] core test:false 16.513
[RUSTC-TIMING] gimli test:false 5.020
[RUSTC-TIMING] object test:false 9.645
error: build failed
command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "arm-linux-androideabi" "-Zbinary-dep-depinfo" "-j" "16" "--release" "--locked" "--color" "always" "--features" "panic-unwind backtrace profiler compiler-builtins-c" "--manifest-path" "/checkout/library/test/Cargo.toml" "--message-format" "json-render-diagnostics"
failed to run: /checkout/obj/build/bootstrap/debug/bootstrap dist --host= --target arm-linux-androideabi,armv7-linux-androideabi,thumbv7neon-linux-androideabi,i686-linux-android,aarch64-linux-android,x86_64-linux-android
Build completed unsuccessfully in 0:13:33

@bors
Copy link
Contributor

bors commented Mar 27, 2021

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 27, 2021
@JohnTitor
Copy link
Member

The failure is caused by #81469, closing.

@JohnTitor JohnTitor closed this Mar 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.