Skip to content

Rollup of 10 pull requests - #86006

Merged
bors merged 24 commits into
rust-lang:masterfrom
JohnTitor:rollup-97iuoi3
Jun 5, 2021
Merged

Rollup of 10 pull requests#86006
bors merged 24 commits into
rust-lang:masterfrom
JohnTitor:rollup-97iuoi3

Conversation

@JohnTitor

Copy link
Copy Markdown
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

jyn514and others added 24 commits May 3, 2021 17:01
- Don't duplicate DefKind -> ItemType handling; that's a good way to get bugs
- Use exhaustive match
- Add comments
This found that register_res is very wrong in at least one way: if it
registers a Res for `Variant`, it should also register one for `Field`.
But I don't know whether the one for Variant should be removed or Field
added. Maybe someone has ideas?
This commit updates wasm target specs to use `simd_types_indirect: true`
again. Long ago this was added since wasm simd types were always
translated to `v128` under-the-hood in LLVM, meaning that it didn't
matter whether that target feature was enabled or not. Now, however,
`v128` is conditionally used in codegen depending on target features
enabled, meaning that it's possible to get linker errors about different
signatures in code that correctly uses simd types. The fix is the same
as for all other platforms, which is to pass the type indirectly.
Skip where-clauses when suggesting using indirection in combination with
`?Sized` bounds on type parameters.
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
 ## User-facing changes
- Intra-doc links to primitives that currently go to rust-lang.org/nightly/std/primitive.x.html will start going to channel that rustdoc was built with. Nightly will continue going to /nightly; Beta will link to /beta; stable compilers will link to /1.52.1 (or whatever version they were built as).
- Cross-crate links from std to core currently go to /nightly unconditionally. They will start going to /1.52.0 on stable channels (but remain the same on nightly channels).
- Intra-crate links from std to std (or core to core) currently go to the same URL they are hosted at; they will continue to do so. Notably, this is different from everything else because it can preserve the distinction between /stable and /1.52.0 by using relative links.
Note that "links" includes both intra-doc links and rustdoc's own
automatically generated hyperlinks.
## Implementation changes
- Update the testsuite to allow linking to /beta and /1.52.1 in docs
- Use an html_root_url for the standard library that's dependent on the channel
This avoids linking to nightly docs on stable.
- Update rustdoc to use channel-dependent links for primitives from an
unknown crate
- Set DOC_RUST_LANG_ORG_CHANNEL from bootstrap to ensure it's in sync
- Include doc.rust-lang.org in the channel
It's confusing for these to be different, even if some of the methods
are unused.
Remove unused code from `rustc_data_structures::sync`
Found using https://github.com/est31/warnalyzer. Follow-up to rust-lang#83185.
r? `@Zoxc` cc `@oli-obk`
rustdoc: Remove `PrimitiveType::{to_url_str, as_str}`
These can easily be rewritten in terms of `as_sym`, and this avoids bugs where the two get out of sync.
I don't expect this to have a perf impact, but I'll start a perf run just in case.
…eGomez
Make match in `register_res` easier to read
- Don't duplicate DefKind -> ItemType handling; that's a good way to get bugs
- Use exhaustive match
- Add comments
This found that register_res is very wrong in at least one way: if it
registers a Res for `Variant`, it should also register one for `Field`.
But I don't know whether the one for Variant should be removed or Field
added. Maybe someone has ideas?
Found while reviewing rust-lang#84176.
rustdoc: link to stable/beta docs consistently in documentation
This is an alternative to rust-lang#84941 which fixes the problem consistently by linking to stable/beta for *all* items, not just for primitives.
## User-facing changes
- Intra-doc links to primitives that currently go to rust-lang.org/nightly/std/primitive.x.html will start going to channel that rustdoc was built with. Nightly will continue going to /nightly; Beta will link to /beta; stable compilers will link to /1.52.1 (or whatever version they were built as).
- Cross-crate links from std to core currently go to /nightly unconditionally. They will start going to /1.52.0 on stable channels (but remain the same on nightly channels).
- Intra-crate links from std to std (or core to core) currently go to the same URL they are hosted at; they will continue to do so. Notably, this is different from everything else because it can preserve the distinction between /stable and /1.52.0 by using relative links.
Note that "links" includes both intra-doc links and rustdoc's own
automatically generated hyperlinks.
## Implementation changes
- Update the testsuite to allow linking to /beta and /1.52.1 in docs
- Use an html_root_url for the standard library that's dependent on the channel
This avoids linking to nightly docs on stable.
- Update rustdoc to use channel-dependent links for primitives from an
unknown crate
- Set DOC_RUST_LANG_ORG_CHANNEL from bootstrap to ensure it's in sync
- Include doc.rust-lang.org in the channel
cc Mark-Simulacrum - I know [you were dubious about this in the past](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Rustdoc.20unconditionally.20links.20to.20nightly.20libstd.20docs/near/231223124), but I'm not quite sure why? I see this as "just a bugfix", I don't know why rustdoc should unconditionally link to nightly.
cc dtolnay who commented in rust-lang#30693:
> I would welcome a PR to solve this permanently if anyone has ideas for how. I don't believe we need an RFC.
Fixesrust-lang#30693 (note that issue is marked as feature-accepted, although I don't see where it was discussed).
…ions-boxed-dst, r=petrochenkov
Warn against boxed DST in `improper_ctypes_definitions` lint
Fixesrust-lang#85714
…tion, r=estebank
Fix suggestion for removing &mut from &mut macro!().
Fixesrust-lang#85933
Before: (Note the suggestions.)
```
error[E0308]: mismatched types
--> src/main.rs:2:21
|
2 | let _: String = &mut format!("");
| ------ ^^^^^^^^^^^^^^^^
| | |
| | expected struct `String`, found `&mut String`
| | help: consider removing the borrow: `mut format!("")`
| expected due to this
error[E0308]: mismatched types
--> src/main.rs:3:21
|
3 | let _: String = &mut (format!(""));
| ------ ^^^^^^^^^^^^^^^^^^
| | |
| | expected struct `String`, found `&mut String`
| | help: consider removing the borrow: `mut (format!(""))`
| expected due to this
```
After:
```
error[E0308]: mismatched types
--> src/main.rs:2:21
|
2 | let _: String = &mut format!("");
| ------ ^^^^^^^^^^^^^^^^
| | |
| | expected struct `String`, found `&mut String`
| | help: consider removing the borrow: `format!("")`
| expected due to this
error[E0308]: mismatched types
--> src/main.rs:3:21
|
3 | let _: String = &mut (format!(""));
| ------ ^^^^^^^^^^^^^^^^^^
| | |
| | expected struct `String`, found `&mut String`
| | help: consider removing the borrow: `format!("")`
| expected due to this
```
…workingjubilee
wasm: Make simd types passed via indirection again
This commit updates wasm target specs to use `simd_types_indirect: true`
again. Long ago this was added since wasm simd types were always
translated to `v128` under-the-hood in LLVM, meaning that it didn't
matter whether that target feature was enabled or not. Now, however,
`v128` is conditionally used in codegen depending on target features
enabled, meaning that it's possible to get linker errors about different
signatures in code that correctly uses simd types. The fix is the same
as for all other platforms, which is to pass the type indirectly.
…r=estebank
don't suggest unsized indirection in where-clauses
Skip where-clauses when suggesting using indirection in combination with
`?Sized` bounds on type parameters.
Fixesrust-lang#85943.
`@estebank` I think this doesn't conflict with your work in rust-lang#85947; please let me know if you'd like me to cherry pick it to a new branch based on yours instead.
Note that `ninja = false` goes under `[llvm]`
Addresses rust-lang#84938 (comment) - `@kornelski` does this look good?
r? `@Mark-Simulacrum` cc `@joshtriplett`
@rustbotrustbot added the rollup A PR which is a rollup label Jun 4, 2021
@JohnTitor

Copy link
Copy Markdown
MemberAuthor

@bors r+ p=10 rollup=never

@bors

bors commented Jun 4, 2021

Copy link
Copy Markdown
Collaborator

📌 Commit 062e789 has been approved by JohnTitor

@borsbors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jun 4, 2021
@bors

bors commented Jun 4, 2021

Copy link
Copy Markdown
Collaborator

⌛ Testing commit 062e789 with merge 704934d...

@bors

bors commented Jun 5, 2021

Copy link
Copy Markdown
Collaborator

☀️ Test successful - checks-actions
Approved by: JohnTitor
Pushing 704934d to master...

@borsbors added the merged-by-bors This PR was explicitly merged by bors. label Jun 5, 2021
@bors
bors merged commit 704934d into rust-lang:masterJun 5, 2021
@rustbotrustbot added this to the 1.54.0 milestone Jun 5, 2021
@JohnTitor
JohnTitor deleted the rollup-97iuoi3 branch June 5, 2021 01:13
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merged-by-borsThis PR was explicitly merged by bors.rollupA PR which is a rollupS-waiting-on-borsStatus: Waiting on bors to run and complete tests. Bors will change the label on completion.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants

@JohnTitor@bors@rustbot@jyn514@m-ou-se@alexcrichton@tlyu@marmeladema@dtolnay