Fix `x test rust-installer` when `cargo` is set to a relative path
Previously, this would give an error because the shell script had a different working directory:
```
test: basic_install
$ sh /home/jyn/src/rust/src/tools/rust-installer/gen-installer.sh --image-dir=/home/jyn/src/rust/src/tools/rust-installer/test/image1 --work-dir=/home/jyn/src/rust/build/x86_64-unknown-linux-gnu/test/rust-installer/workdir --output-dir=/home/jyn/src/rust/build/x86_64-unknown-linux-gnu/test/rust-installer/outdir
/home/jyn/src/rust/src/tools/rust-installer/gen-installer.sh: 15: ../rust3/build/host/stage2-tools-bin/cargo: not found
TEST FAILED!
```
Allow everyone to set the beta-nominated label
It is allowed both in cargo and clippy's triagebot.toml, and nomination does not automatically mean that the PR will be backported.
[compiletest] Add more test ignore reasons, `needs-` validation, and improved error messages
This PR makes more improvements to the way compiletest ignoring headers are handled, following up on #108905:
* Human-readable ignore reasons have been added for the remaining ignore causes (`needs-*` directives, `*llvm*` directives, and debugger version directives). All ignored tests should now have a human-readable reason.
* The code handling `needs-*` directives has been refactored, and now invalid `needs-*` directive emit errors like `ignore-*` and `only-*`.
* All errors are now displayed at startup (with line numbers) rather than just the first error of the first file.
This PR is best reviewed commit-by-commit.
r? `@ehuss`
This test was ignored long ago in
https://github.com/rust-lang/rust/pull/20578/ when the syntax for
closures was changed.
The current status is that a closure with an explicit `!` return type
will trigger the `unreachable_code` lint which appears to be the
original intent of the test
(https://github.com/rust-lang/rust/pull/16836). A closure without a
return type won't trigger the lint since the `!` type isn't inferred
(AFAIK). This restores the test to its original form.
Temporarily disable the jobserver-error test
This test is failing randomly on CI. We don't have a handle on what might be causing it, so disable it for now to reduce disruption.
cc https://github.com/rust-lang/rust/issues/110321
Previously, this would give an error because the shell script had a
different working directory:
```
test: basic_install
$ sh /home/jyn/src/rust/src/tools/rust-installer/gen-installer.sh --image-dir=/home/jyn/src/rust/src/tools/rust-installer/test/image1 --work-dir=/home/jyn/src/rust/build/x86_64-unknown-linux-gnu/test/rust-installer/workdir --output-dir=/home/jyn/src/rust/build/x86_64-unknown-linux-gnu/test/rust-installer/outdir
/home/jyn/src/rust/src/tools/rust-installer/gen-installer.sh: 15: ../rust3/build/host/stage2-tools-bin/cargo: not found
TEST FAILED!
```
explicit `adt_dtorck_constraint` for `ManuallyDrop`
the only reason we didn't add outlives requirements when dropping `ManuallyDrop` was a fast-path in `trivial_dropck_outlives`. Explicitly acknowledge that fast-path in `adt_dtorck_constraint`
Only enable ConstProp at mir-opt-level >= 2.
That pass is not responsible for lints any more, so we can restrict it to optimized builds.
This reduces the amount of duplicated const-eval messages.
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`
