Rollup merge of #101954 - notriddle:notriddle/location-a-first-of-type, r=GuillaumeGomez
rustdoc: remove redundant `.location a { font-weight: 500 }`
The `class="location"` element is an h2, either in the sidebar or in the mobile header. Either way, it already has `font-weight: 500`, which the link inside will inherit.
The original version of this rule was added in 9e82fc7ef9b6c8a344dd27583990b02a661af78c. At that time, the location header was rendered as a paragraph with the full path:
Rollup merge of #101923 - jsha:aux-pages-no-rustdoc-css, r=Mark-Simulacrum
Don't add rustdoc's CSS to other doc pages
This was originally added so those doc pages could use the same font files, but it turns out to be fragile. And those doc pages are just stubs that link to other pages, so they don't need fancy fonts.
Before:
After:
Michael Howell [Sat, 17 Sep 2022 22:30:23 +0000 (15:30 -0700)]
rustdoc: remove redundant `.location a { font-weight: 500 }`
The `class="location"` element is an h2, either in the sidebar or in the
mobile header. Either way, it already has `font-weight: 500`, which the link
inside will inherit.
The original version of this rule was added in 9e82fc7ef9b6c8a344dd27583990b02a661af78c. At that time, the location header
was rendered as a paragraph with the full path:
This selector was added in 959a13d53e27ca92b59798e6c6737f8249d59a2e to target a `<div class="non-exhaustive">`. With 4edcf6147912e7e4c1f13208d830c3c25e544a8c, the non-exhaustive indicator was changed to a `<details>`, and a separate selector targetting `details.non-exhaustive` was added for it, but the old selector was never removed.
Rollup merge of #101942 - Mark-Simulacrum:fix-perf, r=jyn514
Revert "Copy stage0 binaries into stage0-sysroot"
This reverts PR #101711.
The PR broke the rustc/bootstrap benchmark on rustc-perf, I believe due to the assumption that the stage0 directory exists. Fixing that by just skipping this logic might be reasonable, but I think there's a larger discussion to be had around the right behavior when we don't have a single bin/ directory (when rustc= and cargo= are specified in config.toml). I think it's potentially reasonable to put those binaries (cargo, rustc, rustfmt?) into the bin directory, but for now just want to get us back to a healthy state.
r? `@jyn514` (but would appreciate review from others as this is just a direct revert).
Rollup merge of #101826 - andrewpollack:fix-joined-without-noop, r=Mark-Simulacrum
Enforce "joined()" and "joined_with_noop()" test
Several similar tests come in the form of `joined()` and `joined_with_noop()`. In this test, the `joined()` has two calls to a noop, making it functionally equivalent to `joined_with_noop()`. This doesn't seem intended, and this PR removes those calls and changes the memory size to reflect the change
For my education, why do tests with `noop()` calls sometimes have `noop()` contributing to the size, while others do not? E.g. https://github.com/rust-lang/rust/blob/master/src/test/ui/async-await/async-fn-size-moved-locals.rs#L115 and https://github.com/rust-lang/rust/blob/master/src/test/ui/async-await/async-fn-size-moved-locals.rs#L116 have no size difference, whereas https://github.com/rust-lang/rust/blob/master/src/test/ui/async-await/async-fn-size-moved-locals.rs#L113 and https://github.com/rust-lang/rust/blob/master/src/test/ui/async-await/async-fn-size-moved-locals.rs#L114 have a size difference. Thank you!
Rollup merge of #101713 - Bryanskiy:AccessLevels, r=petrochenkov
change AccessLevels representation
Part of RFC (https://github.com/rust-lang/rust/issues/48054). This patch implements effective visibility table with basic methods and change AccessLevels table representation according to it.
Auto merge of #101946 - matthiaskrgr:rollup-jqkhsku, r=matthiaskrgr
Rollup of 9 pull requests
Successful merges:
- #101672 (array docs - advertise how to get array from slice)
- #101781 (Extend list of targets that support dyanmic linking for llvm tools)
- #101783 (Improve handing of env vars during bootstrap process)
- #101801 (add note for `layout_of` when query depth overflows)
- #101824 (rustdoc: add test cases for turning ``[Vec<T>]`` into ``[`Vec<T>`]``)
- #101861 (Update stdarch)
- #101873 (Allow building `rust-analyzer-proc-macro-srv` as a standalone tool)
- #101918 (rustdoc: clean up CSS for All Items and All Crates lists)
- #101934 (Continue migration of CSS themes)
Rollup merge of #101873 - WaffleLapkin:x-build-proc-macro-srv, r=jyn514
Allow building `rust-analyzer-proc-macro-srv` as a standalone tool
This PR allows building `rust-analyzer-proc-macro-srv` as a standalone tool via `x b proc-macro-srv-cli` (I thought that `x b rust-analyzer-proc-macro-srv` should work, but it doesn't for some reason...). Also this PR adds a copy of `rust-analyzer-proc-macro-srv` binary to `build/{triple}/{stage}/libexec/` when building `rust-analyzer-proc-macro-srv`, so that r-a can pick it up.
This is useful to make r-a (and I assume Intellij IDEA) to expand macros when using a custom, build from source toolchain.
Rollup merge of #101801 - SparrowLii:query_depth_note, r=estebank
add note for `layout_of` when query depth overflows
Fixes #101747
Added `try_find_layout_root` function to add a note for `layout_of` when query depth overflows. This would make the error in #101747 look like this:
```
error: queries overflow the depth limit!
|
note: Query depth increased by 66 when computing layout of `core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<core::option::Option<alloc::boxed::Box<alloc::string::String>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>`!
--> D:\rust-backup\parallel_rust\query_depth.rs:40:1
|
40 | fn main() {
| ^^^^^^^^^
Rollup merge of #101783 - chriswailes:env-vars, r=jyn514
Improve handing of env vars during bootstrap process
This CL modifies the handing of env vars during the bootstrap process in two ways:
1. Replaces '-' characters with '_' characters in target names to increase compatibility with different shells
2. Passes Stage0 snapshot compiler related env vars to early invocations of Cargo
Rollup merge of #101672 - idigdoug:array_try_into, r=Mark-Simulacrum
array docs - advertise how to get array from slice
On my first Rust project, I spent more time than I care to admit figuring out how to efficiently get an array from a slice. Update the array documentation to explain this a bit more clearly.
(As a side note, it's a bit unfortunate that get-array-from-slice is only available via trait since that means it can't be used from const functions yet.)
This selector was added in 959a13d53e27ca92b59798e6c6737f8249d59a2e to
target a `<div class="non-exhaustive">`. With 4edcf6147912e7e4c1f13208d830c3c25e544a8c, the non-exhaustive indicator was
changed to a `<details>`, and a separate selector targetting
`details.non-exhaustive` was added for it, but the old selector was never
removed.
Auto merge of #101938 - Dylan-DPC:rollup-6vlohhs, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #93628 (Stabilize `let else`)
- #98441 (Implement simd_as for pointers)
- #101790 (Do not suggest a placeholder to const and static without a type)
- #101807 (Disallow defaults on type GATs)
- #101915 (doc: fix redirected link in `/index.html`)
- #101931 (doc: Fix a typo in `Rc::make_mut` docstring)
Outside of desugaring I'm not aware of any differences between the implementation and the RFC. The chosen desugaring has been changed from the RFC's [original](https://rust-lang.github.io/rfcs/3137-let-else.html#reference-level-explanations). You can read a detailed discussion of the implementation history of it in `@cormacrelf` 's [summary](https://github.com/rust-lang/rust/pull/93628#issuecomment-1041143670) in this thread, as well as the [followup](https://github.com/rust-lang/rust/pull/93628#issuecomment-1046598419). Since that followup, further changes have happened to the desugaring, in #98574, #99518, #99954. The later changes were mostly about the drop order: On match, temporaries drop in the same order as they would for a `let` declaration. On mismatch, temporaries drop before the `else` block.
* [`ui/let-else/let-else-bool-binop-init.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/let-else-bool-binop-init.rs) to ensure that no lazy boolean expressions (using `&&` or `||`) are allowed in the expression, as the RFC mandates.
* [`ui/let-else/let-else-brace-before-else.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/let-else-brace-before-else.rs) to ensure that no `}` directly preceding the `else` is allowed in the expression, as the RFC mandates.
* [`ui/let-else/let-else-check.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/let-else-check.rs) to ensure that `#[allow(...)]` attributes added to the entire `let` statement apply for the `else` block.
* [`ui/let-else/let-else-irrefutable.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/let-else-irrefutable.rs) to ensure that the `irrefutable_let_patterns` lint fires.
* [`ui/let-else/let-else-missing-semicolon.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/let-else-missing-semicolon.rs) to ensure the presence of semicolons at the end of the `let` statement.
* [`ui/let-else/let-else-non-diverging.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/let-else-non-diverging.rs) to ensure the `else` block diverges.
* [`ui/let-else/let-else-run-pass.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/let-else-run-pass.rs) to ensure the feature works in some simple test case settings.
* [`ui/let-else/let-else-scope.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/let-else-scope.rs) to ensure the bindings created by the outer `let` expression are not available in the `else` block of it.
* [`ui/let-else/issue-89960.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/issue-89960.rs) as a regression test for the ICE-on-error bug #89960 . Later in 102b9125e1cefbb8ed8408d2db3f9f7d5afddbf0 this got removed in favour of more comprehensive tests.
* [`ui/let-else/let-else-if.rs`](https://github.com/rust-lang/rust/blob/1.58.1/src/test/ui/let-else/let-else-if.rs) to test for the improved error message that points out that `let else if` is not possible.
* [`ui/let-else/let-else-allow-unused.rs`](https://github.com/rust-lang/rust/blob/1.61.0/src/test/ui/let-else/let-else-allow-unused.rs) as a regression test for #89807, to ensure that `#[allow(...)]` attributes added to the entire `let` statement apply for bindings created by the `let else` pattern.
* [`ui/let-else/let-else-non-copy.rs`](https://github.com/rust-lang/rust/blob/1.61.0/src/test/ui/let-else/let-else-non-copy.rs) to ensure that a copy is performed out of non-copy wrapper types. This mirrors `if let` behaviour. The test case bases on rustc internal changes originally meant for #89933 but then removed from the PR due to the error prior to the improvements of #89841.
* [`ui/let-else/let-else-source-expr-nomove-pass.rs `](https://github.com/rust-lang/rust/blob/1.61.0/src/test/ui/let-else/let-else-source-expr-nomove-pass.rs) to ensure that while there is a move of the binding in the successful case, the `else` case can still access the non-matching value. This mirrors `if let` behaviour.
* [`ui/let-else/let-else-ref-bindings.rs`](https://github.com/rust-lang/rust/blob/1.61.0/src/test/ui/let-else/let-else-ref-bindings.rs) and [`ui/let-else/let-else-ref-bindings-pass.rs `](https://github.com/rust-lang/rust/blob/1.61.0/src/test/ui/let-else/let-else-ref-bindings-pass.rs) to check `ref` and `ref mut` keywords in the pattern work correctly and error when needed.
* [`ui/let-else/let-else-deref-coercion-annotated.rs`](https://github.com/rust-lang/rust/blob/1.61.0/src/test/ui/let-else/let-else-deref-coercion-annotated.rs) and [`ui/let-else/let-else-deref-coercion.rs`](https://github.com/rust-lang/rust/blob/1.61.0/src/test/ui/let-else/let-else-deref-coercion.rs) to check deref coercions.
#### Added since this stabilization report was originally written (2022-02-09)
* [`ui/let-else/let-else-destructuring.rs`](https://github.com/rust-lang/rust/blob/1.63.0/src/test/ui/let-else/let-else-destructuring.rs) to give a nice error message if an user tries to do an assignment with a (possibly refutable) pattern and an `else` block, like asked for in #93995.
* [`ui/let-else/let-else-allow-in-expr.rs`](https://github.com/rust-lang/rust/blob/1.61.0/src/test/ui/let-else/let-else-allow-in-expr.rs) to test whether `#[allow(unused_variables)]` works in the expr, as well as its non presence, as well as putting it on the entire `let else` *affects* the expr, too. This was adding a missing test as pointed out by the stabilization report.
* Expansion of `ui/let-else/let-else-allow-unused.rs` and `ui/let-else/let-else-check.rs` to ensure that non-presence of `#[allow(unused)]` does issue the unused lint. This was adding a missing test case as pointed out by the stabilization report.
* [`ui/let-else/let-else-slicing-error.rs`](https://github.com/rust-lang/rust/blob/1.61.0/src/test/ui/let-else/let-else-slicing-error.rs), a regression test for #92069, which got fixed without addition of a regression test. This resolves a missing test as pointed out by the stabilization report.
* [`src/test/ui/async-await/async-await-let-else.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui/async-await/async-await-let-else.rs) to test the interaction of async/await with `let else`
* [`src/test/ui/let-else/let-else-temporary-lifetime.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui/let-else/let-else-temporary-lifetime.rs) as a (partial) regression test for #98672
* [`src/test/ui/let-else/let-else-temp-borrowck.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui/let-else/let-else-temporary-lifetime.rs) as a regression test for #93951
* Extension of `src/test/ui/let-else/let-else-temporary-lifetime.rs` to include a partial regression test for #98672 (especially regarding `else` drop order)
* Extension of `src/test/ui/let-else/let-else-temporary-lifetime.rs` to include a partial regression test for #93951, similar to `let-else-temp-borrowck.rs`
* Extension of `src/test/ui/let-else/let-else-temporary-lifetime.rs` to include a program that can now be compiled thanks to borrow checker implications of #99518
* [`src/test/ui/let-else/issue-100103.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui/let-else/issue-100103.rs), as a regression test for #100103, to ensure that there is no ICE when doing `Err(...)?` inside else blocks.
* [`src/test/ui/let-else/let-else-then-diverge.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui/let-else/let-else-then-diverge.rs), to verify that there is no unreachable code error with the current desugaring.
* [`src/test/ui/let-else/issue-94176.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui/let-else/issue-94176.rs), to make sure that a correct span is emitted for a missing trailing expression error. Regression test for #94176.
* [src/test/ui/unpretty/pretty-let-else.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/unpretty/pretty-let-else.rs), as a regression test to ensure pretty printing works for `let else` (this bug surfaced in many different ways)
* [`src/test/ui/let-else/let-else-temporary-lifetime.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui/let-else/let-else-temporary-lifetime.rs) extended to contain & borrows as well, as this was identified as an earlier issue with the desugaring: https://github.com/rust-lang/rust/issues/98672#issuecomment-1200196921
* [`src/test/ui/let-else/let-else-drop-order.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui/let-else/let-else-drop-order.rs) a matrix based test for various drop order behaviour of `let else`. Especially, it verifies equality of `let` and `let else` drop orders, [resolving](https://github.com/rust-lang/rust/pull/93628#issuecomment-1238498468) a [stabilization blocker](https://github.com/rust-lang/rust/pull/93628#issuecomment-1055738523).
* [`src/test/ui/let-else/issue-99975.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui/let-else/issue-99975.rs) as a regression test for the ICE #99975.
Added by this PR:
* `ui/let-else/let-else.rs`, a simple run-pass check, similar to `ui/let-else/let-else-run-pass.rs`.
### Things not currently tested
* ~~The `#[allow(...)]` tests check whether allow works, but they don't check whether the non-presence of allow causes a lint to fire.~~ → *test added by e7730dcb7eb29a10ee73f269f4dc6e9d606db0da*
* ~~There is no `#[allow(...)]` test for the expression, as there are tests for the pattern and the else block.~~ → *test added by e7730dcb7eb29a10ee73f269f4dc6e9d606db0da*
* ~~`let-else-brace-before-else.rs` forbids the `let ... = {} else {}` pattern and there is a rustfix to obtain `let ... = ({}) else {}`. I'm not sure whether the `.fixed` files are checked by the tooling that they compile. But if there is no such check, it would be neat to make sure that `let ... = ({}) else {}` compiles.~~ → *test added by e7730dcb7eb29a10ee73f269f4dc6e9d606db0da*
* ~~#92069 got closed as fixed, but no regression test was added. Not sure it's worth to add one.~~ → *test added by 5bd71063b3810d977aa376d1e6dd7cec359330cc*
* ~~consistency between `let else` and `if let` regarding lifetimes and drop order: https://github.com/rust-lang/rust/pull/93628#issuecomment-1055738523~~ → *test added by 2d8460ef43d902f34ba2133fe38f66ee8d2fdafc*
Edit: they are all tested now.
### Possible future work / Refutable destructuring assignments
[RFC 2909](https://rust-lang.github.io/rfcs/2909-destructuring-assignment.html) specifies destructuring assignment, allowing statements like `FooBar { a, b, c } = foo();`.
As it was stabilized, destructuring assignment only allows *irrefutable* patterns, which before the advent of `let else` were the only patterns that `let` supported.
So the combination of `let else` and destructuring assignments gives reason to think about extensions of the destructuring assignments feature that allow refutable patterns, discussed in #93995.
A naive mapping of `let else` to destructuring assignments in the form of `Some(v) = foo() else { ... };` might not be the ideal way. `let else` needs a diverging `else` clause as it introduces new bindings, while assignments have a default behaviour to fall back to if the pattern does not match, in the form of not performing the assignment. Thus, there is no good case to require divergence, or even an `else` clause at all, beyond the need for having *some* introducer syntax so that it is clear to readers that the assignment is not a given (enums and structs look similar). There are better candidates for introducer syntax however than an empty `else {}` clause, like `maybe` which could be added as a keyword on an edition boundary:
```Rust
let mut v = 0;
maybe Some(v) = foo(&v);
maybe Some(v) = foo(&v) else { bar() };
```
Further design discussion is left to an RFC, or the linked issue.
Michael Howell [Sat, 17 Sep 2022 03:37:17 +0000 (20:37 -0700)]
Rollup merge of #101921 - est31:bootstrap_cfg_rustdoc, r=joshtriplett
Pass --cfg=bootstrap for rustdoc for proc_macro crates
This PR does three things:
* First, it passes --cfg=bootstrap on stage 0 for rustdoc invocations on proc_macro crates. This mirrors what we do already for rustc invocations of those, and is needed because cargo doesn't respect RUSTFLAGS or RUSTDOCFLAGS when confronted with a proc macro.
* Second, it marks the bootstrap config variable as expected. This is needed both on later stages where it's not set, but also on stage 0, where it is set.
* Third, it adjusts the comment in the rustc wrapper to better reflect the reason why we set the bootstrap variable as
expected: due to recent changes, setting it as expected
is also required even if the cfg variable is passed: ebf4cc361e0d0f11a25b42372bd629953365d17e .
This rule originated in 7669f04fb0ddc3d71a1fb44dc1c5c00a6564ae99, to override the default, limited line-width that makes sense for prose, but doesn't make sense for code (which typically uses hard-wrapped lines):
Michael Howell [Sat, 17 Sep 2022 03:37:16 +0000 (20:37 -0700)]
Rollup merge of #101898 - GuillaumeGomez:rm-unused-css, r=notriddle
Remove some unused CSS rules
Since we now have list of items for the ones on the page, we don't need the CSS rules anymore in the sidebar (`.sidebar a`). As for the `.content` ones, they are used to highlight the items in the page (for definitions and others). Surprisingly enough, `method` and `tymethod` are all replaced with `fnname`.
I also used this opportunity to remove these rules in `ayu.css`:
This was originally added so those doc pages could use the same font
files, but it turns out to be fragile. And those doc pages are just
stubs that link to other pages, so they don't need fancy fonts.
Chris Wailes [Tue, 13 Sep 2022 23:13:43 +0000 (16:13 -0700)]
Improve handing of env vars during bootstrap process
This CL modifies the handing of env vars during the bootstrap process in
two ways:
1. Replaces '-' characters with '_' characters in target names to
increase compatibility with different shells
2. Passes Stage0 snapshot compiler related env vars to early invocations
of Cargo
Pass --cfg=bootstrap for rustdoc for proc_macro crates
This commit does three things:
* First, it passes --cfg=bootstrap on stage 0 for rustdoc
invocations on proc_macro crates. This mirrors what we
do already for rustc invocations of those, and is needed
because cargo doesn't respect RUSTFLAGS or RUSTDOCFLAGS
when confronted with a proc macro.
* Second, it marks the bootstrap config variable as expected.
This is needed both on later stages where it's not set,
but also on stage 0, where it is set.
* Third, it adjusts the comment in the rustc wrapper to better
reflect the reason why we set the bootstrap variable as
expected: due to recent changes, setting it as expected
is also required even if the cfg variable is passed: ebf4cc361e0d0f11a25b42372bd629953365d17e .
This rule originated in 7669f04fb0ddc3d71a1fb44dc1c5c00a6564ae99, to
override the default, limited line-width that makes sense for prose, but
doesn't make sense for code (which typically uses hard-wrapped lines):
Rollup merge of #101877 - notriddle:notriddle/block, r=Dylan-DPC
rustdoc: remove no-op CSS `.block { padding: 0 }`
This rule was changed in 8fb1250aba8135679463351a3813c04ae45bf311 from the original version that had a non-zero padding. It's not needed, because it's not overriding anything that would've given `.block` a padding.
Rollup merge of #101868 - notriddle:notriddle/short-links-jump-to-definition, r=GuillaumeGomez
rustdoc: use more precise URLs for jump-to-definition links
As an example, this cuts down <https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_middle/ty/mod.rs.html> by about 11%.
$ du -h new_mod.rs.html old_mod.rs.html
296K new_mod.rs.html
332K old_mod.rs.html
Like https://github.com/rust-lang/rust/pull/83237, but separate code since source links have a different URL structure.
Related to [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/RFC.20for.20.22jump.20to.20definition.22.20feature/near/299029786) and [the jump-to-definition pre-RFC](https://github.com/GuillaumeGomez/rfcs/pull/1).
Rollup merge of #101813 - GuillaumeGomez:check-css-variables, r=notriddle
Extend CSS check to CSS variables
This PR is a bit big because the first commit is a rewrite of the CSS parser to something a bit simpler which still allows to get easily access to CSS properties name.
The other two are about adding tests and adding the CSS variables check.
This check was missing because we are relying more and more on CSS variables rather than CSS selectors in themes.
Rollup merge of #101494 - jsha:notable-traits-right, r=GuillaumeGomez
rustdoc mobile: move notable traits to return type
These were originally on the left, but were moved to the return type in c90fb7185a5febb00b7f8ccb49abceacd41bad6e. The CSS rule for mobile did not get updated at the time, so updating it now.
check_missing_items.py was a python script that checked rustdoc json output to make sure all the Id's referenced existed in the JSON index. This PR replaces that with a rust binary (`jsondoclint`) that does the same thing.
### Motivation
1. Easier to change when `rustdoc-json-types` changes, as `jsondoclint` uses the types directly.
2. Better Errors:
- Multiple Errors can be emited for a single crate
- Errors can say where in JSON they occored
```
2:2889:408 not in index or paths, but refered to at '.index."2:2888:104".inner.items[0]'
2:2890:410 not in index or paths, but refered to at '.index."2:2888:104".inner.items[1]'
```
3. Catches more bugs.
- Because matches are exaustive, all posible variants considered for enums
- All Id's checked
- Has already found #101770, #101199 and #100973
- Id type is also checked, so the Id's in a structs fields can only be field items.
4. Allows the possibility of running from `rustdoc::json`, which we should do in a crator run at some point.
Rollup merge of #101753 - oli-obk:tait_closure_args, r=compiler-errors
Prefer explict closure sig types over expected ones
fixes #100800
Previously we only checked that given closure arguments are equal to expected closure arguments, but now we choose the given closure arguments for the signature that is used when type checking the closure body, and keep the other signature for the type of the closure as seen outside of it.
Rollup merge of #101738 - dpaoliello:linkname, r=petrochenkov
Fix `#[link kind="raw-dylib"]` to respect `#[link_name]`
Issue Details:
When using `#[link kind="raw-dylib"]` (#58713), the Rust compiler ignored any `#[link_name]` attributes when generating the import library and so the resulting binary would fail to link due to missing symbols.
Fix Details:
Use the name from `#[link_name]` if present when generating the `raw-dylib` import library, otherwise default back to the actual symbol name.
projects / rust.git / log