compiletest: Support revisions in debuginfo (read: debugger) tests
And start using revisions in `tests/debuginfo/macro-stepping.rs` to prevent regressing both with and without `SingleUseConsts` MIR pass.
I recommend commit-by-commit review.
## ~TODO~
- [x] Verify this more carefully.
- [x] Possibly do some preparatory PRs before taking this PR out of draft.
- [x] Rebase on https://github.com/rust-lang/rust/pull/150205 once merged so we don't have to add another "`+ 1`".
## CC
CC ``@Zalathar`` since you might have opinions about that I expose a helper function to reduce duplication
CC ``@saethlin`` since this is what we will use for `tests/debuginfo/basic-stepping.rs` in https://github.com/rust-lang/rust/pull/147426 (in the same way I use it in `tests/debuginfo/macro-stepping.rs` here)
Added codegen tests for different forms of `Option::or`
Adds tests to check the output of the different ways of writing `Option::or`
Fixesrust-lang/rust#124533
Removed confusing diagnostics note for trait required for `?` operator use
- **test: modified `bad-question-mark-on-trait-objects` to match expected behavior**
- **removed confusing message from diagnostics**
fixes [#150527](https://github.com/rust-lang/rust/issues/150527)
Detect cases where `?` is applied on a type that could be coming from a different crate version than expected
```
error[E0277]: `?` couldn't convert the error to `dependency::Error`
--> replaced
|
LL | fn main() -> Result<(), Error> {
| ----------------- expected `dependency::Error` because of this
...
LL | Err(Error2)?;
| -----------^ the trait `From<Error2>` is not implemented for `dependency::Error`
| |
| this can't be annotated with `?` because it has type `Result<_, Error2>`
|
= note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
help: the trait `From<Error2>` is not implemented for `dependency::Error`
but trait `From<()>` is implemented for it
--> replaced
|
LL | impl From<()> for Error {
| ^^^^^^^^^^^^^^^^^^^^^^^
= help: for that trait implementation, expected `()`, found `Error2`
= note: there are multiple different versions of crate `dependency` in the dependency graph
= help: you can use `cargo tree` to explore your dependency tree
```
The existing checks rely on having access to the actual types/traits that diverged to detect they are called the same, come from different crates with the same name. The new check is less specific, merely looking to see if the crate name the involved type belongs has multiple crates.
CC rust-lang/rust#78552.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#149991 (Add checks for gpu-kernel calling conv)
- rust-lang/rust#150047 (std: merge `sys::pal::common` and `sys_common` into `sys::helpers`)
- rust-lang/rust#150441 (do not suggest method call removal if it changes receiver type)
- rust-lang/rust#150616 (Update `browser-ui-test` version to `0.23.0`)
r? `@ghost`
`@rustbot` modify labels: rollup
Add checks for gpu-kernel calling conv
The `gpu-kernel` calling convention has several restrictions that were not enforced by the compiler until now.
Add the following restrictions:
1. Cannot be async
2. Cannot be called
3. Cannot return values, return type must be `()` or `!`
4. Arguments should be simple, i.e. passed by value. More complicated types can work when you know what you are doing, but it is rather unintuitive, one needs to know ABI/compiler internals.
5. Export name should be unmangled, either through `no_mangle` or `export_name`. Kernels are searched by name on the CPU side, having a mangled name makes it hard to find and probably almost always unintentional.
Tracking issue: rust-lang/rust#135467
amdgpu target tracking issue: rust-lang/rust#135024
``@workingjubilee,`` these should be all the restrictions we talked about a year ago.
cc ``@RDambrosio016`` ``@kjetilkjeka`` for nvptx
tests/codegen-llvm/some-non-zero-from-atomic-optimization.rs: New test
Closesrust-lang/rust#60044 which has one 👍 and one ❤️ vote and just **E-needs-test**.
Make `asm_experimental_arch` work in `allow_internal_unstable` macros
This change makes it possible to use unstable `asm!`, usually requiring `feature(asm_experimental_arch)`, in proc-macros with the `allow_internal_unstable` attribute.
The test was added on a target where `asm!` is unstable: Wasm. However, this affects *any* target with an unstable `asm!` implementation.
Use more principled check for generics in const ops
Fixesrust-lang/rust#144547.
Fixesrust-lang/rust#140891.
In the future, we likely want to make the check less likely to be missed by reducing the number of external entry points to HIR type lowering.
Note: If this causes pass->error regressions (not truly regressions because those cases were mistakenly accepted), they can easily be avoided for the time being by only running the check if `is_self_alias` is true or mgca is enabled.
- **Fix parsing of mgca const blocks in array repeat exprs**
- **Use more principled check for generics in const ops**
Instead of using a visitor in typeck, we just check, whenever lowering a
use of a param, whether the parent item is an MCG anon const during hir
ty lowering (and instantiate_value_path). If so, we report an error
since MCG anon consts should never be able to use generics. All other
kinds of anon consts are at least syntactically allowed to use generic
params.
We use a `TypeFolder` to accomplish this; this way, we look at the
fully explicit semantic representation of the type/const/whatever and
don't miss subtle cases like `Self` type aliases.
Add regression test for issue #99173Closerust-lang/rust#99173.
Adds a regression test for rust-lang/rust#99173, which was an ICE that occurred when a proc-macro generated code that invoked another proc-macro returning an empty `TokenStream`.
test and document that `proc_macro::Ident` is NFC-normalized
Previously, this was not tested at all and the test suite would pass even when replacing the `normalize_and_validate_ident` implementation with a `panic!`.
The `gpu-kernel` calling convention has several restrictions that were
not enforced by the compiler until now.
Add the following restrictions:
1. Cannot be async
2. Cannot be called
3. Cannot return values, return type must be `()` or `!`
4. Arguments should be primitives, i.e. passed by value. More complicated
types can work when you know what you are doing, but it is rather
unintuitive, one needs to know ABI/compiler internals.
5. Export name should be unmangled, either through `no_mangle` or
`export_name`. Kernels are searched by name on the CPU side, having
a mangled name makes it hard to find and probably almost always
unintentional.
cleanup: move c-variadic arguments handling into compute_inputs_and_output
Previously, ``unnormalized_input_tys`` needs to be mutable because the c_variadic arguments are added to ``unnormalized_input_tys`` outside of ``compute_inputs_and_output``. This could have been done together in ``compute_inputs_and_output``.
```
error[E0277]: `?` couldn't convert the error to `dependency::Error`
--> replaced
|
LL | fn main() -> Result<(), Error> {
| ----------------- expected `dependency::Error` because of this
...
LL | Err(Error2)?;
| -----------^ the trait `From<Error2>` is not implemented for `dependency::Error`
| |
| this can't be annotated with `?` because it has type `Result<_, Error2>`
|
= note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
help: the trait `From<Error2>` is not implemented for `dependency::Error`
but trait `From<()>` is implemented for it
--> replaced
|
LL | impl From<()> for Error {
| ^^^^^^^^^^^^^^^^^^^^^^^
= help: for that trait implementation, expected `()`, found `Error2`
= note: there are multiple different versions of crate `dependency` in the dependency graph
= help: you can use `cargo tree` to explore your dependency tree
```
The existing checks rely on having access to the actual types/traits that diverged to detect they are called the same, come from different crates with the same name. The new check is less specific, merely looking to see if the crate name the involved type belongs has multiple crates.
Remove `feature(string_deref_patterns)`
The older `string_deref_patterns` feature has been superseded by the newer and more general `deref_patterns` feature. Removing string-deref-patterns allows us to get rid of a few tricky special cases in match lowering, which are different from the special cases used by deref-patterns.
The handful of existing tests for `string_deref_patterns` have been migrated to use `deref_patterns` instead. Current nightly users of the older feature should hopefully be able to migrate to the newer feature without too much trouble.
Note that `deref_patterns` is currently marked as an “incomplete” feature, because it doesn't have an accepted RFC. But `string_deref_patterns` doesn't appear to have ever had an accepted RFC either, so arguably it should have been marked incomplete too.
---
- Tracking issue for both features: https://github.com/rust-lang/rust/issues/87121
- Original implementation: https://github.com/rust-lang/rust/pull/98914
- [Zulip thread: Can we remove `#![feature(string_deref_patterns)]`?](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Can.20we.20remove.20.60.23!.5Bfeature.28string_deref_patterns.29.5D.60.3F/with/565787352)
RISC-V: Implement (Zkne or Zknd) intrinsics correctly
On rust-lang/stdarch#1765, it has been pointed out that two RISC-V (64-bit only) intrinsics to perform AES key scheduling have wrong target feature.
`aes64ks1i` and `aes64ks2` instructions require *either* Zkne (scalar cryptography: AES encryption) or Zknd (scalar cryptography: AES decryption) extension (or both) but corresponding Rust intrinsics (in `core::arch::riscv64`) required *both* Zkne and Zknd extensions.
An excerpt from the original intrinsics:
```rust
#[target_feature(enable = "zkne", enable = "zknd")]
```
To fix that, we need to:
1. Represent a condition where *either* Zkne or Zknd is available and
2. Workaround an issue: `llvm.riscv.aes64ks1i` / `llvm.riscv.aes64ks2` LLVM intrinsics require either Zkne or Zknd extension.
This PR attempts to resolve them by:
1. Adding a perma-unstable RISC-V target feature: `zkne_or_zknd` (implied from both `zkne` and `zknd`) and
2. Using inline assembly to construct machine code directly (because `zkne_or_zknd` alone cannot imply neither Zkne nor Zknd, we cannot use LLVM intrinsics).
The author confirmed that we can construct an AES key scheduling function with decent performance using fixed `aes64ks1i` and `aes64ks2` intrinsics (with optimization enabled).
Allow inline calls to offload intrinsic
Removes explicit insertion point handling and recovers the pointer at the end of the saved basic block.
r? `@ZuseZ4`
fixes: https://github.com/rust-lang/rust/issues/150413
Port `#[instruction_set]` to attribute parser
Please note the test changes, and deprecation of `E0778` and `E0779`
In my opinion, all errors related to this attribute are improved I think, except for if you have `#[instruction_set(arm::)]` in which case there's an `error: expected identifier, found <eof>`, which is quite unhelpful I think, but this seems to be a limitation of the general attribute parsing flow
r? `@JonathanBrouwer`
Make inliner cycle detection a fallible process
The query `mir_callgraph_cyclic` is supposed to find _all_ callees that _may_ lead to a recursive call back to the given `LocalDefId`. But that query was built using a function which recurses through the call graph and tries to locally handle hitting the recursion limit during the walk. That is wrong. If the recursion limit is encountered, the set may be incomplete and thus useless. If we hit the recursion limit the only correct thing to do is bail.
Some benchmarks improve because for some functions we will bail out of the call graph walk faster. Some benchmarks regress because we do less inlining, but that is quite rare with the default recursion depth.
Originally I thought this might be a fix for https://github.com/rust-lang/rust/issues/131960, but it turns out that it is _actually_ a fix for https://github.com/rust-lang/rust/issues/146998.
There was an inconsistency where in the case of array repeat
expressions, we forgot to eat the `const` keyword of mgca const blocks.
Thus, we ended up parsing them as an anon const containing an inline
const, instead of simply an anon const as they should be.
This commit fixes that issue and also makes the parsing for mgca const
blocks more consistent and simpler in general. For example, we avoid
doing a lookahead check to ensure there's a curly brace coming. There
should always be one after a `const` keyword in an expression context,
and that's handled by the mgca const block parsing function.
Adds a regression test for #137823
Adds a regression test for rust-lang/rust#137823. The test ensures that recursive generic function instantiation properly triggers the recursion limit error instead of ICE-ing with `type variables should not be hashed`.
Closesrust-lang/rust#137823
Stuart Cook