Factor out several utils, add `path_def_id`
changelog: none
This is generally an effort to reduce the total number of utils. `path_def_id` is added which I believe is more "cross-cutting" and also complements `path_to_local`. Best reviewed one commit at a time.
Added:
* `path_def_id`
* `path_res`
Removed:
* `is_qpath_def_path`
* `match_any_diagnostic_items`
* `expr_path_res`
* `single_segment_path`
* `differing_macro_contexts`
* `is_ty_param_lang_item`
* `is_ty_param_diagnostic_item`
* `get_qpath_generics`
Renamed:
* `path_to_res` to `def_path_res`
* `get_qpath_generic_tys` to `qpath_generic_tys`
CC `@Jarcho` since this relates to some of your work and you may have input.
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``
Impl {Add,Sub,Mul,Div,Rem,BitXor,BitOr,BitAnd}Assign<$t> for Wrapping<$t> for rust 1.60.0
Tracking issue #93204
This is about adding basic integer operations to the `Wrapping` type:
```rust
let mut value = Wrapping(2u8);
value += 3u8;
value -= 1u8;
value *= 2u8;
value /= 2u8;
value %= 2u8;
value ^= 255u8;
value |= 123u8;
value &= 2u8;
```
Because this adds stable impls on a stable type, it runs into the following issue if an `#[unstable(...)]` attribute is used:
```
an `#[unstable]` annotation here has no effect
note: see issue #55436 <https://github.com/rust-lang/rust/issues/55436> for more information
```
This means - if I understood this correctly - the new impls have to be stabilized instantly.
Which in turn means, this PR has to kick of an FCP on the tracking issue as well?
This impl is analog to 1c0dc1810d#92356 for the `Saturating` type ``@dtolnay`` ``@Mark-Simulacrum``
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````
This adds in an enum when matching on positions which can either be types or consts.
It will default to emitting old special cased error messages for types.
use `fold_list` in `try_super_fold_with` for `SubstsRef`
split out from #93505 as this by itself is responsible for most of the perf improvements there
r? `@michaelwoerister`
These statistics are computable from the self-profile data and/or ad-hoc
collectable as needed, and in the meantime contribute to rustc bootstrap times.
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
Rollup of 2 pull requests
Successful merges:
- #90998 (Require const stability attribute on all stable functions that are `const`)
- #93489 (Mark the panic_no_unwind lang item as nounwind)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
