about summary refs log tree commit diff
path: root/tests
AgeCommit message (Collapse)AuthorLines
2025-03-20Make dedicated recovery for missing braces on closure with returnMichael Goulet-6/+12
2025-03-20Fix diagnostic struct typo, make sure is_array_like_block checks that it's a ↵Michael Goulet-2/+38
block
2025-03-20tests: accept some noise from LLVM 21 in symbols-all-mangledAugie Fackler-2/+14
I'm not entirely sure this is correct, but it doesn't feel obviously-wrong so I figured I'd just start by sending a PR rather than filing a bug and letting it linger. @rustbot label llvm-main
2025-03-20Rollup merge of #138732 - compiler-errors:did, r=jieyouxuMatthias Krüger-6/+6
Use `def_path_str` for def id arg in `UnsupportedOpInfo` We could alternatively just omit the def path from the label, but I think it's fine to keep around Fixes #138730
2025-03-20Rollup merge of #138727 - compiler-errors:ty-var-origin, r=fmeaseMatthias Krüger-10/+33
Do not rely on `type_var_origin` in `OrphanCheckErr::NonLocalInputType` The ordering of ty var unification means that we may end up with a root variable whose ty var origin is from another item's params. Let's not rely on this by just unifying the infer vars with the params of the impl + resolving. It's kinda goofy but it's clearer IMO. Fixes #132826. r? `@fmease` or `@lcnr`
2025-03-20Rollup merge of #138700 - xizheyin:issue-138612, r=NadrierilMatthias Krüger-0/+9
Suggest `-Whelp` when pass `--print lints` to rustc Closes #138612
2025-03-20Rollup merge of #138435 - eholk:prefix-yield, r=oli-obkMatthias Krüger-0/+49
Add support for postfix yield expressions We've been having a discussion about whether we want postfix yield, or want to stick with prefix yield, or have both. I figured it's easy enough to support both for now and let us play around with them while the feature is still experimental. This PR treats `yield x` and `x.yield` as semantically equivalent. There was a suggestion to make `yield x` have a `()` type (so it only works in coroutines with `Resume = ()`. I think that'd be worth trying, either in a later PR, or before this one merges, depending on people's opinions. #43122
2025-03-20Auto merge of #133889 - compiler-errors:inh-unstable, r=Nadrierilbors-0/+110
Consider fields to be inhabited if they are unstable Fixes #133885 with a simple heuristic r? Nadrieril Not totally certain if this needs T-lang approval or a crater run.
2025-03-20rustc_target: Add more RISC-V vector-related featuresTaiki Endo-1/+37
2025-03-19Lower to a memset(undef) when Rvalue::Repeat repeats uninitBen Kimock-0/+21
2025-03-20Use def_path_str for def id arg in UnsupportedOpInfoMichael Goulet-6/+6
2025-03-20Do not rely on type_var_origin in OrphanCheckErr::NonLocalInputTypeMichael Goulet-10/+33
2025-03-20Add `#[repr(u128)]`/`#[repr(i128)]` enums to `improper_ctypes_definitions`beetrees-31/+75
2025-03-19Check attrs: Don't try to retrieve the name of list stemsLeón Orell Valerian Liehr-0/+11
2025-03-19Use explicit cpu in some asm and codegen tests.Jesus Checa Hidalgo-28/+29
Some tests expect to be compiled for a specific CPU or require certain target features to be present (or absent). These tests work fine with default CPUs but fail in downstream builds for RHEL and Fedora, where we use non-default CPUs such as z13 on s390x, pwr9 on ppc64le, or x86-64-v2/x86-64-v3 on x86_64.
2025-03-19Specify a concrete stack size in channel testsJeff Martin-5/+15
The channel-stack-overflow-issue-102246 regression test fails on platforms with a small default stack size (e.g. Fuchsia, with a default of 256KiB). Update the test to specify an exact stack size for both the sender and receiver operations, to ensure it is platform agnostic. Set the stack size to less than the total allocation size of the mpsc channel, to continue to prove that the allocation is on the heap.
2025-03-19merge opaque types of nested bodieslcnr-98/+59
2025-03-19Add chaining versions of lt/le/gt/ge and use them in tuple PartialOrdScott McMurray-314/+72
2025-03-19Add a MIR pre-codegen test for tuple comparisonsScott McMurray-0/+398
We have codegen ones, but it looks like we could make those less flakey by just doing something better in the first place...
2025-03-19Rollup merge of #138613 - m-ou-se:no-more-e0773, r=jdonszelmann,petrochenkovMatthias Krüger-53/+4
Remove E0773 "A builtin-macro was defined more than once." Error E0773 "A builtin-macro was defined more than once" is triggered when using the same `#[rustc_builtin_macro(..)]` twice. However, it can only be triggered in unstable code (using a `rustc_` attribute), and there doesn't seem to be any harm in using the same implementation from `compiler/rustc_builtin_macros/…` for multiple macro definitions. By changing the Box to an Arc in `SyntaxExtensionKind`, we can throw away the `BuiltinMacroState::{NotYetSeen, AlreadySeen}` logic, simplifying things.
2025-03-19Rollup merge of #138594 - oli-obk:no-select, r=lcnrMatthias Krüger-10/+68
Fix next solver handling of shallow trait impl check I'm trying to remove unnecessary direct calls to `select`, and this one seemed like a good place to start 😆 r? `@compiler-errors` or `@lcnr`
2025-03-19Rollup merge of #138589 - ↵Matthias Krüger-0/+230
zachs18:block-label-not-supported-here-loop-body-help, r=petrochenkov If a label is placed on the block of a loop instead of the header, suggest moving it to the header. Fixes #138585 If a label is placed on the block of a loop instead of the header, suggest to the user moving it to the loop header instead of ~~suggesting to remove it~~ emitting a tool-only suggestion to remove it. ```rs fn main() { loop 'a: { return; } } ``` ```diff error: block label not supported here --> src/main.rs:2:10 | 2 | loop 'a: { return; } | ^^^ not supported here + | +help: if you meant to label the loop, move this label before the loop + | +2 - loop 'a: { return; } +2 + 'a: loop { return; } + | ``` Questions for reviewer: * The "desired output" in the linked issue had the main diagnostic be "misplaced loop label". Should the main diagnostic message the changed instead of leaving it as "block label not supported here"? * Should this be `Applicability::MachineApplicable`?
2025-03-19Rollup merge of #138001 - meithecatte:privately-uninhabited, r=NadrierilMatthias Krüger-0/+70
mir_build: consider privacy when checking for irrefutable patterns This PR fixes #137999. Note that, since this makes the compiler reject code that was previously accepted, it will probably need a crater run. I include a commit that factors out a common code pattern into a helper function, purely because the fact that this was repeated all over the place was bothering me. Let me know if I should split that into a separate PR instead.
2025-03-19Rollup merge of #137051 - thaliaarchi:io-optional-impls/empty, r=m-ou-seMatthias Krüger-2/+2
Implement default methods for `io::Empty` and `io::Sink` Implements default methods of `io::Read`, `io::BufRead`, and `io::Write` for `io::Empty` and `io::Sink`. These implementations are equivalent to the defaults, except in doing less unnecessary work. `Read::read_to_string` and `BufRead::read_line` both have a redundant call to `str::from_utf8` which can't be inlined from `core` and `Write::write_all_vectored` has slicing logic which can't be simplified (See on [Compiler Explorer](https://rust.godbolt.org/z/KK6xcrWr4)). The rest are optimized to the minimal with `-C opt-level=3`, but this PR gives that benefit to unoptimized builds. This includes an implementation of `Write::write_fmt` which just ignores the `fmt::Arguments<'_>`. This could be problematic whenever a user formatting impl is impure, but the docs do not guarantee that the args will be expanded. Tracked in https://github.com/rust-lang/rust/issues/136756. r? `@m-ou-se`
2025-03-19Fix next solver handling of shallow trait impl checkOli Scherer-2/+39
2025-03-19Demonstrate next-solver missing diagnosticOli Scherer-12/+33
2025-03-19Allow builtin macros to be used more than once.Mara Bos-53/+4
This removes E0773 "A builtin-macro was defined more than once."
2025-03-19Auto merge of #138693 - matthiaskrgr:rollup-ejq8mwp, r=matthiaskrgrbors-120/+177
Rollup of 10 pull requests Successful merges: - #136177 (clarify BufRead::{fill_buf, consume} docs) - #138654 (Remove the regex dependency from coretests) - #138655 (rustc-dev-guide sync) - #138656 (Remove double nesting in post-merge workflow) - #138658 (CI: mirror alpine and centos images to ghcr) - #138659 (coverage: Don't store a body span in `FunctionCoverageInfo`) - #138661 (Revert: Add *_value methods to proc_macro lib) - #138670 (Remove existing AFIDT implementation) - #138674 (Various codegen_llvm cleanups) - #138684 (use then in docs for `fuse` to enhance readability) r? `@ghost` `@rustbot` modify labels: rollup
2025-03-19Add test.Mara Bos-0/+22
2025-03-19Suggest `-Whelp` when pass `--print lints` to rustcxizheyin-0/+9
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-03-19Rollup merge of #138670 - compiler-errors:remove-afidt, r=oli-obkMatthias Krüger-38/+170
Remove existing AFIDT implementation This experiment will need to be reworked differently; I don't think we'll be going with the `dyn* Future` approach that is currently implemented. r? oli-obk Fixes #136286 Fixes #137706 Fixes #137895 Tracking: * #133119
2025-03-19Rollup merge of #138661 - RalfJung:revert-rustc-dev-breakage, r=petrochenkovMatthias Krüger-69/+1
Revert: Add *_value methods to proc_macro lib This reverts https://github.com/rust-lang/rust/pull/136355. That PR caused unexpected breakage: - the rustc-dev component can no longer be loaded by cargo, which impacts Miri and clippy and likely others - rustc_lexer can no longer be published to crates.io, which impacts RA See https://github.com/rust-lang/rust/issues/138647 for context. Cc `@GuillaumeGomez` `@Amanieu`
2025-03-18fix pthread-based tls on apple targetsAndrei Damian-0/+53
2025-03-18Dont consider fields that are forced unstable due to ↵Michael Goulet-1/+30
-Zforce-unstable-if-unmarked to be uninhabited
2025-03-18Consider fields to be inhabited if they are unstableMichael Goulet-0/+81
2025-03-18Remove existing AFIDT implementationMichael Goulet-38/+170
2025-03-18Revert "Rollup merge of #136355 - ↵Ralf Jung-69/+1
GuillaumeGomez:proc-macro_add_value_retrieval_methods, r=Amanieu" This reverts commit 08dfbf49e30d917c89e49eb14cb3f1e8b8a1c9ef, reversing changes made to 10bcdad7df0de3cfb95c7bdb7b16908e73cafc09.
2025-03-18coverage: Don't store a body span in `FunctionCoverageInfo`Zalathar-13/+6
2025-03-18Rollup merge of #138569 - aDotInTheVoid:reprdoc-json, r=GuillaumeGomezMatthias Krüger-0/+163
rustdoc-json: Add tests for `#[repr(...)]` Works towards #137645 and #81359 Based on #138018, but with only the test changes. CC ```@obi1kenobi``` r? ```@GuillaumeGomez```
2025-03-18Auto merge of #138630 - matthiaskrgr:rollup-kk1gogr, r=matthiaskrgrbors-0/+9
Rollup of 7 pull requests Successful merges: - #138384 (Move `hir::Item::ident` into `hir::ItemKind`.) - #138508 (Clarify "owned data" in E0515.md) - #138531 (Store test diffs in job summaries and improve analysis formatting) - #138533 (Only use `DIST_TRY_BUILD` for try jobs that were not selected explicitly) - #138556 (Fix ICE: attempted to remap an already remapped filename) - #138608 (rustc_target: Add target feature constraints for LoongArch) - #138619 (Flatten `if`s in `rustc_codegen_ssa`) r? `@ghost` `@rustbot` modify labels: rollup
2025-03-18Add test for `MutMirVisitor`makai410-1/+80
2025-03-17Auto merge of #127173 - bjorn3:mangle_rustc_std_internal_symbol, ↵bors-6/+94
r=wesleywiser,jieyouxu Mangle rustc_std_internal_symbols functions This reduces the risk of issues when using a staticlib or rust dylib compiled with a different rustc version in a rust program. Currently this will either (in the case of staticlib) cause a linker error due to duplicate symbol definitions, or (in the case of rust dylibs) cause rustc_std_internal_symbols functions to be silently overridden. As rust gets more commonly used inside the implementation of libraries consumed with a C interface (like Spidermonkey, Ruby YJIT (curently has to do partial linking of all rust code to hide all symbols not part of the C api), the Rusticl OpenCL implementation in mesa) this is becoming much more of an issue. With this PR the only symbols remaining with an unmangled name are rust_eh_personality (LLVM doesn't allow renaming it) and `__rust_no_alloc_shim_is_unstable`. Helps mitigate https://github.com/rust-lang/rust/issues/104707 try-job: aarch64-gnu-debug try-job: aarch64-apple try-job: x86_64-apple-1 try-job: x86_64-mingw-1 try-job: i686-mingw-1 try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: test-various try-job: armhf-gnu
2025-03-17Rollup merge of #138556 - charmitro:already-remapped-filename, ↵Matthias Krüger-0/+9
r=GuillaumeGomez,Urgau Fix ICE: attempted to remap an already remapped filename This commit fixes an internal compiler error (ICE) that occurs when rustdoc attempts to process macros with a remapped filename. The issue arose during macro expansion when the `--remap-path-prefix` option was used. Instead of passing remapped filenames through, which would trigger the "attempted to remap an already remapped filename" panic, we now extract the original local path from remapped filenames before processing them. A test case has been added to verify this behavior. Fixes #138520
2025-03-17resolve repeated attribute fixmeManuel Drehwald-4/+0
2025-03-17update testsManuel Drehwald-4/+4
2025-03-17Auto merge of #138611 - matthiaskrgr:rollup-hmjbqva, r=matthiaskrgrbors-31/+530
Rollup of 7 pull requests Successful merges: - #133870 (Stabilize `asm_goto` feature gate) - #137449 (Denote `ControlFlow` as `#[must_use]`) - #137465 (mir_build: Avoid some useless work when visiting "primary" bindings) - #138349 (Emit function declarations for functions with `#[linkage="extern_weak"]`) - #138412 (Install licenses into `share/doc/rust/licenses`) - #138577 (rustdoc-json: Don't also include `#[deprecated]` in `Item::attrs`) - #138588 (Avoid double lowering of idents) Failed merges: - #138321 ([bootstrap] Distribute split debuginfo if present) r? `@ghost` `@rustbot` modify labels: rollup
2025-03-17Auto merge of #137081 - ↵bors-1/+1
Shourya742:2025-02-15-change-config.toml-to-bootstrap.toml, r=onur-ozkan,jieyouxu,kobzol change config.toml to bootstrap.toml Currently, both Bootstrap and Cargo uses same name as their configuration file, which can be confusing. This PR is based on a discussion to rename `config.toml` to `bootstrap.toml` for Bootstrap. Closes: https://github.com/rust-lang/rust/issues/126875. I have split the PR into atomic commits to make it easier to review. Once the changes are finalized, I will squash them. I am particularly concerned about the changes made to modules that are not part of Bootstrap. How should we handle those changes? Should we ping the respective maintainers?
2025-03-17Rollup merge of #138577 - aDotInTheVoid:deprecate-deprecations, r=GuillaumeGomezMatthias Krüger-0/+38
rustdoc-json: Don't also include `#[deprecated]` in `Item::attrs` Closes #138378 Not sure if this should bump `FORMAT_VERSION` or not. CC `@Enselic` `@LukeMathWalker` `@obi1kenobi` r? `@GuillaumeGomez,` best reviewed commit-by-commit
2025-03-17Rollup merge of #138349 - 1c3t3a:external-weak-cfi, r=rcvalleMatthias Krüger-0/+24
Emit function declarations for functions with `#[linkage="extern_weak"]` Currently, when declaring an extern weak function in Rust, we use the following syntax: ```rust unsafe extern "C" { #[linkage = "extern_weak"] static FOO: Option<unsafe extern "C" fn() -> ()>; } ``` This allows runtime-checking the extern weak symbol through the Option. When emitting LLVM-IR, the Rust compiler currently emits this static as an i8, and a pointer that is initialized with the value of the global i8 and represents the nullabilty e.g. ``` `@FOO` = extern_weak global i8 `@_rust_extern_with_linkage_FOO` = internal global ptr `@FOO` ``` This approach does not work well with CFI, where we need to attach CFI metadata to a concrete function declaration, which was pointed out in https://github.com/rust-lang/rust/issues/115199. This change switches to emitting a proper function declaration instead of a global i8. This allows CFI to work for extern_weak functions. Example: ``` `@_rust_extern_with_linkage_FOO` = internal global ptr `@FOO` ... declare !type !61 !type !62 !type !63 !type !64 extern_weak void `@FOO(double)` unnamed_addr #6 ``` We keep initializing the Rust internal symbol with the function declaration, which preserves the correct behavior for runtime checking the Option. r? `@rcvalle` cc `@jakos-sec` try-job: test-various
2025-03-17Rollup merge of #137465 - Zalathar:visit-primary, r=oli-obkMatthias Krüger-0/+463
mir_build: Avoid some useless work when visiting "primary" bindings While looking over `visit_primary_bindings`, I noticed that it does a bunch of extra work to build up a collection of “user-type projections”, even though 2/3 of its call sites don't even use them. Those callers can get the same result via `thir::Pat::walk_always`. (And it turns out that doing so also avoids creating some redundant user-type entries in MIR for some binding constructs.) I also noticed that even when the user-type projections *are* used, the process of building them ends up eagerly cloning some nested vectors at every recursion step, even in cases where they won't be used because the current subpattern has no bindings. To avoid this, the visit method now assembles a linked list on the stack containing the information that *would* be needed to create projections, and only creates the concrete projections as needed when a primary binding is encountered. Some relevant prior PRs: - #55274 - https://github.com/rust-lang/rust/commit/0bfe184b1ad14db4b002c3a272adf44e1839822f in #55937 --- There should be no user-visible change in compiler output.