Rollup of 7 pull requests
Successful merges:
- #91950 (Point at type when a `static` `#[global_allocator]` doesn't `impl` `GlobalAlloc`)
- #92715 (Do not suggest char literal for zero-length strings)
- #92917 (Don't constrain projection predicates with inference vars in GAT substs)
- #93206 (Use `NtCreateFile` instead of `NtOpenFile` to open a file)
- #93732 (add fut/back compat tests for implied trait bounds)
- #93764 (⬆️ rust-analyzer)
- #93767 (deduplicate `lcnr` in mailmap)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
add fut/back compat tests for implied trait bounds
the `guard` test was tested to cause a segfault with `-Zchalk`, very nice
cc ``@nikomatsakis`` #44491#25860
Don't constrain projection predicates with inference vars in GAT substs
cc #91762
Not a fix, but a mitigation to prevent a backwards-compatible hazard where we normalize using a predicate only because it's the only one available, but shouldn't. This would constrain an inference variable which didn't really want. We already do this when selecting a projection candidate, which isn't always correct. But changing that is a problem for a different day.
Also found out that a suggestion for `await`ing a future was using the wrong substs.
r? ``@nikomatsakis``
Do not suggest char literal for zero-length strings
PR #92507 adds a hint to switch to single quotes when a char is expected and a single-character string literal is provided.
The check to ensure the string literal is one character long missed the 0-char case, and would incorrectly offer the hint.
This PR adds the missing check, and a test case to confirm the new behavior.
Fix HashMap not displaying correctly in VS debugger
The natvis to render HashMaps was not working correctly in Visual Studio
because the type names for tuples changed from `tuple$<A, B>` to
`tuple$<A,B>` (notice the missing space). WinDbg and cdb continued to
parse this type name which is why no tests in CI broke. VS however is
slightly more strict and this caused the visualizer to break.
Since we cannot test the VS debugger in CI, I'm not checking in any
test changes.
Fixes#92286
r? `@michaelwoerister`
rustdoc: Special-case macro lookups less
Previously, rustdoc had 3 fallbacks it used:
1. `resolve_macro_path`
2. `all_macros`
3. `resolve_str_path_error`
Ideally, it would only use `resolve_str_path_error`, to be consistent with other namespaces.
Unfortunately, that doesn't consider macros that aren't defined at module scope;
consider for instance
```rust
{
struct S;
macro_rules! mac { () => {} }
// `mac`'s scope starts here
/// `mac` <- `resolve_str_path_error` won't see this
struct Z;
//`mac`'s scope ends here
}
```
This changes it to only use `all_macros` and `resolve_str_path_error`, and gives
`resolve_str_path_error` precedence over `all_macros` in case there are two macros with the same
name in the same module.
This is a smaller version of https://github.com/rust-lang/rust/pull/91427.
r? `@petrochenkov`
Include all contents of first line of scraped item in Rustdoc
This fixes#93528. When scraping examples, it extends the span of the enclosing item to include all characters up to the start of the first line of the span.
r? `@camelid`
Fix hover effects in sidebar
The dark and ayu themes have a menu-like highlight on sidebar items. The light theme used to, but it was accidentally lost in the sidebar unification. The change brings back the hover effect in the light theme.
It also makes the hover effect apply consistently to all links in the sidebar, including headings.
It also simplifies the "In _path_" heading so it's one big link. The breadcrumbs are still readily available at the top of the page.
Note that a small number of headings are not linkified and so don't get the hover effect. That will be fixed with #92957.
Demo: https://rustdoc.crud.net/jsha/sidebar-hover/std/string/trait.ToString.html
r? `@GuillaumeGomez`
Fixes#93115
Add `#[no_coverage]` tests for nested functions
I was playing around a bit trying to figure out how `#[no_coverage]` behaves for nested functions and thought I might as well add this as a testcase.
The "nesting covered fn inside not covered fn" case looks pretty much as expected.
The "nesting not covered fn inside a covered fn" case however seems a bit counterintuitive.
Essentially the region of the outer function "covers" its whole lexical range. And the inner function does not generate any region at all. 🤷🏻♂️
r? `@richkadel`
Add more *-unwind ABI variants
The following *-unwind ABIs are now supported:
- "C-unwind"
- "cdecl-unwind"
- "stdcall-unwind"
- "fastcall-unwind"
- "vectorcall-unwind"
- "thiscall-unwind"
- "aapcs-unwind"
- "win64-unwind"
- "sysv64-unwind"
- "system-unwind"
cc `@rust-lang/wg-ffi-unwind`
Lazy type-alias-impl-trait
Previously opaque types were processed by
1. replacing all mentions of them with inference variables
2. memorizing these inference variables in a side-table
3. at the end of typeck, resolve the inference variables in the side table and use the resolved type as the hidden type of the opaque type
This worked okayish for `impl Trait` in return position, but required lots of roundabout type inference hacks and processing.
This PR instead stops this process of replacing opaque types with inference variables, and just keeps the opaque types around.
Whenever an opaque type `O` is compared with another type `T`, we make the comparison succeed and record `T` as the hidden type. If `O` is compared to `U` while there is a recorded hidden type for it, we grab the recorded type (`T`) and compare that against `U`. This makes implementing
* https://github.com/rust-lang/rfcs/pull/2515
much simpler (previous attempts on the inference based scheme were very prone to ICEs and general misbehaviour that was not explainable except by random implementation defined oddities).
r? `@nikomatsakis`
fixes#93411fixes#88236
The dark and ayu themes have a menu-like highlight on sidebar items. The
light theme used to, but it was accidentally lost in the sidebar
unification. The change brings back the hover effect in the light theme.
It also makes the hover effect apply consistently to all links in the
sidebar, including headings.
It also simplifies the "In _path_" heading so it's one big link. The
breadcrumbs are still readily available at the top of the page.
bootstrap: prefer using '--config' over 'RUST_BOOTSTRAP_CONFIG'
Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com>
Closes: #93725
Rleated: #92260
Rerun bootstrap's build script when RUSTC changes
Previously, rustbuild would give strange errors if you tried to reuse the same build directory under two names:
```
$ mkdir tmp && cd tmp
$ ../x.py check
Building rustbuild
Finished dev [unoptimized] target(s) in 35.27s
Checking stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
^C
$ cd ..
$ mv tmp/build build
$ ./x.py check
Building rustbuild
Compiling bootstrap v0.0.0 (/home/jnelson/rust-lang/rust/src/bootstrap)
Finished dev [unoptimized] target(s) in 11.18s
failed to execute command: "/home/jnelson/rust-lang/rust/tmp/build/x86_64-unknown-linux-gnu/stage0/bin/rustc" "--target" "x86_64-unknown-linux-gnu" "--print" "target-libdir"
error: No such file or directory (os error 2)
```
This fixes the error. Reusing the same build directory is useful if you want to test path-related things in
bootstrap itself, without having to recompile it each time.
For good measure, this also reruns the build script when PATH changes.
Use shallow clones for submodules managed by rustbuild, not just bootstrap.py
I missed this in https://github.com/rust-lang/rust/pull/89757; it made
`x.py test src/bootstrap` very slow.
Update tracking issue for `const_fn_trait_bound`
It previously pointed to #57563, the conglomerate issue for `const fn` (presumably under the feature gate `const_fn`). This tracking issue doesn't mention anything about `const_fn_trait_bound`(the only occurrence of "trait bound" is for the now-removed `?const Trait` syntax), which can be confusing to people who want to find out more about trait bounds on `const fn`s. This pull request changes the tracking issue to one meant specifically for `const_fn_trait_bound`, #93706, which can help collect information on this feature's stabilization and point users towards `const_trait_impl` if they're looking for const-in-const-contexts trait bounds.
Fixes#93679.
`````@rustbot````` modify labels +A-const-fn +F-const_trait_impl
Linkify sidebar headings for sibling items
Also adjust CSS so this doesn't produce excess padding/margin.
Note: I tried and failed to write a test with browser-UI-test. First I tried to `assert-property: (".block.mod h3 a", {"href": "index.html#macros"})`. But the `href` that gets read out is the fully-quallified URL, starting with `file:///`. That URL will differ depending on what path the test is run from, so that doesn't work.
Next I tried clicking on the appropriate sidebar link, and verifying that the appropriate heading on the next page is highlighted with the right background color. However, that also didn't work: according to browser-UI-test, the targeted heading was plain white. However, running with no-headless, I could see that it actually was yellow. I suspect this is a bug in the older version of Chromium used with browser-UI-test's bundled puppeteer, since it doesn't reproduce on latest Chrome.
Fixes#92957
Demo: https://rustdoc.crud.net/jsha/linkify-sidebar-headings/std/string/trait.ToString.html
r? ``@GuillaumeGomez``
Suggest 1-tuple parentheses on exprs without existing parens
A follow-on from #86116, split out from #90677.
This alters the suggestion to add a trailing comma to create a 1-tuple - previously we would only apply this if the relevant expression was parenthesised. We now make the suggestion regardless of parentheses, which reduces the fragility of the check (w.r.t formatting).
e.g.
```rust
let a: Option<(i32,)> = Some(3);
```
gets the below suggestion:
```rust
let a: Option<(i32,)> = Some((3,));
// ^ ^^
```
This change also improves the suggestion in other ways, such as by only making the suggestion if the types would match after the suggestion is applied and making the suggestion a multipart suggestion.
Make the pre-commit script pre-push instead
This should make it substantially less annoying, and hopefully more
people will find it useful. In particular, it will no longer run tidy
each time you run `git commit --amend` or rebase a branch.
This also warns if you have the old script in pre-commit; see the HACK
comment for details.
r? ````@Mark-Simulacrum```` cc ````@caass````
Previously, rustbuild would give strange errors if you tried to reuse the same build directory under two names:
```
$ mkdir tmp && cd tmp
$ ../x.py check
Building rustbuild
Finished dev [unoptimized] target(s) in 35.27s
Checking stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
^C
$ cd ..
$ mv tmp/build build
$ ./x.py check
Building rustbuild
Compiling bootstrap v0.0.0 (/home/jnelson/rust-lang/rust/src/bootstrap)
Finished dev [unoptimized] target(s) in 11.18s
failed to execute command: "/home/jnelson/rust-lang/rust/tmp/build/x86_64-unknown-linux-gnu/stage0/bin/rustc" "--target" "x86_64-unknown-linux-gnu" "--print" "target-libdir"
error: No such file or directory (os error 2)
```
This fixes the error. Reusing the same build directory is useful if you want to test path-things in
bootstrap itself, without having to recompile it each time.
For good measure, this also reruns the build script when PATH changes.
Previously, rustdoc had 3 fallbacks it used:
1. `resolve_macro_path`
2. `all_macros`
3. `resolve_str_path_error`
Ideally, it would only use `resolve_str_path_error`, to be consistent with other namespaces.
Unfortunately, that doesn't consider macros that aren't defined at module scope;
consider for instance
```rust
{
struct S;
macro_rules! mac { () => {} }
// `mac`'s scope starts here
/// `mac` <- `resolve_str_path_error` won't see this
struct Z;
//`mac`'s scope ends here
}
```
This changes it to only use `all_macros` and `resolve_str_path_error`, and gives
`resolve_str_path_error` precedence over `all_macros` in case there are two macros with the same
name in the same module.
This also adds a failing test case which will catch trying to remove `all_macros`.
Fix invalid special casing of the unreachable! macro
This pull-request fix an invalid special casing of the `unreachable!` macro in the same way the `panic!` macro was solved, by adding two new internal only macros `unreachable_2015` and `unreachable_2021` edition dependent and turn `unreachable!` into a built-in macro that do dispatching. This logic is stolen from the `panic!` macro.
~~This pull-request also adds an internal feature `format_args_capture_non_literal` that allows capturing arguments from formatted string that expanded from macros. The original RFC #2795 mentioned this as a future possibility. This feature is [required](https://github.com/rust-lang/rust/issues/92137#issuecomment-1018630522) because of concatenation that needs to be done inside the macro:~~
```rust
$crate::concat!("internal error: entered unreachable code: ", $fmt)
```
**In summary** the new behavior for the `unreachable!` macro with this pr is:
Edition 2021:
```rust
let x = 5;
unreachable!("x is {x}");
```
```
internal error: entered unreachable code: x is 5
```
Edition <= 2018:
```rust
let x = 5;
unreachable!("x is {x}");
```
```
internal error: entered unreachable code: x is {x}
```
Also note that the change in this PR are **insta-stable** and **breaking changes** but this a considered as being a [bug](https://github.com/rust-lang/rust/issues/92137#issuecomment-998441613).
If someone could start a perf run and then a crater run this would be appreciated.
Fixes https://github.com/rust-lang/rust/issues/92137
It previously pointed to #57563, the conglomerate issue for
`const fn` (presumably under the feature gate `const_fn`).
`const_fn_trait_bounds` weren't mentioned here, so this commit changes
its tracking issue to a new one.
Require const stability attribute on all stable functions that are `const`
This PR requires all stable functions (of all kinds) that are `const fn` to have a `#[rustc_const_stable]` or `#[rustc_const_unstable]` attribute. Stability was previously implied if omitted; a follow-up PR is planned to change the fallback to be unstable.
