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 #83178

Closed
wants to merge 43 commits into from

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

tblah and others added 30 commits February 21, 2021 10:58
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.
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".
Aaron1011 and others added 13 commits March 15, 2021 16:00
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.

![Listing of items in a module with some portability snippets attached to some of the items (light theme). The portability snippet has a light blue background and all of the text in it, monospace or not, is the same colour – black](https://user-images.githubusercontent.com/679122/111196363-1900f500-85b5-11eb-8f97-e283c59002a4.png)
![Listing of items in a module with some portability snippets attached to some of the items (dark theme). The portability snippet has a light blue background and all of the text in it, monospace or not, is the same colour – black](https://user-images.githubusercontent.com/679122/111196366-19998b80-85b5-11eb-9914-4d14d9d13ed3.png)

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.
@rustbot rustbot added the rollup A PR which is a rollup label Mar 16, 2021
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Mar 16, 2021

📌 Commit 1c3860b 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 16, 2021
@bors
Copy link
Contributor

bors commented Mar 16, 2021

⌛ Testing commit 1c3860b with merge a64aac3726d3f8664a74bd821d5151c3bd404658...

@rust-log-analyzer
Copy link
Collaborator

The job test-various failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
test [run-make] run-make/wasm-symbols-different-module ... ok

failures:

---- [run-make] run-make/issue-36710 stdout ----
error: make failed
status: exit code: 2
command: "make"
stdout:
stdout:
------------------------------------------
clang -ffunction-sections -fdata-sections -fPIC --target=wasm32-unknown-unknown -c -o /checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/issue-36710/issue-36710/libfoo.o foo.cpp
------------------------------------------
stderr:
------------------------------------------
/bin/dash: 1: clang: not found
/bin/dash: 1: clang: not found
make: *** [Makefile:14: /checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/issue-36710/issue-36710/libfoo.o] Error 127
------------------------------------------




failures:
    [run-make] run-make/issue-36710

test result: FAILED. 15 passed; 1 failed; 6 ignored; 0 measured; 0 filtered out; finished in 2.38s



command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/wasm32-unknown-unknown/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--rustdoc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustdoc" "--src-base" "/checkout/src/test/run-make" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make" "--stage-id" "stage2-wasm32-unknown-unknown" "--suite" "run-make" "--mode" "run-make" "--target" "wasm32-unknown-unknown" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/checkout/obj/build/x86_64-unknown-linux-gnu/llvm/build/bin/FileCheck" "--nodejs" "/node-v14.4.0-linux-x64/bin/node" "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/wasm32-unknown-unknown/native/rust-test-helpers" "--docck-python" "/usr/bin/python3" "--lldb-python" "/usr/bin/python3" "--gdb" "/usr/bin/gdb" "--llvm-version" "12.0.0-rust-1.52.0-nightly" "--llvm-components" "aarch64 aarch64asmparser aarch64codegen aarch64desc aarch64disassembler aarch64info aarch64utils aggressiveinstcombine all all-targets analysis arm armasmparser armcodegen armdesc armdisassembler arminfo armutils asmparser asmprinter avr avrasmparser avrcodegen avrdesc avrdisassembler avrinfo binaryformat bitreader bitstreamreader bitwriter cfguard codegen core coroutines coverage debuginfocodeview debuginfodwarf debuginfogsym debuginfomsf debuginfopdb demangle dlltooldriver dwarflinker engine executionengine extensions filecheck frontendopenacc frontendopenmp fuzzmutate globalisel hellonew hexagon hexagonasmparser hexagoncodegen hexagondesc hexagondisassembler hexagoninfo instcombine instrumentation interfacestub interpreter ipo irreader jitlink libdriver lineeditor linker lto mc mca mcdisassembler mcjit mcparser mips mipsasmparser mipscodegen mipsdesc mipsdisassembler mipsinfo mirparser msp430 msp430asmparser msp430codegen msp430desc msp430disassembler msp430info native nativecodegen nvptx nvptxcodegen nvptxdesc nvptxinfo objcarcopts object objectyaml option orcjit orcshared orctargetprocess passes powerpc powerpcasmparser powerpccodegen powerpcdesc powerpcdisassembler powerpcinfo profiledata remarks riscv riscvasmparser riscvcodegen riscvdesc riscvdisassembler riscvinfo runtimedyld scalaropts selectiondag sparc sparcasmparser sparccodegen sparcdesc sparcdisassembler sparcinfo support symbolize systemz systemzasmparser systemzcodegen systemzdesc systemzdisassembler systemzinfo tablegen target textapi transformutils vectorize webassembly webassemblyasmparser webassemblycodegen webassemblydesc webassemblydisassembler webassemblyinfo windowsmanifest x86 x86asmparser x86codegen x86desc x86disassembler x86info xray" "--llvm-bin-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/llvm/build/bin" "--cc" "clang" "--cxx" "clang" "--cflags" "-ffunction-sections -fdata-sections -fPIC --target=wasm32-unknown-unknown" "--ar" "ar" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"


failed to run: /checkout/obj/build/bootstrap/debug/bootstrap --stage 2 test --host= --target wasm32-unknown-unknown src/test/run-make src/test/ui src/test/mir-opt src/test/codegen-units library/core
Build completed unsuccessfully in 0:18:53

@bors
Copy link
Contributor

bors commented Mar 16, 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 Mar 16, 2021
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.