Rollup of 7 pull requests
Successful merges:
- #103682 (Stabilize rustdoc `--test-run-directory`)
- #106249 (Create "suggested tests" tool in `rustbuild`)
- #110047 (Add link to `collections` docs to `extend` trait)
- #110269 (Add `tidy-alphabetical` to features in `core`)
- #110292 (Add `tidy-alphabetical` to features in `alloc` & `std`)
- #110305 (rustdoc-search: use ES6 `Map` and `Set` where they make sense)
- #110315 (Add a stable MIR way to get the main function)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc-search: use ES6 `Map` and `Set` where they make sense
Since all supported browsers now support these classes, and rustdoc has started using them in some places, it might as well use them everywhere it makes sense (because, as [MDN's Map page] says, it "performs better in scenarios involving frequent additions and removals of key-value pairs.").
[MDN's Map page]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map
Create "suggested tests" tool in `rustbuild`
Not the claimed person in #97339 but:
I've done a very rough implementation of this feature in-tree. I'm very new to `rustc` development (outside of docs) so some help would be greatly appreciated. The UI of this new subcommand obviously will change and I need some mentoring with the `--run` flag.
r? ```@jyn514```
fix running Miri tests
This partially reverts https://github.com/rust-lang/rust/pull/108659 to fix https://github.com/rust-lang/rust/issues/110102: the Miri test runner does not support any flags, they are interpreted as filters instead which leads to no tests being run.
I have not checked any of the other test runners for whether they are having any trouble with these flags.
Cc `@pietroalbini` `@Mark-Simulacrum` `@jyn514`
rustdoc: Correctly handle built-in compiler proc-macros as proc-macro and not macro
Part of https://github.com/rust-lang/rust/issues/110111.
There were actually one issue split in two parts:
* Compiler built-in proc-macro were incorrectly considered as macros and not proc-macros.
* Re-exports of compiler built-in proc-macros were considering them as macros.
Both issues can be fixed by looking at the `MacroKind` variant instead of just relying on information extracted later on.
r? ``@fmease``
resolve: Pre-compute non-reexport module children
Instead of repeating the same logic by walking HIR during metadata encoding.
The only difference is that we are no longer encoding `macro_rules` items, but we never currently need them as a part of this list. They can be encoded separately if this need ever arises.
`module_reexports` is also un-querified, because I don't see any reasons to make it a query, only overhead.
Update cargo
4 commits in 7bf43f028ba5eb1f4d70d271c2546c38512c9875..84b7041fd2745ee6b3b4a150314f81aabb78e6b2
2023-04-10 16:01:41 +0000 to 2023-04-13 20:08:40 +0000
- Stabilize `cargo logout` (rust-lang/cargo#11950)
- Add more information to HTTP errors to help with debugging. (rust-lang/cargo#11878)
- Use registry.default for login/logout (rust-lang/cargo#11949)
- Change -C to be unstable (rust-lang/cargo#11960)
Add inline assembly support for m68k
I believe this should be correct, to the extent I understand the logic around inline assembly. M68k is fairly straightforward here, other than having separate address registers.
Fix `--extend-css` option
Fixes#110002.
The file was generated in the wrong folder so I moved it into `static.files` as it made more sense to have there instead of changing the path in the templates.
I also added a GUI test to ensure that this option won't break unexpectedly again.
Fix x check --stage 1 when download-ci-llvm=false
Bootstrap tries to avoid building LLVM unless it needs to; in particular we only build it for `x build`, not `x check`. Unfortunately, the check forgot about existence of stages - it would break if you used `x check --stage 1`:
```
= note: /usr/bin/ld: cannot find -lPolly: No such file or directory
/usr/bin/ld: cannot find -lPollyISL: No such file or directory
```
Fix it to work for stage 1.
I recommend reading this commit-by-commit; the first one makes a bunch of whitespace changes but otherwise doesn't change the logic.
Replace rustdoc-ui/{c,z}-help tests with a stable run-make test
This make rustdoc resilient to changes in the debugging options while still testing that it matches rustc.
Fixes https://github.com/rust-lang/rust/issues/109391.
Rollup of 8 pull requests
Successful merges:
- #110153 (Fix typos in compiler)
- #110165 (rustdoc: use CSS `overscroll-behavior` instead of JavaScript)
- #110175 (Symbol cleanups)
- #110203 (Remove `..` from return type notation)
- #110205 (rustdoc: make settings radio and checks thicker, less contrast)
- #110222 (Improve the error message when forwarding a matched fragment to another macro)
- #110237 (Split out a separate feature gate for impl trait in associated types)
- #110241 (tidy: Issue an error when UI test limits are too high)
Failed merges:
- #110218 (Remove `ToRegionVid`)
r? `@ghost`
`@rustbot` modify labels: rollup
tidy: Issue an error when UI test limits are too high
cc #73494
Ensuring the limits are as low as they need to be will make it harder to accidentally add new tests to any large directories
Split out a separate feature gate for impl trait in associated types
in https://github.com/rust-lang/rust/issues/107645 it was decided that we'll take a new route for type alias impl trait. The exact route isn't clear yet, so while I'm working on implementing some of these proposed changes (e.g. in https://github.com/rust-lang/rust/pull/110010) to be able to experiment with them, I will also work on stabilizing another sugar version first: impl trait in associated types. Similarly I'll look into creating feature gates for impl trait in const/static types.
This PR does nothing but split the feature gate, so that you need to enable a different feature gate for
```rust
impl Trait for Type {
type Assoc = impl SomeTrait;
}
```
than what you need for `type Foo = impl SomeTrait;`
Fixes the desktop scrolling weirdness mentioned in
https://github.com/rust-lang/rust/pull/98775#issuecomment-1182575603
As described in the MDN page for this property:
* The current Firefox ESR is 102, and the first Firefox version
to support this feature is 59.
* The current Chrome version 112, and the first version to support
this is 63.
* Edge is described as having a minor bug in `none` mode, but we
use `contain` mode anyway, so it doesn't matter.
* Safari 16, released September 2022, is the last browser to
add this feature, and is also the oldest version we officially
support.
This is very dependent on subjectivity and what screen you use,
but this change makes the radio buttons' outer circle less ugly.
This is because I could see the pixels very clearly, thanks to the
very thin line and high contrast. This change makes both less
severe, giving your browser's antialiasing algorithm more to
work with. Since it's thicker, lowering the contrast shouldn't
impact visibility.
Instead of repeating the same logic by walking HIR during metadata encoding.
The only difference is that we are no longer encoding `macro_rules` items, but we never currently need them as a part of this list.
They can be encoded separately if this need ever arises.
`module_reexports` is also un-querified, because I don't see any reasons to make it a query, only overhead.
rustdoc: remove redundant expandSection code from main.js
This functionality is already tested in `hash-item-expansion.goml`, and was implemented twice:
* First, in code that ran at load time and at hash change: 917cdd295d
* Later, the hash change event handler was itself run at load time, and the code handling both cases diverged in implementation, though their behavior still matches pretty well: f66a331335
Fix `x test ui --target foo` when download-rustc is enabled
Previously, we would never build the target std, only the host std:
```
; x t tests/ui/attributes --target wasm32-unknown-unknown
Building bootstrap
Finished dev [unoptimized] target(s) in 0.02s
Building stage0 library artifacts (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.08s
Building tool compiletest (stage0)
Finished release [optimized] target(s) in 0.09s
Check compiletest suite=ui mode=ui (x86_64-unknown-linux-gnu -> wasm32-unknown-unknown)
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { depth: 0, inner: Io { path: Some("/home/jyn/src/rust2/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/wasm32-unknown-unknown/lib"), err: Os { code: 2, kind: NotFound, message: "No such file or directory" } } }', src/tools/compiletest/src/main.rs:842:31
```
Helps with https://github.com/rust-lang/rust/issues/81930.
Pass host linker to compiletest.
Tests marked `// force-host` were using the default linker, even if a custom linker was configured in config.toml.
This change adds a new flag, --host-linker, to compiletest, and renames --linker to --target-linker.
Initial support for loongarch64-unknown-linux-gnu
Hi, We hope to add a new port in rust for LoongArch.
LoongArch intro
LoongArch is a RISC style ISA which is independently designed by Loongson
Technology in China. It is divided into two versions, the 32-bit version (LA32)
and the 64-bit version (LA64). LA64 applications have application-level
backward binary compatibility with LA32 applications. LoongArch is composed of
a basic part (Loongson Base) and an expanded part. The expansion part includes
Loongson Binary Translation (LBT), Loongson VirtualiZation (LVZ), Loongson SIMD
EXtension (LSX) and Loongson Advanced SIMD EXtension(LASX).
Currently the LA464 processor core supports LoongArch ISA and the Loongson
3A5000 processor integrates 4 64-bit LA464 cores. LA464 is a four-issue 64-bit
high-performance processor core. It can be used as a single core for high-end
embedded and desktop applications, or as a basic processor core to form an
on-chip multi-core system for server and high-performance machine applications.
Documentations:
ISA:
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html
ABI:
https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
More docs can be found at:
https://loongson.github.io/LoongArch-Documentation/README-EN.html
Since last year, we have locally adapted two versions of rust, rust1.41 and rust1.57, and completed the test locally.
I'm not sure if I'm submitting all the patches at once, so I split up the patches and here's one of the commits
bors
