rustdoc-search: add support for nested generics
This change allows `search.js` to parse nested generics (which look `Like<This<Example>>`) and match them. It maintains the existing "bag semantics", so that the order of type parameters is ignored but the number is required to be greater than or equal to what's in the query.
For example, a function with the signature `fn read_all(&mut self: impl Read) -> Result<Vec<u8>, Error>` will match these queries:
* `Read -> Result<Vec<u8>, Error>`
* `Read -> Result<Error, Vec>`
* `Read -> Result<Vec<u8>>`
But it *does not* match `Result<Vec, u8>` or `Result<u8<Vec>>`.
Do not attempt to commute comparison and cast to codegen discriminants
The general algorithm to compute a discriminant is:
```
relative_tag = tag - niche_start
is_niche = relative_tag <= (ule) relative_max
discr = if is_niche {
cast(relative_tag) + niche_variants.start()
} else {
untagged_variant
}
```
We have an optimization branch which attempts to merge the addition and the subtraction by commuting them with the cast. We currently get this optimization wrong.
This PR takes the easiest and safest way: remove the optimization, and let LLVM handle it. (Perf may not agree with that course of action 😅)
There may be a less invasive solution, but I don't have the necessary knowledge of LLVM semantics to find it. Cranelift has the same optimization, which should be handled similarly.
cc `@nikic` and `@bjorn3` if you have a better solution.
Fixes https://github.com/rust-lang/rust/issues/110128
Rollup of 7 pull requests
Successful merges:
- #108687 (Reformulate `point_at_expr_source_of_inferred_type` to be more accurate)
- #109272 (Add Command environment variable inheritance docs)
- #109947 (Add links from `core::cmp` derives to their traits)
- #110110 (Use `Display` in top-level example for `PanicInfo`)
- #110154 (Fix typos in library)
- #110244 (Remove some unneeded imports / qualified paths)
- #110328 ([rustdoc] Add explanations for auto-disambiguation when an intra doc link is resolved to a proc-macro and a trait at the same time)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
[rustdoc] Add explanations for auto-disambiguation when an intra doc link is resolved to a proc-macro and a trait at the same time
Part of https://github.com/rust-lang/rust/issues/110111.
r? `@notriddle`
Use `Display` in top-level example for `PanicInfo`
Addresses https://github.com/rust-lang/rust/issues/110098.
This confused me as well, when I was writing a `no_std` panic handler for the first time, so here's a better top-level example.
`Display` is stable, prints the `.message()` if available, and falls back to `.payload().downcast_ref<&str>()` if the message is not available. So this example should provide strictly more information and also work for formatted panics.
The old example still exists on the `payload` method.
Add links from `core::cmp` derives to their traits
Fixes#109946
Adds intra-doc links from the `core::cmp` derives to their respective traits, and a link to their derive behaviour
`@rustbot` label +A-docs
Add Command environment variable inheritance docs
The interaction between the environment variable methods can be confusing. Specifically `env_clear` and `remove_env` have a side effects not mentioned: they disable inheriting environment variables from the parent process. I wanted to fully document this behavior as well as explain relevant edge cases in each of the `Command` env methods.
This is further confused by the return of `get_envs` which will return key/None if `remove_env` has been used, but an empty iterator if `env_clear` has been called. Or a non-empty iterator if `env_clear` was called and later explicit mappings are added. Currently there is no way (that I'm able to find) of observing whether or not the internal `env_clear=true` been toggled on the `Command` struct via its public API.
Ultimately environment variable mappings can be in one of several states:
- Explicitly set value (via `envs` / `env`) will take precedence over parent mapping
- Not explicitly set, will inherit mapping from parent
- Explicitly removed via `remove_env`, this single mapping will not inherit from parent
- Implicitly removed via `env_clear`, no mappings will inherit from parent
I tried to represent this in the relevant sections of the docs.
This is my second-ever doc PR (whoop!). I'm happy to take specific or general doc feedback. Also happy to explain the logic behind any changes or additions I made.
Reformulate `point_at_expr_source_of_inferred_type` to be more accurate
Be more accurate when deducing where along the several usages of a binding it is constrained to be some type that is incompatible with an expectation.
This also renames the method to `note_source_of_type_mismatch_constraint` because I prefer that name, though I guess I can revert that. (Also drive-by rename `note_result_coercion` -> `suggest_coercing_result_via_try_operator`, because it's suggesting, not noting!)
This PR is (probably?) best reviewed per commit, but it does regress a bit only to fix it later on, so it could also be reviewed as a whole if that makes the final results more clear.
r? `@estebank`
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
Add a stable MIR way to get the main function
This is useful for analysis tools that only analyze the code paths that a specific program actually goes through. Or for code generators built on top of stable MIR.
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
Add `tidy-alphabetical` to features in `alloc` & `std`
So that people have to keep them sorted in future, rather than just sticking them on the end where they conflict more often.
Follow-up to #110269
cc `@jyn514`
Add `tidy-alphabetical` to features in `core`
So that people have to keep them sorted in future, rather than just sticking them on the end where they conflict more often.
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`
Rollup of 9 pull requests
Successful merges:
- #109225 (Clarify that RUST_MIN_STACK may be internally cached)
- #109800 (Improve safe transmute error reporting)
- #110158 (Remove obsolete test case)
- #110180 (don't uniquify regions when canonicalizing)
- #110207 (Assemble `Unpin` candidates specially for generators in new solver)
- #110276 (Remove all but one of the spans in `BoundRegionKind::BrAnon`)
- #110279 (rustdoc: Correctly handle built-in compiler proc-macros as proc-macro and not macro)
- #110298 (Cover edge cases for {f32, f64}.hypot() docs)
- #110299 (Switch to `EarlyBinder` for `impl_subject` query)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Switch to `EarlyBinder` for `impl_subject` query
Part of the work to finish https://github.com/rust-lang/rust/issues/105779.
Several queries `X` have a `bound_X` variant that wraps the output in `EarlyBinder`. This adds `EarlyBinder` to the return type of the `impl_subject` query and removes `bound_impl_subject`.
r? ```@lcnr```
Cover edge cases for {f32, f64}.hypot() docs
Fixes#88944
The Euclidean distance is a more general way to express what these functions do, and covers the edge cases of zero and negative inputs.
Does not cover the case of non-normal input values (as the [POSIX docs](https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/) do), but the docs for the rest of the functions in these modules do not address this, I assumed it was not desired.
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``
Remove all but one of the spans in `BoundRegionKind::BrAnon`
There are only three places where `BoundRegionKind::BrAnon` uses `Some(span)` instead of `None`. Two of them are easy to remove, which this PR does.
r? ```@jackh726```
don't uniquify regions when canonicalizing
uniquifying causes a bunch of issues, most notably it causes `AliasEq(<?x as Trait<'a>>::Assoc, <?x as Trait<'a>>::Assoc)` to result in ambiguity because both `normalizes-to` paths result in ambiguity and substs equate should trivially succeed but doesn't because we uniquified `'a` to two different regions.
I originally added uniquification to make it easier to deal with requirement 6 from the dev-guide: https://rustc-dev-guide.rust-lang.org/solve/trait-solving.html#requirements
> ### 6. Trait solving must be (free) lifetime agnostic
>
> Trait solving during codegen should have the same result as during typeck. As we erase
> all free regions during codegen we must not rely on them during typeck. A noteworthy example
> is special behavior for `'static`.
cc https://github.com/rust-lang/rustc-dev-guide/pull/1671
Relying on regions being identical may cause ICE during MIR typeck, but even without this PR we can end up relying on that as type inference vars can resolve to types which contain an identical region. Let's land this and deal with any ICE that crop up as we go. Will look at this issue again before stabilization.
r? ```@compiler-errors```
Remove obsolete test case
This test case was supposed to cover issue #31109 at some point.
It never did anything, as the issue was still open at the time of its creation.
When the issue was resolved, the `issue31109` test case was created,
making the existence of this test pointless.
Improve safe transmute error reporting
This patch updates the error reporting when Safe Transmute is not possible between 2 types by including the reason.
Also, fix some small bugs that occur when computing the `Answer` for transmutability.
Clarify that RUST_MIN_STACK may be internally cached
For larger applications it's important that users set `RUST_MIN_STACK` at the start of their program because [`min_stack`](7d3e03666a/library/std/src/sys_common/thread.rs) caches the value. Not doing so can lead to their `env::set_var` call surprisingly not having any effect.
In my own testing `RUST_MIN_STACK` had no effect until I moved it to the top of `main()`. Hopefully this clarification in the docs will help others going forward.
linkat() not available in the system headers of Solaris 10
I've installed rustup on x86_64-unknown-linux-gnu and would like to use the target sparcv9-sun-solaris. For this, I have built a gcc from the source code for cross-compiling to sparcv9-sun-solaris2.10 with system headers of Solaris 10.
With the following hello word example:
main.rs:
```rust
fn main() {
println!("Hello, world!");
}
```
I had a compilation error:
```
$ rustc -v --target sparcv9-sun-solaris -C linker=/opt/cross-solaris/gcc730/bin/sparcv9-sun-solaris2.10-gcc main.rs
error: linking with `/opt/cross-solaris/gcc730/bin/sparcv9-sun-solaris2.10-gcc` failed: exit status: 1
|
= note: "/opt/cross-solaris/gcc730/bin/sparcv9-sun-solaris2.10-gcc" "-m64" "/tmp/rustcgebYgj/symbols.o" "main.main.89363361-cgu.0.rcgu.o" "main.main.89363361-cgu.1.rcgu.o" "main.main.89363361-cgu.2.rcgu.o" "main.main.89363361-cgu.3.rcgu.o" "main.main.89363361-cgu.4.rcgu.o" "main.main.89363361-cgu.5.rcgu.o" "main.csypsau9u2r8348.rcgu.o" "-Wl,-z,ignore" "-L" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib" "-Wl,-Bstatic" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libstd-fa47c8247d587714.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libpanic_unwind-5c87bbe223e6c2a3.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libobject-d484934062ff9fbb.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libmemchr-e8dbd5835abcbf43.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libaddr2line-909ad09329bde2f9.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libgimli-4d74a3be929697ac.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/librustc_demangle-47cbe1d7f7271ae1.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libstd_detect-239fd2d25fb32a00.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libhashbrown-c4a7ce45fb9dec19.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libminiz_oxide-fa6bc3d9bfb4e402.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libadler-419f5a82ddd339a3.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/librustc_std_workspace_alloc-7672b378962c11be.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libunwind-0f9e07f0a032c000.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libcfg_if-ede7757c356dfb28.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/liblibc-808d56fbc668148a.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/liballoc-784767fe059ad3fe.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/librustc_std_workspace_core-aa31d7ef0556bbe1.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libcore-81d07df07db18847.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libcompiler_builtins-313a510e63006db2.rlib" "-Wl,-Bdynamic" "-lsocket" "-lposix4" "-lpthread" "-lresolv" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lsendfile" "-llgrp" "-L" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib" "-o" "main" "-nodefaultlibs"
= note: /opt/cross-solaris/gcc730/lib/gcc/sparcv9-sun-solaris2.10/7.3.0/../../../../sparcv9-sun-solaris2.10/bin/ld: warning: -z ignore ignored.
/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libstd-fa47c8247d587714.rlib(std-fa47c8247d587714.std.5c42d2c1-cgu.0.rcgu.o): In function `std::sys::unix::fs:🔗:h3683dfbfbb4995cb':
/rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/sys/unix/fs.rs:1407: undefined reference to `linkat'
collect2: error: ld returned 1 exit status
= help: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
= note: use the `-l` flag to specify native libraries to link
= note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)
```
linkat() is not available in the system headers of Solaris 10. The hello word example works fine when I build/use rust with this PR change.
The `std` test straightforwardly can't work without file descriptors;
#99417 tracks moving it out of tests/ui.
`issue-13560.rs` requires the target to support dynamic linking.
`extern-mod-syntax` is interesting. The original test was added to check
if `extern mod` could be parsed correctly and used `extern mod std` and
an import:
138dc3048a (diff-73700e1e851b7a37bc92174635dab726124c82e5bfabbbc45b4a3c2e8e14fadd)
At some point `std::json::Object` was moved out of std to an unstable
rustc-only `extras` crate, and rather than just changing the import it
got changed to use the unstable crate. When `extras` was removed, people
assumed the test was meant to also test rustc_private and changed it to
another unstable crate rather than using something in std.
This changes the test to remove the `rustc_private` import, to allow it
to work properly when cross-compiling.
Camille GILLOT