Auto merge of #96003 - aswild:pr/bootstrap-subcommands-cleanup, r=jyn514
bootstrap: consolidate subcommand parsing and matching
There's several places where the x.py command names are matched as
strings, leading to some inconsistencies and opportunities for cleanup.
* Add Format, Clean, and Setup variants to builder::Kind.
* Use Kind to parse the x.py subcommand name (including aliases)
* Match on the subcommand Kind rather than strings when handling
options and help text.
* Several subcommands don't display any paths when run with `-h -v` even
though the help text indicates that they should. Fix this and refactor
so that manually keeping matches in sync isn't necessary.
This lets us clone just the parts within a `TokenTree` that need
cloning, rather than the entire thing. This is a surprisingly large
performance win, up to 4% on `async-std-1.10.0`.
Produce `CloseDelim` and pop the stack at the same time.
This makes `CloseDelim` handling more like `OpenDelim` handling, which
produces `OpenDelim` and pushes the stack at the same time. It requires
some adjustment to `parse_token_tree` now that we don't remain within
the frame after getting the `CloseDelim`.
Auto merge of #96263 - Dylan-DPC:rollup-0eofl13, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #90630 (Create real parser for search queries)
- #96193 ([fuchsia] Add implementation for `current_exe`)
- #96196 (Remove assertion that all paths in `ShouldRun` exist)
- #96228 (Fix locations for intrinsics impls and change to links)
- #96236 (Add an explicit `Span` field to `OutlivesConstraint`)
Rollup merge of #96236 - Aaron1011:constraint-debug, r=jackh726
Add an explicit `Span` field to `OutlivesConstraint`
Previously, we would retrieve the span from the `Body` using
the `locations` field. However, we may end up changing the
`locations` field when moving a constraint from a promoted
to a different body.
We now store the original `Span` in a dedication field, so that
changes to the `locations` do not affect the quality of our
diagnostics.
Rollup merge of #96193 - djkoloski:fuchsia_current_exe, r=tmandry
[fuchsia] Add implementation for `current_exe`
This implementation returns a best attempt at the current exe path. On
fuchsia, fdio will always use `argv[0]` as the process name and if it is
not set then an error will be returned. Because this is not guaranteed
to be the case, this implementation returns an error if `argv` does not
contain any elements.
Rollup merge of #90630 - GuillaumeGomez:improve-rustdoc-search, r=notriddle
Create real parser for search queries
You can test it [here](https://rustdoc.crud.net/imperio/improve-rustdoc-search/std/index.html).
This PR adds a real parser for the query engine in rustdoc. The parser is quite simple but it allows to makes query handling much easier. I added a new testsuite to ensure it works as expected and ran fuzzing checks on it for a few hours without problems.
So about the parser: as you can see in the screenshot, it handles recursive generics parsing. It also allows to set which item should use exact matching by adding double-quotes around it (look for `exact_search` in the screenshot).
Now about the query engine itself: I simplified it a lot thanks to the parsed query. It behaves mostly the same when there is only one argument, but is much more powerful when there are more than one.
When making this change, we also removed the support for multi-query.
PS: A big part of the PR is tests and test-related code. :)
Auto merge of #96187 - GuillaumeGomez:potential-intra-doc-links-filtering, r=notriddle
Prevent `<>` links to be interpreted for intra-doc links
As discussed in [this thread](https://github.com/rust-lang/rust/pull/96135#discussion_r852107956). As mentioned, the intra-doc RFC states that `<>` links shouldn't be potential intra-doc links: https://rust-lang.github.io/rfcs/1946-intra-rustdoc-links.html#no-autolinks-style.
I renamed `markdown_links` into `potential_intra_doc_markdown_links` to make it more obvious what it's doing.
Auto merge of #96253 - Dylan-DPC:rollup-87hpds5, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #93313 (Check if call return type is visibly uninhabited when building MIR)
- #96160 (Miri/interpreter debugging tweaks)
- #96167 (Replace sys/unix/weak AtomicUsize with AtomicPtr)
- #96168 (Improve AddrParseError description)
- #96206 (Use sys::unix::locks::futex* on wasm+atomics.)
- #96234 (remove_dir_all_recursive: treat ELOOP the same as ENOTDIR)
remove_dir_all_recursive: treat ELOOP the same as ENOTDIR
On older Linux kernels (I tested on 4.4, corresponding to Ubuntu 16.04), opening a symlink using `O_DIRECTORY | O_NOFOLLOW` returns `ELOOP` instead of `ENOTDIR`. We should handle it the same, since a symlink is still not a directory and needs to be `unlink`ed.
Rollup merge of #96168 - chris-morgan:AddrParseError-description-improvements, r=joshtriplett
Improve AddrParseError description
The existing description was incorrect for socket addresses, and misleading: users would see “invalid IP address syntax” and suppose they were supposed to provide an IP address rather than a socket address.
I contemplated making it two variants (IP, socket), but realised we can do still better for the IPv4 and IPv6 types, so here it is as six.
I contemplated more precise error descriptions (e.g. “invalid IPv6 socket address syntax: expected a decimal scope ID after %”), but that’s a more invasive change, and probably not worthwhile anyway.
Rollup merge of #93313 - tmiasko:uninhabited, r=tmandry
Check if call return type is visibly uninhabited when building MIR
The main motivation behind the change is to expose information about diverging
calls to the generator transform and match the precision of drop range tracking
which already understands that call expressions with visibly uninhabited types
diverges.
This change should also accept strictly more programs than before. That is
programs that were previously rejected due to errors raised by control-flow
sensitive checks in a code that is no longer considered reachable.
Auto merge of #96250 - ehuss:update-cargo, r=ehuss
Update cargo
7 commits in dba5baf4345858c591517b24801902a062c399f8..edffc4ada3d77799e5a04eeafd9b2f843d29fc23
2022-04-13 21:58:27 +0000 to 2022-04-19 17:38:29 +0000
- Document cargo-add (rust-lang/cargo#10578)
- feat: Support '-F' as an alias for '--features' (rust-lang/cargo#10576)
- Completion support for `cargo-add` (rust-lang/cargo#10577)
- Add a link to the document in the timings report (rust-lang/cargo#10492)
- feat: Import cargo-add into cargo (rust-lang/cargo#10472)
- Part 8 of RFC2906 - Keep `InheritableFields` in a `LazyCell` inside `… (rust-lang/cargo#10568)
- Part 7 of RFC2906 - Add support for inheriting `exclude` and `include` (rust-lang/cargo#10565)
Auto merge of #96135 - petrochenkov:doclink6, r=GuillaumeGomez
rustdoc: Optimize and refactor doc link resolution
One more subset of https://github.com/rust-lang/rust/pull/94857 that should bring perf improvements rather than regressions + a couple more optimizations on top of it.
It's better to read individual commits and their descriptions to understand the changes.
The `may_have_doc_links` optimization is not *very* useful here, but it's much more important for https://github.com/rust-lang/rust/pull/94857.
Remove `Eof` sanity check in `Parser::inlined_bump_with`.
A Google search of the error message fails to return any relevant
resuts, suggesting this has never occurred in practice. And removeing it
reduces instruction counts by up to 2% on some benchmarks.
Aaron Hill [Wed, 20 Apr 2022 00:53:35 +0000 (20:53 -0400)]
Add an explicit `Span` field to `OutlivesConstraint`
Previously, we would retrieve the span from the `Body` using
the `locations` field. However, we may end up changing the
`locations` field when moving a constraint from a promoted
to a different body.
We now store the original `Span` in a dedication field, so that
changes to the `locations` do not affect the quality of our
diagnostics.
The loop is there to handle a `NoDelim` open/close token. This commit
changes `TokenCursor::inlined_next` so it never returns such a token.
This is a performance win because the conditional test in `bump()` is
removed.
If the parser needs changing in the future to handle `NoDelim` tokens,
then `inlined_next()` can easily be changed to return them.
Use `true` for `open_delim`/`close_delim` in one spot.
The `DelimToken` here is `NoDelim`, which means the returned delim
tokens will just be ignored by `Parser::bump()`. This commit changes
things so the delim tokens won't be returned.
David Wood [Tue, 19 Apr 2022 02:32:30 +0000 (03:32 +0100)]
bootstrap: non-bootstrap windows split debuginfo
Temporarily, only enable split debuginfo on Windows if not building with
the boostrap compiler as there is a bug that isn't fixed in the
bootstrap compiler which would result in `thorin` being run on Windows.
Auto merge of #96224 - Dylan-DPC:rollup-h2h3j93, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #95740 (asm: Add a kreg0 register class on x86 which includes k0)
- #95813 (Remove extra space before a where clause)
- #96029 (Refactor loop into iterator; simplify negation logic.)
- #96162 (interpret: Fix writing uninit to an allocation)
- #96165 (Miri provenance cleanup)
- #96205 (Use futex locks on emscripten.)
Rollup merge of #96165 - RalfJung:miri-provenance-cleanup, r=oli-obk
Miri provenance cleanup
Reviewing https://github.com/rust-lang/rust/pull/95826 by ``@carbotaniuman`` made me realize that we could clean things up a little here.
``@carbotaniuman`` please let me know if you're okay with landing this (it will create a lot of conflicts with your PR), or if you'd prefer incorporating the ideas from this PR into yours. I think we want to end up in a situation where the function you called `ptr_reify_alloc` returns just two things, a concrete tag and an offset. Getting an `AllocId` from a concrete tag should be infallible like now. However a concrete tag and `Tag` don't have to be the same type.
Rollup merge of #96162 - RalfJung:mark-uninit, r=oli-obk
interpret: Fix writing uninit to an allocation
When calling `mark_init`, we need to also be mindful of what happens with the relocations! Specifically, when we de-init memory, we need to clear relocations in that range as well or else strange things will happen (and printing will not show the de-init, since relocations take precedence there).
Here's the Miri testcase that this fixes (requires `-Zmiri-disable-validation`):
```rust
use std::mem::MaybeUninit;
fn main() { unsafe {
let mut x = MaybeUninit::<i64>::uninit();
// Put in a ptr.
x.as_mut_ptr().cast::<&i32>().write_unaligned(&0);
// Overwrite parts of that pointer with 'uninit' through a Scalar.
let ptr = x.as_mut_ptr().cast::<i32>();
*ptr = MaybeUninit::uninit().assume_init();
// Reading this back should hence work fine.
let _c = *ptr;
} }
```
Previously this failed with
```
error: unsupported operation: unable to turn pointer into raw bytes
--> ../miri/uninit.rs:11:14
|
11 | let _c = *ptr;
| ^^^^ unable to turn pointer into raw bytes
|
= help: this is likely not a bug in the program; it indicates that the program performed an operation that the interpreter does not support
= note: inside `main` at ../miri/uninit.rs:11:14
```
Rollup merge of #96029 - IsakNyberg:error-messages-fix, r=Dylan-DPC
Refactor loop into iterator; simplify negation logic.
is_dummy should return when a non-dummy is found, but instead is iterated until completion. With some inspiration from line 323 this was refactored to a single line that returns once a single counterexample is found.
Rollup merge of #95813 - Urgau:rustdoc-where-clause-space, r=GuillaumeGomez
Remove extra space before a where clause
Remove extra space before where clause in the generated documentation.
The fix is to move the space before the break-line so that it doesn't appear visually but is still here. Removing it completely would create things like this `impl<D> Delta<D>where D: MyTrait` (missing a space before the where) which I don't think we want.
Added two regression test, first one test that the `<br>` is after the space and the second check that the `<br>` is before the spaces.
asm: Add a kreg0 register class on x86 which includes k0
Previously we only exposed a kreg register class which excludes the k0
register since it can't be used in many instructions. However k0 is a
valid register and we need to have a way of marking it as clobbered for
clobber_abi.
David Koloski [Mon, 18 Apr 2022 22:22:32 +0000 (18:22 -0400)]
[fuchsia] Add implementation for `current_exe`
This implementation returns a best attempt at the current exe path. On
fuchsia, fdio will always use `argv[0]` as the process name and if it is
not set then an error will be returned. Because this is not guaranteed
to be the case, this implementation returns an error if `argv` does not
contain any elements.
rustdoc: Optimize and refactor doc link resolution
- Cache doc link resolutions obtained early
- Cache markdown links retrieved from doc strings early
- Rename and restructure the code in early doc link resolution to be closer to #94857
asm: Add a kreg0 register class on x86 which includes k0
Previously we only exposed a kreg register class which excludes the k0
register since it can't be used in many instructions. However k0 is a
valid register and we need to have a way of marking it as clobbered for
clobber_abi.
Auto merge of #96214 - Dylan-DPC:rollup-a5b4fow, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #94493 (Improved diagnostic on failure to meet send bound on future in a foreign crate)
- #95809 (Fix typo in bootstrap.py)
- #96086 (Remove `--extern-location` and all associated code)
- #96089 (`alloc`: make `vec!` unavailable under `no_global_oom_handling`)
- #96122 (Fix an invalid error for a suggestion to add a slice in pattern-matching)
- #96142 (Stop using CRATE_DEF_INDEX outside of metadata encoding.)
Rollup merge of #96089 - ojeda:no-vec-no_global_oom_handling, r=Mark-Simulacrum
`alloc`: make `vec!` unavailable under `no_global_oom_handling`
`alloc`: make `vec!` unavailable under `no_global_oom_handling`
The `vec!` macro has 3 rules, but two are not usable under
`no_global_oom_handling` builds of the standard library
(even with a zero size):
```rust
let _ = vec![42]; // Error: requires `exchange_malloc` lang_item.
let _ = vec![42; 0]; // Error: cannot find function `from_elem`.
```
Thus those two rules should not be available to begin with.
The remaining one, with an empty matcher, is just a shorthand for
`new()` and may not make as much sense to have alone, since the
idea behind `vec!` is to enable `Vec`s to be defined with the same
syntax as array expressions. Furthermore, the documentation can be
confusing since it shows the other rules.
Thus perhaps it is better and simpler to disable `vec!` entirely
under `no_global_oom_handling` environments, and let users call
`new()` instead:
```rust
let _: Vec<i32> = vec![];
let _: Vec<i32> = Vec::new();
```
Notwithstanding this, a `try_vec!` macro would be useful, such as
the one introduced in https://github.com/rust-lang/rust/pull/95051.
If the shorthand for `new()` is deemed worth keeping on its own,
then it may be interesting to have a separate `vec!` macro with
a single rule and different, simpler documentation.
Rollup merge of #96086 - jsgf:remove-extern-location, r=davidtwco
Remove `--extern-location` and all associated code
`--extern-location` was an experiment to investigate the best way to
generate useful diagnostics for unused dependency warnings by enabling a
build system to identify the corresponding build config.
While I did successfully use this, I've since been convinced the
alternative `--json unused-externs` mechanism is the way to go, and
there's no point in having two mechanisms with basically the same
functionality.
This effectively reverts https://github.com/rust-lang/rust/pull/72603
In particular, avoid wrapping a token within `TokenTree::Token` and then
immediately matching it and returning the token within. Just return the
token immediately.
Chris Morgan [Tue, 19 Apr 2022 03:02:20 +0000 (13:02 +1000)]
Improve AddrParseError description
The existing description was incorrect for socket addresses, and
misleading: users would see “invalid IP address syntax” and suppose they
were supposed to provide an IP address rather than a socket address.
I contemplated making it two variants (IP, socket), but realised we can
do still better for the IPv4 and IPv6 types, so here it is as six.
I contemplated more precise error descriptions (e.g. “invalid IPv6
socket address syntax: expected a decimal scope ID after %”), but that’s
a more invasive change, and probably not worthwhile anyway.
Auto merge of #95379 - icewind1991:suggest-associated-type-more, r=jackh726
show suggestion to replace generic bounds with associated types in more cases
Moves the hint to replace generic parameters with associated type bounds from the "not all associated type bounds are specified"(`E0191`) to "to many generic type parameters provided"(`E0107`).
Since `E0191` is only emitted in places where all associated types must be specified (when creating `dyn` types), the suggesting is currently not shown for other generic type uses (such as in generic type bounds). With this change the suggesting is always emitted when the number of excess generic parameters matches the number of unbound associated types.
Main motivation for the change was a lack of useful suggesting when doing
projects / rust.git / log