about summary refs log tree commit diff
path: root/tests
AgeCommit message (Collapse)AuthorLines
2025-05-21Check for element being `const` before resolving repeat countBoxy-32/+18
2025-05-21GAI logic on stable tooBoxy-10/+139
2025-05-21Properly test whether repeat expr checks are pre/post integer fallbackBoxy-82/+74
2025-05-21Don't allow repeat expr count inference side effects to propagateBoxy-2/+77
2025-05-21Rollup merge of #141318 - nnethercote:fix-140884, r=compiler-errorsMatthias Krüger-6/+18
Avoid creating an empty identifer in `Symbol::to_ident_string`. Because that causes an assertion failure in debug builds. Fixes #140884. r? `@oli-obk`
2025-05-21Rollup merge of #141317 - dianne:continue-liveness-ice-fix, r=compiler-errorsMatthias Krüger-15/+80
typeck: catch `continue`s pointing to blocks This taints the typeck results with errors if a `continue` is found not pointing to a loop. A few things were going wrong here. First, since this wasn't caught in typeck, we'd end up building the THIR and then running liveness lints on ill-formed HIR. Since liveness assumes all `continue`s point to loops, it wasn't setting a live node for the `continue`'s destination. There was a fallback for if it couldn't retrieve that live node, but it was faulty; it would create a new live node to represent an erroneous state after the analysis's RWU table had already been built. This would ICE if the new live node was used in operations, such as merging results from the arms of a match. I've removed this error-recovery since it was buggy, and we should really catch bad labels before liveness. I've also replaced an outdated comment about when liveness lints are run. At this point, I think the call to `check_liveness` could be moved elsewhere, but if it can be run when the typeck results are tainted by errors, it'll need some slight refactoring so it can bail out in that case. In lieu of that, I've added an assert. Fixes #113379 Fixes #121623
2025-05-21Rollup merge of #141213 - xizheyin:issue-141136, r=nnethercoteMatthias Krüger-10/+65
Suggest use "{}", self.x instead of {self.x} when resolve x as field of `self` Fixes #141136 Changes can be seen in the second commit: https://github.com/rust-lang/rust/commit/9de7fff0d8ab72fb57dea6255fc10fe35219db72 r? compiler
2025-05-21Avoid creating an empty identifer in `Symbol::to_ident_string`.Nicholas Nethercote-6/+18
Because that causes an assertion failure in debug builds. Fixes #140884.
2025-05-21Rollup merge of #141308 - spastorino:fix-rpitit-error-reporting-ice, ↵Matthias Krüger-1/+22
r=nnethercote Do not call name() on rpitit assoc_item Fixes #141143 r? `@nnethercote`
2025-05-21Rollup merge of #140981 - est31:guard_let_chains_tests, r=petrochenkovMatthias Krüger-48/+269
Add match guard let chain drop order and scoping tests We have a bunch of tests for if let chain drop order, but those tests don't cover match guard chains to the same depth. This PR adds the following tests: * match guard equivalents of the if let chains tests in the `drop-order-comparisons.rs` test, added by #133605. * match guard equivalent of the `mir_let_chains_drop_order.rs` test, added by #107251 * match guard equivalent of `temporary-early-drop.rs`, added by #133093 The added tests all have variants for 2021 and 2024, showing that the behavior on both editions matches that of if let chains on 2024. tracking issue: https://github.com/rust-lang/rust/issues/51114
2025-05-21Auto merge of #127721 - bvanjoi:issue-124273, r=petrochenkovbors-0/+241
collect doc alias as tips during resolution Close #124273 Collect the symbol in the doc alias attributes and provide a tip when a match is found. r? `@estebank`
2025-05-20typeck: catch `continue`s pointing to blocksdianne-15/+80
This taints the typeck results with errors if a `continue` is found not pointing to a loop, which fixes an ICE. A few things were going wrong here. First, since this wasn't caught in typeck, we'd end up building the THIR and then running liveness lints on ill-formed HIR. Since liveness assumes all `continue`s point to loops, it wasn't setting a live node for the `continue`'s destination. However, the fallback for this was faulty; it would create a new live node to represent the erroneous state after the analysis's RWU table had already been built. This would ICE if the new live node was used in operations, such as merging results from the arms of a match. I've removed this error-recovery since it was buggy, and we should really catch bad labels before liveness. I've also replaced an outdated comment about when liveness lints are run. At this point, I think the call to `check_liveness` could be moved elsewhere, but if it can be run when the typeck results are tainted by errors, it'll need some slight refactoring so it can bail out in that case. In lieu of that, I've added an assertion.
2025-05-20Do not call name() on rpitit assoc_itemSantiago Pastorino-1/+22
2025-05-21collect doc alias as tips during resolutionbohan-0/+241
2025-05-20Rollup merge of #141275 - dianne:gather-guard-pat-locals-once, r=compiler-errorsMatthias Krüger-0/+15
`gather_locals`: only visit guard pattern guards when checking the guard When checking a pattern with guards in it, `GatherLocalsVisitor` will visit both the pattern (when type-checking the let, arm, or param containing it) and local declarations in the guard expression (when checking the guard itself). This keeps it from visiting the guard when visiting the pattern, since otherwise it would gather locals from the guard twice, which would lead to a delayed bug: "evaluated expression more than once". Tracking issue for guard patterns: #129967
2025-05-20Rollup merge of #141253 - ↵Matthias Krüger-2/+2
azhogin:azhogin/async-drop-feature-inconsistency-warning, r=oli-obk Warning added when dependency crate has async drop types, and the feature is disabled In continue of https://github.com/rust-lang/rust/pull/141031. When dependency crate has non-empty `adt_async_destructor` table in metadata, and `async_drop` feature is disabled for local crate, warning will be emitted. Test `dependency-dropped` has two revisions - with and without feature enabled. With feature enabled, async drop for dropee is executed ("Async drop" printed). Without the feature enabled, sync drop is executed ("Sync drop" printed) and warning is emitted. Warning example: ``` warning: found async drop types in dependecy `async_drop_dep`, but async_drop feature is disabled for `dependency_dropped` --> $DIR/dependency-dropped.rs:7:1 | LL | #![cfg_attr(with_feature, feature(async_drop))] | ^ | = help: if async drop type will be dropped in a crate without `feature(async_drop)`, sync Drop will be used ```
2025-05-20Rollup merge of #141236 - jagunter:issue-140823, r=compiler-errorsMatthias Krüger-9/+38
Resolved issue with mismatched types triggering ICE in certain scenarios ## Background The function `annotate_mut_binding_to_immutable_binding` called in `emit_coerce_suggestions` performs a type comparison between the `expected` and `found` types from `ExpectedFound` in the `TypeError`. This can fail if the `found` type contains a region variable that's been rolled back. ## What is being changed? This updates `annotate_mut_binding_to_immutable_binding` to use `expr_ty` and `expected` from the parent function instead of the types from the `TypeError`. This sidesteps the issue of using `found` from `TypeError` which may leak lingering inference region variables. This does change the diagnostic behavior to _only_ support cases where the expected outermost type is `&T`, but that seems to be the intended functionality. Also fixed the example in the `annotate_mut_binding_to_immutable_binding` rustdocs. r? rust-lang/types Fixes #140823
2025-05-20Just error on recursive opaque ty in HIR typeckMichael Goulet-180/+90
2025-05-19`gather_locals`: only visit guard pattern guards when checking the guarddianne-0/+15
When checking a pattern with guards in it, `GatherLocalsVisitor` will visit both the pattern (when type-checking the let, arm, or param containing it) and the guard expression (when checking the guard itself). This keeps it from visiting the guard when visiting the pattern, since otherwise it would gather locals from the guard twice, which would lead to a delayed bug: "evaluated expression more than once".
2025-05-20Add println! test for sugg-field-in-format-string-issue-141136xizheyin-1/+10
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-05-20make std::intrinsic functions actually be intrinsicsRalf Jung-34/+17
2025-05-20Warning when dependency crate has async drop types, and the feature is ↵Andrew Zhogin-2/+2
disabled - typo fixed
2025-05-19Fixed possible ICE in annotate_mut_binding_to_immutable_bindingJosh Gunter-9/+38
2025-05-19Auto merge of #141255 - matthiaskrgr:rollup-ravsgen, r=matthiaskrgrbors-1/+15
Rollup of 6 pull requests Successful merges: - #131200 (Handle `rustc_query_system` cases of `rustc::potential_query_instability` lint) - #141244 (windows: document that we rely on an undocumented property of GetUserProfileDirectoryW) - #141247 (skip compiler tools sanity checks on certain commands) - #141248 (fix data race in ReentrantLock fallback for targets without 64bit atomics) - #141249 (introduce common macro for `MutVisitor` and `Visitor` to dedup code) - #141253 (Warning added when dependency crate has async drop types, and the feature is disabled) r? `@ghost` `@rustbot` modify labels: rollup
2025-05-19Warning added when dependency crate has async drop types, and the feature is ↵Andrew Zhogin-1/+15
disabled
2025-05-19Rollup merge of #141242 - folkertdev:aarch64-asm-parse-errors, r=AmanieuStuart Cook-470/+7
in `tests/ui/asm/aarch64/parse-error.rs`, only test cases specific to that target this is more in line with the x86 parse error tests at https://github.com/rust-lang/rust/blob/master/tests/ui/asm/x86_64/x86_64_parse_error.rs. We could at this point use minicore so that these tests run no matter the host target? `tests/ui/asm/aarch64/parse-error.rs` was mostly a copy of https://github.com/rust-lang/rust/blob/master/tests/ui/asm/parse-error.rs, though a bit out of date. The only aarch64-specific tests are those that talk about register names. Here is a diff between those two files: ```diff --- <unnamed> +++ <unnamed> `@@` -1,4 +1,4 `@@` -//@ needs-asm-support +//@ only-aarch64 use std::arch::{asm, global_asm}; `@@` -36,36 +36,12 `@@` //~^ ERROR expected one of asm!("{}", options(), const foo); //~^ ERROR attempt to use a non-constant value in a constant - - // test that asm!'s clobber_abi doesn't accept non-string literals - // see also https://github.com/rust-lang/rust/issues/112635 - asm!("", clobber_abi()); - //~^ ERROR at least one abi must be provided asm!("", clobber_abi(foo)); //~^ ERROR expected string literal asm!("", clobber_abi("C" foo)); //~^ ERROR expected one of `)` or `,`, found `foo` asm!("", clobber_abi("C", foo)); //~^ ERROR expected string literal - asm!("", clobber_abi(1)); - //~^ ERROR expected string literal - asm!("", clobber_abi(())); - //~^ ERROR expected string literal - asm!("", clobber_abi(uwu)); - //~^ ERROR expected string literal - asm!("", clobber_abi({})); - //~^ ERROR expected string literal - asm!("", clobber_abi(loop {})); - //~^ ERROR expected string literal - asm!("", clobber_abi(if)); - //~^ ERROR expected string literal - asm!("", clobber_abi(do)); - //~^ ERROR expected string literal - asm!("", clobber_abi(<)); - //~^ ERROR expected string literal - asm!("", clobber_abi(.)); - //~^ ERROR expected string literal - asm!("{}", clobber_abi("C"), const foo); //~^ ERROR attempt to use a non-constant value in a constant asm!("", options(), clobber_abi("C")); `@@` -76,7 +52,15 `@@` //~^^ ERROR argument never used //~^^^ ERROR attempt to use a non-constant value in a constant //~^^^^ ERROR attempt to use a non-constant value in a constant - + asm!("", a = in("x0") foo); + //~^ ERROR explicit register arguments cannot have names + asm!("{a}", in("x0") foo, a = const bar); + //~^ ERROR attempt to use a non-constant value in a constant + asm!("{a}", in("x0") foo, a = const bar); + //~^ ERROR attempt to use a non-constant value in a constant + asm!("{1}", in("x0") foo, const bar); + //~^ ERROR positional arguments cannot follow named arguments or explicit register arguments + //~^^ ERROR attempt to use a non-constant value in a constant asm!("", options(), ""); //~^ ERROR expected one of asm!("{}", in(reg) foo, "{}", out(reg) foo); `@@` -109,13 +93,11 `@@` global_asm!("{}", const(reg) FOO); //~^ ERROR expected one of global_asm!("", options(FOO)); -//~^ ERROR expected one of `)`, `att_syntax`, or `raw`, found `FOO` -global_asm!("", options(FOO,)); -//~^ ERROR expected one of `)`, `att_syntax`, or `raw`, found `FOO` +//~^ ERROR expected one of global_asm!("", options(nomem FOO)); -//~^ ERROR expected one of `)` or `,`, found `FOO` +//~^ ERROR expected one of global_asm!("", options(nomem, FOO)); -//~^ ERROR expected one of `)`, `att_syntax`, or `raw`, found `FOO` +//~^ ERROR expected one of global_asm!("{}", options(), const FOO); global_asm!("", clobber_abi(FOO)); //~^ ERROR expected string literal `@@` -129,8 +111,6 `@@` //~^ ERROR `clobber_abi` cannot be used with `global_asm!` global_asm!("{}", options(), clobber_abi("C"), const FOO); //~^ ERROR `clobber_abi` cannot be used with `global_asm!` -global_asm!("", clobber_abi("C"), clobber_abi("C")); -//~^ ERROR `clobber_abi` cannot be used with `global_asm!` global_asm!("{a}", a = const FOO, a = const BAR); //~^ ERROR duplicate argument named `a` //~^^ ERROR argument never used `@@` -142,16 +122,3 `@@` //~^ ERROR asm template must be a string literal global_asm!("{1}", format!("{{{}}}", 0), const FOO, const BAR); //~^ ERROR asm template must be a string literal - -global_asm!("{}", in(reg)); -//~^ ERROR the `in` operand cannot be used with `global_asm!` -global_asm!("{}", out(reg)); -//~^ ERROR the `out` operand cannot be used with `global_asm!` -global_asm!("{}", lateout(reg)); -//~^ ERROR the `lateout` operand cannot be used with `global_asm!` -global_asm!("{}", inout(reg)); -//~^ ERROR the `inout` operand cannot be used with `global_asm!` -global_asm!("{}", inlateout(reg)); -//~^ ERROR the `inlateout` operand cannot be used with `global_asm!` -global_asm!("{}", label(reg)); -//~^ ERROR the `label` operand cannot be used with `global_asm!` ```
2025-05-19Rollup merge of #141225 - matthiaskrgr:crashes_may2015, r=compiler-errorsStuart Cook-0/+396
more ice tests try-job: aarch64-apple try-job: x86_64-msvc-1 try-job: x86_64-gnu try-job: dist-i586-gnu-i586-i686-musl try-job: test-various
2025-05-19Rollup merge of #140847 - Zalathar:unused-local-file, r=SparrowLiiStuart Cook-20/+46
coverage: Detect unused local file IDs to avoid an LLVM assertion Each function's coverage metadata contains a *local file table* that maps local file IDs (used by the function's mapping regions) to global file IDs (shared by all functions in the same CGU). LLVM requires all local file IDs to have at least one mapping region, and has an assertion that will fail if it detects a local file ID with no regions. To make sure that assertion doesn't fire, we need to detect and skip functions whose metadata would trigger it. (This can't actually happen yet, because currently all of a function's spans must belong to the same file and expansion. But this will be an important edge case when adding expansion region support.)
2025-05-19in aarch64 asm parse error tests, only test cases specific to that targetFolkert de Vries-470/+7
this is more in line with the x86 parse error tests. The cross-platform tests were more complete anyway
2025-05-19Rollup merge of #141094 - satler-git:issue-101650, r=lcnrStuart Cook-0/+24
add regression test for rust-lang#101650 closes #101650, which was already fixed.
2025-05-19Rollup merge of #140049 - haenoe:fix-autodiff-generics, r=ZuseZ4Stuart Cook-0/+62
fix autodiff macro on generic functions heloo there! This short PR allows applying the `autodiff` macro to generic functions like this one. It only touches the frontend part, since the `rustc_autodiff` macro can already handle generics. ```rust #[autodiff(d_square, Reverse, Duplicated, Active)] fn square<T: std::ops::Mul<Output = T> + Copy>(x: &T) -> T { *x * *x } ``` Thanks to Manuel for creating an issue on this. For more information on this see #140032 r? `@ZuseZ4` As always: thanks for any piece of feedback!! Fixes: #140032 Tracking issue for autodiff: https://github.com/rust-lang/rust/issues/124509
2025-05-18Rollup merge of #141218 - dianqk:gvn-overlapping, r=oli-obkLeón Orell Valerian Liehr-0/+54
gvn: avoid creating overlapping assignments Quick fix #141038, as I couldn't find a way to avoid in-place modification. I'm considering handling all `ravlue` modifications within the `visit_statement` function. r? mir-opt
2025-05-18Rollup merge of #140746 - dianne:guard-pat-res, r=oli-obkLeón Orell Valerian Liehr-27/+220
name resolution for guard patterns This PR provides an initial implementation of name resolution for guard patterns [(RFC 3637)](https://github.com/rust-lang/rfcs/blob/master/text/3637-guard-patterns.md). This does not change the requirement that the bindings on either side of an or-pattern must be the same [(proposal here)](https://github.com/rust-lang/rfcs/blob/master/text/3637-guard-patterns.md#allowing-mismatching-bindings-when-possible); the code that handles that is separate from what this PR touches, so I'm saving it for a follow-up. On a technical level, this separates "collecting the bindings in a pattern" (which was already done for or-patterns) from "introducing those bindings into scope". I believe the approach used here can be extended straightforwardly in the future to work with `if let` guard patterns, but I haven't tried it myself since we don't allow those yet. Tracking issue for guard patterns: #129967 cc ``@Nadrieril``
2025-05-18Rollup merge of #140490 - folkertdev:asm-parser-changes, r=Amanieu,traviscrossLeón Orell Valerian Liehr-65/+37
split `asm!` parsing and validation This PR splits `asm!` parsing and validation into two separate steps. The parser constructs a `Vec<RawAsmArg>`, with each element corresponding to an argument to one of the `asm!` macros. The validation then checks things like ordering of arguments or that options are not provided twice. The motivation is https://github.com/rust-lang/rust/issues/140279, which wants to add `#[cfg(...)]` support to these arguments. This support can now be added in a straightforward way by adding an `attributes: ast::AttrVec` field to `RawAsmArg`. An extra reason for this split is that `rustfmt` probably wants to format the assembly at some point (currently that appears to be stubbed out, and the formatting is unstable https://github.com/rust-lang/style-team/issues/152). r? ``@ghost`` (just want to look at CI for now) cc ``@ytmimi`` we discussed asm formatting a little while ago in https://github.com/rust-lang/rustfmt/issues/6526. Am I correct in assuming that `AsmArgs` does not give enough information for formatting, but that `RawAsmArgs` would (it e.g. does not join information from multiple lines). This must have been an issue before? try-job: aarch64-apple
2025-05-18Rollup merge of #138940 - sayantn:stabilize-avx512, r=Amanieu,traviscrossLeón Orell Valerian Liehr-35/+27
Stabilize the avx512 target features This PR stabilizes the AVX512 target features - see [this comment](https://github.com/rust-lang/rust/issues/111137#issuecomment-2745821279). Tracking Issue - #44839 The target feature UI tests have been changed to `x87` (chosen because this is very unlikely to stablize ever, please comment if some other feature will be better) related: #111137
2025-05-18more ice testsMatthias Krüger-0/+396
2025-05-18name resolution for guard patternsdianne-27/+220
2025-05-18gvn: avoid creating overlapping assignmentsdianqk-0/+54
2025-05-18delay error for unsupported optionsFolkert de Vries-65/+37
2025-05-18Rollup merge of #141132 - bvanjoi:issue-141082, r=fmeaseLeón Orell Valerian Liehr-5/+50
Use `crate::` prefix for root macro suggestions Fixes #141082 I've changed the prefix to `crate` directly, since it's compatible across all editions.
2025-05-18Rollup merge of #141045 - dpaoliello:noarmhazard, r=jieyouxuLeón Orell Valerian Liehr-0/+7
[win][arm64] Remove 'Arm64 Hazard' undocumented MSVC option and instead disable problematic test PR #140758 added the undocumented `/arm64hazardfree` MSVC linker flag to work around a test failure where LLVM generated code that would trip a hazard in an outdated ARM processor. Adding this flag caused issues with LLD, as it doesn't recognize it. Rethinking the issue, using the undocumented flag seems like the incorrect solution: there's no guarantee that the flag won't be removed in the future, or change its meaning. Instead, I've disabled the problematic test for Arm64 Windows and have filed a bug with the MSVC team to have the check removed: <https://developercommunity.microsoft.com/t/Remove-checking-for-and-fixing-Cortex-A/10905134> This PR supersedes #140977 r? ```@jieyouxu```
2025-05-18Rollup merge of #140966 - est31:let_chains_library, r=tgross35León Orell Valerian Liehr-1/+1
Remove #![feature(let_chains)] from library and src/librustdoc PR https://github.com/rust-lang/rust/pull/132833 has stabilized the `let_chains` feature. This PR removes the last occurences from the library, the compiler, and librustdoc (also because #140887 missed the conditional in one of the crates as it was behind the "rustc" feature). We keep `core` as exercise for the future as updating it is non-trivial (see PR thread).
2025-05-18Suggest use `"{}", self.x` instead of `{self.x}` when resolve `x` as field ↵xizheyin-18/+4
of `self` Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-05-18Add test sugg-field-in-format-string-issue-141136xizheyin-0/+60
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-05-18Remove uses of `#[feature(avx512_target_feature)]`sayantn-23/+16
2025-05-18Stabilize `avx512_target_feature`sayantn-12/+11
2025-05-17Use `crate::` prefix for root macro suggestionsbohan-5/+50
2025-05-17Rollup merge of #141125 - lcnr:coroutine_obligations_use_borrowck, ↵Matthias Krüger-0/+48
r=compiler-errors check coroutines with `TypingMode::Borrowck` to avoid cyclic reasoning MIR borrowck taints its output if an obligation fails. This could then cause `check_coroutine_obligations` to silence its error, causing us to not emit and actual error and ICE. Fixes the ICE in https://github.com/rust-lang/trait-system-refactor-initiative/issues/199. It is unfortunately still a regression. r? compiler-errors
2025-05-17Rollup merge of #141121 - compiler-errors:ambig-is-not-err, r=lcnrMatthias Krüger-0/+37
Only select true errors in `impossible_predicates` See description in test. Fixes #141119 r? lcnr
2025-05-17Rollup merge of #135808 - tiif:conv_display, r=workingjubileeMatthias Krüger-2/+2
Implement Display for ``rustc_target::callconv::Conv`` Follow up of https://github.com/rust-lang/rust/pull/133103#discussion_r1885552854