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 11 pull requests #94585

Closed
wants to merge 25 commits into from
Closed

Conversation

Dylan-DPC
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

krhancoc and others added 25 commits September 9, 2021 20:05
According to https://html.spec.whatwg.org/multipage/links.html#rel-icon:

> For historical reasons, the `icon` keyword may be preceded by
> the keyword "`shortcut`".

And to https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types:

> **Warning:** The `shortcut` link type is often seen before `icon`,
> but this link type is non-conforming, ignored and **web authors
> must not use it anymore.**

While it was removed from the Rust logo case a while ago in commit
085679c ("Use theme-adaptive SVG favicon from other Rust sites"),
it is still there for the custom logo case.

Signed-off-by: Miguel Ojeda <[email protected]>
According to https://html.spec.whatwg.org/multipage/links.html#rel-icon:

> For historical reasons, the `icon` keyword may be preceded by
> the keyword "`shortcut`".

And to https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types:

> **Warning:** The `shortcut` link type is often seen before `icon`,
> but this link type is non-conforming, ignored and **web authors
> must not use it anymore.**

Signed-off-by: Miguel Ojeda <[email protected]>
This also deletes the unstable API surface area previously added to expose this
functionality on new methods rather than built into the current set.
Support can be determined by checking for the "d32" LLVM feature.
The rustdoc JSON for

```
pub fn f(_: impl Clone) {}
```

will effectively be

```
pub fn f<impl Clone: Clone>(_: impl Clone)
```

where a synthetic generic parameter called `impl Clone` with generic
trait bound `Clone` is added to the function declaration.

The generated HTML filters out these generic parameters by doing
`self.params.iter().filter(|p| !p.is_synthetic_type_param())`, because
the synthetic generic parameter is not of interest to regular users.

For the same reason, we should expose whether or not a generic parameter
is synthetic or not also in the rustdoc JSON, so that rustdoc JSON
clients can also have the option to hide synthetic generic parameters.
It isn't used anymore by rustdoc
First, this reverts the `CFLAGS`/`CXXFLAGS` of rust-lang#93918. Those flags are
already read by `cc` and populated into `Build` earlier on in the
process. We shouldn't be overriding that based on `CFLAGS`, since `cc`
also respects overrides like `CFLAGS_{TARGET}` and `HOST_CFLAGS`, which
we want to take into account.

Second, this adds the same capability to specify target-specific
versions of `LDFLAGS` as we have through `cc` for the `C*` flags:
https://github.com/alexcrichton/cc-rs#external-configuration-via-environment-variables

Note that this also necessitated an update to compiletest to treat
CXXFLAGS separately from CFLAGS.
Also remove `step` impl if `ORD_IMPL = off`
Use the new `HandleOrNull` and `HandleOrInvalid` types that were introduced
as part of [I/O safety] in a few functions in the Windows FFI bindings.

This factors out an `unsafe` block and two `unsafe` function calls in the
Windows implementation code.

And, it helps test `HandleOrNull` and `HandleOrInvalid`, which indeed turned
up a bug: `OwnedHandle` also needs to be `#[repr(transparent)]`, as it's
used inside of `HandleOrNull` and `HandleOrInvalid` which are also
`#[repr(transparent)]`.

[I/O safety]: rust-lang#87074
If you have a file in the repository root with the same name as a file
somewhere within a directory, the latter currently won't get formatted.

I have experienced this multiple times and not understood what was
happening; I finally figured out the problem today. This commit fixes
the problem.
Clarification of default socket flags

This PR outlines the decision to disable inheritance of socket objects when possible to child processes in the documentation.
rustdoc & doc: no `shortcut` for `rel="icon"`

According to https://html.spec.whatwg.org/multipage/links.html#rel-icon:

> For historical reasons, the `icon` keyword may be preceded by the keyword "`shortcut`".

And to https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types:

> **Warning:** The `shortcut` link type is often seen before `icon`, but this link type is non-conforming, ignored and **web authors must not use it anymore.**

While it was removed from the Rust logo case a while ago in commit 085679c ("Use theme-adaptive SVG favicon from other Rust sites"), it is still there for the custom logo case.

Also updated a few other instances.

Signed-off-by: Miguel Ojeda <[email protected]>
…ckh726

Remove the everybody loops pass

It isn't used anymore by rustdoc.

Split out of rust-lang#92895. There has been some previous discussion there.
Make regular stdio lock() return 'static handles

This also deletes the unstable API surface area previously added to expose this
functionality on new methods rather than built into the current set.

Closes rust-lang#86845 (tracking issue for unstable API needed without this)

r? ````@dtolnay```` to kick off T-libs-api FCP
…s-in-json, r=CraftSpider

rustdoc-json: Include GenericParamDefKind::Type::synthetic in JSON

The rustdoc JSON for

```
pub fn f(_: impl Clone) {}
```

will effectively be

```
pub fn f<impl Clone: Clone>(_: impl Clone) {}
```

where a synthetic generic parameter called `impl Clone` with generic trait bound
`Clone` is added to the function declaration.

The generated HTML filters out these generic parameters by doing
`self.params.iter().filter(|p| !p.is_synthetic_type_param())`, because the
synthetic generic paramter is not of interest to regular users.

For the same reason, we should expose whether or not a generic parameter is
synthetic or not also in the rustdoc JSON, so that rustdoc JSON clients can also
have the option to hide syntehtic generic parameters.

````@rustbot```` modify labels: +A-rustdoc-json
ARM: Only allow using d16-d31 with asm! when supported by the target

Support can be determined by checking for the "d32" LLVM feature.

r? `````````````@nagisa`````````````
…aron1011

Make Ord and PartialOrd opt-out in `newtype_index`

Part of work on rust-lang#90317. This will allow us to do

```diff
rustc_index::newtype_index! {
    /// A unique ID associated with a macro invocation and expansion.
    pub struct LocalExpnId {
        ENCODABLE = custom
        DEBUG_FORMAT = "expn{}"
+       ORD_IMPL = off
    }
}
```
…r=Mark-Simulacrum

bootstrap: correct reading of flags for llvm

First, this reverts the `CFLAGS`/`CXXFLAGS` of rust-lang#93918. Those flags are
already read by `cc` and populated into `Build` earlier on in the
process. We shouldn't be overriding that based on `CFLAGS`, since `cc`
also respects overrides like `CFLAGS_{TARGET}` and `HOST_CFLAGS`, which
we want to take into account.

Second, this adds the same capability to specify target-specific
versions of `LDFLAGS` as we have through `cc` for the `C*` flags:
https://github.com/alexcrichton/cc-rs#external-configuration-via-environment-variables
…r=joshtriplett

Use `HandleOrNull` and `HandleOrInvalid` in the Windows FFI bindings.

Use the new `HandleOrNull` and `HandleOrInvalid` types that were introduced
as part of [I/O safety] in a few functions in the Windows FFI bindings.

This factors out an `unsafe` block and two `unsafe` function calls in the
Windows implementation code.

And, it helps test `HandleOrNull` and `HandleOrInvalid`, and indeed, it
turned up a bug: `OwnedHandle` also needs to be `#[repr(transparent)]`,
as it's used inside of `HandleOrNull` and `HandleOrInvalid` which are also
`#[repr(transparent)]`.

r? `@joshtriplett`

[I/O safety]: rust-lang#87074
CTFE SwitchInt: update comment

I just wondered why this doesn't use `binary_op`.

r? `@oli-obk`
…imulacrum

Fix a bug in `x.py fmt` that prevents some files being formatted.

If you have a file in the repository root with the same name as a file
somewhere within a directory, the latter currently won't get formatted.

I have experienced this multiple times and not understood what was
happening; I finally figured out the problem today. This commit fixes
the problem.

r? `@Mark-Simulacrum`
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Mar 4, 2022
@Dylan-DPC
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Mar 4, 2022

📌 Commit 1da83f1 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 4, 2022
@aDotInTheVoid
Copy link
Member

@Dylan-DPC Can #94150 be removed from this? It (logicly) conflicts with #94009 (being merged now), see (#94150 (comment))

@Dylan-DPC
Copy link
Member Author

@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 4, 2022
@Dylan-DPC Dylan-DPC closed this Mar 4, 2022
@Dylan-DPC Dylan-DPC deleted the rollup-pyxfwak branch March 4, 2022 01:03
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-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.