Rollup of 11 pull requests #83178
Closed
Rollup of 11 pull requests #83178
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Resolves rust-lang#78911 The target's linker was used but rustc wasn't told to build for that target (instead defaulting to the host). This led to the host instead of the target getting tested and to the linker getting inappropriate arguments.
The test assumes it can run target binaries on the host. This not true for riscv64 CI (or for other platforms using remote-test-server).
When we cross compile, some things (and their documentation) are built for the host (e.g. rustc), while others (and their documentation) are built for the target. This generated documentation will have broken links between documentation for different platforms e.g. between rustc and cargo.
There is no reason for this function to return an object, since it is always used for getting at the name anyhow. It's used in the inner loop for some popular functions, so we want to avoid allocating in it.
Every time splice() is called, another temporary object is created. This version, which uses plain objects as a sort of Hash Bag, should only produce one temporary object each time it's called.
Basically, it doesn't make sense to generate those things every time you search. That generates a bunch of stuff for the GC to clean up, when, if the user wanted to do another search, it would just need to re-do it again.
Co-authored-by: Guillaume Gomez <guillaume1.gomez@gmail.com>
This should have negligible effect on time, but it cuts about 1MiB off of resident memory usage.
There's no reason for it to be a string, since it's only used for de-duplicating the results arrays anyhow.
This basically fixes a search bug introduced by earlier changes.
Otherwise on systems where Arial is not available the system will fallback to a serif font, rather than a sans-serif one. This is especially relevant on acessibility-conscious setups (such as is mine) that have web-fonts disabled and a limited set of fonts available on the system.
This better matches the appearance of this kind of snippet in the full item view and is less jarring to read due to repeated foreground-background changes.
This prevents older git versions to change the "line endings".
We now lint on *any* use of `procedural-masquerade` crate. While this crate still exists, its main reverse dependency (`cssparser`) no longer depends on it. Any crates still depending off should stop doing so, as it only exists to support very old Rust versions. If a crate actually needs to support old versions of rustc via `procedural-masquerade`, then they'll just need to accept the warning until we remove it entirely (at the same time as the back-compat hack). The latest version of `procedural-masquerade` does not work with the latest rustc, but trying to check for the version seems like more trouble than it's worth. While working on this, I realized that the `proc-macro-hack` check was never actually doing anything. The corresponding enum variant in `proc-macro-hack` is named `Value` or `Nested` - it has never been called `Input`. Due to a strange Crater issue, the Crater run that tested adding this did *not* end up testing it - some of the crates that would have failed did not actually have their tests checked, making it seem as though the `proc-macro-hack` check was working. The Crater issue is being discussed at https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Nearly.20identical.20Crater.20runs.20processed.20a.20crate.20differently/near/230406661 Despite the `proc-macro-hack` check not actually doing anything, we haven't gotten any reports from users about their build being broken. I went ahead and removed it entirely, since it's clear that no one is being affected by the `proc-macro-hack` regression in practice.
Riscv64linux Test fixes Get tests passing again using the riscv64gc-unknown-linux-gnu docker image. Test with ``` src/ci/docker/run.sh riscv64gc-linux ``` ## linkcheck Linkcheck tests that interdocument links in the documentation are correct. Some interdocument links go between rustc and tools (such as rustdoc and cargo). When cross compiling, rustc is built for the host while some tools are built for the target. This goes for the documentation too. Because of this, links in the rustc documentation reffering to cargo or rustdoc documentation look broken. This issue is worked around by disabling linkcheck for cross compilation builds. ## run-make tests rust-lang#78911 seems to happen because `--target` was not passed to `rustc`, but the target linker was specified, causing the target linker to be called with options intended for the host. Resolves rust-lang#78911 In a separate issue, `issue-36710` was trying to run a binary built for the target on the host system. This will not work for any platform using `remote-test-server`/`client` (such as riscv64). I don't know of a way of skipping those platforms specifically, so I set this test to skip only on riscv64 for now.
Allow rustdoc to handle asm! of foreign architectures This allows rustdoc to process code containing `asm!` for architectures other than the current one. Since this never reaches codegen, we just replace target-specific registers and register classes with a dummy one. Fixes rust-lang#82869
Update `Vec` docs Fix typos/nits in `Vec` docs
…, r=GuillaumeGomez rustdoc: reduce GC work during search
More precise spans for HIR paths `Ty::assoc_item` is lowered to `<Ty>::assoc_item` in HIR, but `Ty` got span from the whole path. This PR fixes that, and adjusts some diagnostic code that relied on `Ty` having the whole path span. This is a pre-requisite for rust-lang#82868 (we cannot report suggestions like `Tr::assoc` -> `<dyn Tr>::assoc` with the current imprecise spans). r? ``@estebank``
Do not insert impl_trait_in_bindings opaque definitions twice. The reference to the item already appears inside the `OpaqueDef`. It does not need to be repeated as a statement.
…GuillaumeGomez Fall-back to sans-serif if Arial is not available Otherwise on systems where Arial is not available the UA will fallback to a serif font, rather than a sans-serif one. This is especially relevant on acessibility-conscious setups (such as is mine) that have web-fonts disabled and a limited set of fonts available on the system. r? ``@GuillaumeGomez`` cc ``@jsha``
…d, r=GuillaumeGomez No background for code in portability snippets This better matches the appearance of this kind of snippet in the full item view and is less jarring to read due to repeated foreground-background changes.   There should be no observable changes to the ayu theme.
…erives, r=petrochenkov Deprecate RustcEncodable and RustcDecodable. We can't remove the `RustcEncodable` and `RustcDecodable` derive macros from the prelude, but we can deprecate them.
Specify *.woff2 files as binary This prevents older git versions to change the "line endings". Fixes rust-lang#83159.
…e, r=petrochenkov Extend `proc_macro_back_compat` lint to `procedural-masquerade` We now lint on *any* use of `procedural-masquerade` crate. While this crate still exists, its main reverse dependency (`cssparser`) no longer depends on it. Any crates still depending off should stop doing so, as it only exists to support very old Rust versions. If a crate actually needs to support old versions of rustc via `procedural-masquerade`, then they'll just need to accept the warning until we remove it entirely (at the same time as the back-compat hack). The latest version of `procedural-masquerade` does not work with the latest rustc, but trying to check for the version seems like more trouble than it's worth. While working on this, I realized that the `proc-macro-hack` check was never actually doing anything. The corresponding enum variant in `proc-macro-hack` is named `Value` or `Nested` - it has never been called `Input`. Due to a strange Crater issue, the Crater run that tested adding this did *not* end up testing it - some of the crates that would have failed did not actually have their tests checked, making it seem as though the `proc-macro-hack` check was working. The Crater issue is being discussed at https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Nearly.20identical.20Crater.20runs.20processed.20a.20crate.20differently/near/230406661 Despite the `proc-macro-hack` check not actually doing anything, we haven't gotten any reports from users about their build being broken. I went ahead and removed it entirely, since it's clear that no one is being affected by the `proc-macro-hack` regression in practice.
|
@bors r+ rollup=never p=5 |
|
📌 Commit 1c3860b has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit 1c3860b with merge a64aac3726d3f8664a74bd821d5151c3bd404658... |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
Vecdocs #83072 (UpdateVecdocs)proc_macro_back_compatlint toprocedural-masquerade#83168 (Extendproc_macro_back_compatlint toprocedural-masquerade)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup