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 9 pull requests #85452

Closed
wants to merge 29 commits into from

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

durin42 and others added 29 commits May 3, 2021 16:10
The default of --allow-unused-prefixes used to be false, but in LLVM
change 87dbdd2 (https://reviews.llvm.org/D95849) the default became
true. I'm not quite sure how we could do better here (specifically not
providing the CHECK prefix when it's not needed), but this seems to work
for now.
LinkerFlavor::Gcc does not always mean GNU ld specifically. And in the
case of at least the solaris ld in illumos, that flag is unrecognized
and will cause the linking step to fail.
This fixes the `#[must_use = ...]` on `Option::is_none` to have a working suggestion.
 # Stabilization report

 ## Summary

This stabilizes using macro expansion in key-value attributes, like so:

 ```rust
 #[doc = include_str!("my_doc.md")]
 struct S;

 #[path = concat!(env!("OUT_DIR"), "/generated.rs")]
 mod m;
 ```

See the changes to the reference for details on what macros are allowed;
see Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455)
for alternatives that were considered and rejected ("why accept no more
and no less?")

This has been available on nightly since 1.50 with no major issues.

 ## Notes

 ### Accepted syntax

The parser accepts arbitrary Rust expressions in this position, but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g., `#[doc]`).  Note that decorators and the like may be able to observe other expression forms.

 ### Expansion ordering

Expansion of macro expressions in "inert" attributes occurs after decorators have executed, analogously to macro expressions appearing in the function body or other parts of decorator input.

There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion, that can work).

 ## Test cases

 - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs
 - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs

The feature has also been dogfooded extensively in the compiler and
standard library:

- rust-lang#83329
- rust-lang#83230
- rust-lang#82641
- rust-lang#80534

 ## Implementation history

- Initial proposal: rust-lang#55414 (comment)
- Experiment to see how much code it would break: rust-lang#67121
- Preliminary work to restrict expansion that would conflict with this
feature: rust-lang#77271
- Initial implementation: rust-lang#78837
- Fix for an ICE: rust-lang#80563

 ## Unresolved Questions

~~rust-lang#83366 (comment) listed some concerns, but they have been resolved as of this final report.~~

 ## Additional Information

 There are two workarounds that have a similar effect for `#[doc]`
attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons:

```rust
macro_rules! forward_inner_docs {
    ($e:expr => $i:item) => {
        #[doc = $e]
        $i
    };
}

forward_inner_docs!(include_str!("lib.rs") => struct S {});
```

This also works for other attributes (like `#[path = concat!(...)]`).
The other is to use `doc(include)`:

```rust
 #![feature(external_doc)]
 #[doc(include = "lib.rs")]
 struct S {}
```

The first works, but is non-trivial for people to discover, and
difficult to read and maintain. The second is a strange special-case for
a particular use of the macro. This generalizes it to work for any use
case, not just including files.

I plan to remove `doc(include)` when this is stabilized. The
`forward_inner_docs` workaround will still compile without warnings, but
I expect it to be used less once it's no longer necessary.
…=petrochenkov

Stabilize extended_key_value_attributes

Closes rust-lang#44732. Closes rust-lang#78835. Closes rust-lang#82768 (by making it irrelevant).

 # Stabilization report

 ## Summary

This stabilizes using macro expansion in key-value attributes, like so:

 ```rust
 #[doc = include_str!("my_doc.md")]
 struct S;

 #[path = concat!(env!("OUT_DIR"), "/generated.rs")]
 mod m;
 ```

See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455)
for alternatives that were considered and rejected ("why accept no more and no less?")

This has been available on nightly since 1.50 with no major issues.

## Notes

### Accepted syntax

The parser accepts arbitrary Rust expressions in this position, but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g., `#[doc]`).  Note that decorators and the like may be able to observe other expression forms.

### Expansion ordering

Expansion of macro expressions in "inert" attributes occurs after decorators have executed, analogously to macro expressions appearing in the function body or other parts of decorator input.

There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion, that can work).

## Test cases

 - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs
 - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs

The feature has also been dogfooded extensively in the compiler and
standard library:

- rust-lang#83329
- rust-lang#83230
- rust-lang#82641
- rust-lang#80534

## Implementation history

- Initial proposal: rust-lang#55414 (comment)
- Experiment to see how much code it would break: rust-lang#67121
- Preliminary work to restrict expansion that would conflict with this
feature: rust-lang#77271
- Initial implementation: rust-lang#78837
- Fix for an ICE: rust-lang#80563

## Unresolved Questions

~~rust-lang#83366 (comment) listed some concerns, but they have been resolved as of this final report.~~

 ## Additional Information

 There are two workarounds that have a similar effect for `#[doc]`
attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons:

```rust
macro_rules! forward_inner_docs {
    ($e:expr => $i:item) => {
        #[doc = $e]
        $i
    };
}

forward_inner_docs!(include_str!("lib.rs") => struct S {});
```

This also works for other attributes (like `#[path = concat!(...)]`).
The other is to use `doc(include)`:

```rust
 #![feature(external_doc)]
 #[doc(include = "lib.rs")]
 struct S {}
```

The first works, but is non-trivial for people to discover, and
difficult to read and maintain. The second is a strange special-case for
a particular use of the macro. This generalizes it to work for any use
case, not just including files.

I plan to remove `doc(include)` when this is stabilized
(rust-lang#82539). The `forward_inner_docs`
workaround will still compile without warnings, but I expect it to be
used less once it's no longer necessary.
compiletest: "fix" FileCheck with --allow-unused-prefixes

The default of --allow-unused-prefixes used to be false, but in LLVM
change 87dbdd2 (https://reviews.llvm.org/D95849) the default became
true. I'm not quite sure how we could do better here (specifically not
providing the CHECK prefix when it's not needed), but this seems to work
for now.

This reduces codegen test failures against LLVM HEAD from 31 cases to 5.
…r=petrochenkov

Only pass --[no-]gc-sections if linker is GNU ld.

Fixes a regression from rust-lang#84468 where linking now fails with solaris linkers. LinkerFlavor::Gcc does not always mean GNU ld specifically. And in the case of at least the solaris ld in illumos, that flag is unrecognized and will cause the linking step to fail.

Even though removing the `is_like_solaris` branch from `gc_sections` in rust-lang#84468 made sense as `-z ignore/record` are more analogous to the `--[no-]-as-needed` flags, it inadvertently caused solaris linkers to be passed the `--gc-sections` flag. So let's just change it to be more explicit about when we pass those flags.
bootstrap: build cargo only if requested in tools

In Debian we'd like to build rustfmt and clippy alongside rustc, but we're still excluding cargo from the rustc build and doing that separately. This patch makes that possible.
…tt,GuillaumeGomez

Add abstract namespace support for Unix domain sockets

Hello! The other day I wanted to mess around with UDS in Rust and found that abstract namespaces ([unix(7)](https://man7.org/linux/man-pages/man7/unix.7.html)) on Linux still needed development. I took the approach of adding `_addr` specific public functions to reduce conflicts.

Feature name: `unix_socket_abstract`
Tracking issue: rust-lang#85410
Further context: rust-lang#42048

## Non-platform specific additions

`UnixListener::bind_addr(&SocketAddr) -> Result<UnixListener>`

`UnixStream::connect_addr(&SocketAddr) -> Result<()>`

`UnixDatagram::bind_addr(&SocketAddr) -> Result<UnixDatagram>`

`UnixDatagram::connect_addr(&SocketAddr) -> Result<()>`

`UnixDatagram::send_to_addr(&self, &[u8], &SocketAddr) -> Result<usize>`

## Platform-specific (Linux) additions

`SocketAddr::from_abstract_namespace(&[u8]) -> SocketAddr`

`SockerAddr::as_abstract_namespace() -> Option<&[u8]>`

## Example

```rust
#![feature(unix_socket_abstract)]
use std::os::unix::net::{UnixListener, SocketAddr};

fn main() -> std::io::Result<()> {
    let addr = SocketAddr::from_abstract_namespace(b"namespace")?; // Linux only
    let listener = match UnixListener::bind_addr(&addr) {
        Ok(sock) => sock,
        Err(err) => {
            println!("Couldn't bind: {:?}", err);
            return Err(err);
        }
    };
    Ok(())
}
```

## Further Details

The main inspiration for the implementation came from the [nix-rust](https://github.com/nix-rust/nix/blob/master/src/sys/socket/addr.rs#L558) crate but there are also other [historical](rust-lang@c4db068) [attempts](https://github.com/tormol/uds/blob/master/src/addr.rs#L324) with similar approaches.

A comment I did have was with this change, we now allow a `SocketAddr` to be constructed explicitly rather than just used almost as a handle for the return of `peer_addr` and `local_addr`. We could consider adding other explicit constructors (e.g. `SocketAddr::from_pathname`, `SockerAddr::from_unnamed`).

Cheers!
…eGomez

rustdoc: restore header sizes

The `<details>` toggle work changed the relationship from #main to the top-doc docblock so it was no longer a parent relationship but a great-grandparent relationship. This updates the CSS rules that set the heading sizes so they still apply.

Fixes rust-lang#85389

r? `@camelid`
Fix must_use on `Option::is_none`

This fixes the `#[must_use = ...]` on `Option::is_none` to have a working suggestion.
… r=jsha

Fix escape handling

Currently, when we press Escape while on the search results, nothing is happening, this PR fixes it.

More information: it's because in case the element doesn't exist, `hasClass` will return `null`, which coerces into `false` with the `!` comparison operator. But even if it returned `false`, it would still be an issue because if the element doesn't exist, it means it's hidden so in this case it's just as good, hence the additional check I added.

r? `@jsha`
@rustbot rustbot added the rollup A PR which is a rollup label May 18, 2021
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented May 18, 2021

📌 Commit c9c1068 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 May 18, 2021
@bors
Copy link
Contributor

bors commented May 19, 2021

⌛ Testing commit c9c1068 with merge aa1d7293bfa25fe3f76e81e5e7e38a2e9cf3f0ae...

@rust-log-analyzer
Copy link
Collaborator

The job x86_64-apple failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
      Memory: 14 GB
      Boot ROM Version: VMW71.00V.13989454.B64.1906190538
      Apple ROM Info: [MS_VM_CERT/SHA1/27d66596a61c48dd3dc7216fd715126e33f59ae7]Welcome to the Virtual Machine
      SMC Version (system): 2.8f0
      Serial Number (system): VMJLezMnzQxL

hw.ncpu: 3
hw.byteorder: 1234
hw.memsize: 15032385536
---
test src/time.rs - time::SystemTime::now (line 444) ... ok

failures:

---- src/os/./unix/net/addr.rs - os::doc::unix::net::addr::SocketAddr::as_abstract_namespace (line 204) stdout ----
error[E0599]: no function or associated item named `from_abstract_namespace` found for struct `std::os::unix::net::SocketAddr` in the current scope
  |
  |
8 |     let namespace_addr = SocketAddr::from_abstract_namespace(&namespace[..])?;


error[E0599]: no method named `as_abstract_namespace` found for struct `std::os::unix::net::SocketAddr` in the current scope
   |
   |
11 |     assert_eq!(local_addr.as_abstract_namespace(), Some(&namespace[..]));

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0599`.
For more information about this error, try `rustc --explain E0599`.
Couldn't compile the test.
---- src/os/./unix/net/addr.rs - os::doc::unix::net::addr::SocketAddr::from_abstract_namespace (line 258) stdout ----
error[E0599]: no function or associated item named `from_abstract_namespace` found for struct `std::os::unix::net::SocketAddr` in the current scope
  |
  |
7 |     let addr = SocketAddr::from_abstract_namespace(b"hidden")?;

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
For more information about this error, try `rustc --explain E0599`.
Couldn't compile the test.
---- src/os/./unix/net/datagram.rs - os::doc::unix::net::datagram::UnixDatagram::bind_addr (line 119) stdout ----
error[E0599]: no function or associated item named `from_abstract_namespace` found for struct `std::os::unix::net::SocketAddr` in the current scope
  |
  |
7 |     let addr = SocketAddr::from_abstract_namespace(b"hidden")?; // Linux only

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
For more information about this error, try `rustc --explain E0599`.
Couldn't compile the test.
---- src/os/./unix/net/datagram.rs - os::doc::unix::net::datagram::UnixDatagram::connect_addr (line 232) stdout ----
error[E0599]: no function or associated item named `from_abstract_namespace` found for struct `std::os::unix::net::SocketAddr` in the current scope
  |
  |
7 |     let addr = SocketAddr::from_abstract_namespace(b"hidden")?; // Linux only

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
For more information about this error, try `rustc --explain E0599`.
Couldn't compile the test.
---- src/os/./unix/net/datagram.rs - os::doc::unix::net::datagram::UnixDatagram::send_to_addr (line 550) stdout ----
error[E0599]: no function or associated item named `from_abstract_namespace` found for struct `std::os::unix::net::SocketAddr` in the current scope
  |
  |
7 |     let addr = SocketAddr::from_abstract_namespace(b"hidden")?;

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
For more information about this error, try `rustc --explain E0599`.
Couldn't compile the test.
---- src/os/./unix/net/listener.rs - os::doc::unix::net::listener::UnixListener::bind_addr (line 90) stdout ----
error[E0599]: no function or associated item named `from_abstract_namespace` found for struct `std::os::unix::net::SocketAddr` in the current scope
  |
  |
7 |     let addr = SocketAddr::from_abstract_namespace(b"namespace")?; // Linux only

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
For more information about this error, try `rustc --explain E0599`.
Couldn't compile the test.
---- src/os/./unix/net/stream.rs - os::doc::unix::net::stream::UnixStream::connect_addr (line 113) stdout ----
error[E0599]: no function or associated item named `from_abstract_namespace` found for struct `std::os::unix::net::SocketAddr` in the current scope
  |
  |
7 |     let addr = SocketAddr::from_abstract_namespace(b"hidden")?; // Linux only

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
---

error: test failed, to rerun pass '--doc'


command did not execute successfully: "/Users/runner/work/rust/rust/build/x86_64-apple-darwin/stage0/bin/cargo" "test" "--target" "x86_64-apple-darwin" "-Zbinary-dep-depinfo" "-j" "3" "--release" "--locked" "--color" "always" "--features" "panic-unwind backtrace profiler compiler-builtins-c" "--manifest-path" "/Users/runner/work/rust/rust/library/test/Cargo.toml" "-p" "std" "--"


failed to run: /Users/runner/work/rust/rust/build/bootstrap/debug/bootstrap --stage 2 test
Build completed unsuccessfully in 1:47:51

@bors
Copy link
Contributor

bors commented May 19, 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 May 19, 2021
@jackh726 jackh726 closed this May 19, 2021
@Dylan-DPC-zz Dylan-DPC-zz deleted the rollup-yrvjm9a branch May 19, 2021 09:53
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.