about summary refs log tree commit diff
path: root/tests
AgeCommit message (Collapse)AuthorLines
2025-08-26Rollup merge of #145076 - ZhongyaoChen:feature/add-tier3-riscv64a23-target, ↵Guillaume Gomez-0/+5
r=davidtwco Add new Tier-3 target: riscv64a23-unknown-linux-gnu MCP: [Tier 3 target proposal: riscv64a23-unknown-linux-gnu](https://github.com/rust-lang/compiler-team/issues/894) Changes: - add new target: riscv64a23-unknown-linux-gnu - add target page
2025-08-26Rollup merge of #144551 - neuschaefer:a64be-musl, r=davidtwcoGuillaume Gomez-0/+3
Add aarch64_be-unknown-linux-musl target This PR adds a target definition for big-endian Aarch64 with musl-libc. cc `@Gelbpunkt`
2025-08-26Rollup merge of #144373 - hkBst:remove-deprecated-1, r=jhprattGuillaume Gomez-4/+3
remove deprecated Error::description in impls [libs-api permission](https://github.com/rust-lang/libs-team/issues/615#issuecomment-3074045829) r? `@cuviper` or `@jhpratt`
2025-08-26Use captures(address) instead of captures(none) for indirect argsNikita Popov-17/+32
While provenance cannot be captured through these arguments, the address / object identity can.
2025-08-26Test `instrument-mcount`Jamie Hill-Daniel-0/+24
2025-08-26Update tests.Mara Bos-105/+96
2025-08-26remove deprecated Error::description in implsMarijn Schouten-4/+3
2025-08-26Rollup merge of #145535 - lolbinarycat:rustdoc-invalid_html_tags-svg-145529, ↵Stuart Cook-12/+153
r=GuillaumeGomez make rustdoc::invalid_html_tags more robust best reviewed a commit at a time. I kept finding more edge case so I ended up having to make quite significant changes to the parser in order to make it preserve state across events and handle multiline attributes correctly. fixes rust-lang/rust#145529
2025-08-26Rollup merge of #144885 - zachs18:ptr_guaranteed_cmp_more, r=RalfJungStuart Cook-30/+192
Implement some more checks in `ptr_guaranteed_cmp`. * Pointers with different residues modulo their allocations' least common alignment are never equal. * Pointers to the same static allocation are equal if and only if they have the same offset. * Pointers to different non-zero-sized static allocations are unequal if both point within their allocation, and not on opposite ends. Tracking issue for `const_raw_ptr_comparison`: <https://github.com/rust-lang/rust/issues/53020> This should not affect `is_null`, the only usage of this intrinsic on stable. Closes https://github.com/rust-lang/rust/issues/144584
2025-08-25add tests, some with incorrect lifetime extension behaviordianne-0/+157
2025-08-25Auto merge of #145711 - lcnr:non-defining-uses-hir-typeck, r=BoxyUwUbors-183/+225
Support non-defining uses in HIR typeck This changes the impl of `NormalizesTo` for opaque types to be structural during HIR typeck. The previous impl equated region variables of the opaque type key with existing entries which can result in spurious leak check errors and also results in mismatches with MIR borrowck, theoretically causing ICE. The approach is very similar to rust-lang/rust#145244 in MIR typeck: - we collect all uses of opaque types during HIR typeck - before writeback, we search for *defining uses* - the opaque type key has fully universal generic args modulo regions - the hidden type has no infer vars - we use these defining uses to compute the concrete type for the opaque and map it to the definition site - we use this concrete type to check the type of all uses of opaques during HIR typeck. This also constrains infer vars in non-defining uses Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/135, fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/49. r? `@BoxyUwU`
2025-08-25Only consider auto traits empty for the purposes of omitting vptrs from ↵Zachary S-0/+161
subtrait vtables
2025-08-25Use attribute name in message for "outer attr used as inner attr" errorsSasha Pourcelot-171/+537
2025-08-25Add aarch64_be-unknown-linux-musl targetJ. Neuschäfer-0/+3
2025-08-25On binding not present in all patterns, suggest potential typoEsteban Küber-19/+180
``` error[E0408]: variable `Ban` is not bound in all patterns --> f12.rs:9:9 | 9 | (Foo,Bar)|(Ban,Foo) => {} | ^^^^^^^^^ --- variable not in all patterns | | | pattern doesn't bind `Ban` | help: you might have meant to use the similarly named previously used binding `Bar` | 9 - (Foo,Bar)|(Ban,Foo) => {} 9 + (Foo,Bar)|(Bar,Foo) => {} | ```
2025-08-25Switch next solver to use a specific associated type for trait def idChayim Refael Friedman-1/+1
The compiler just puts `DefId` in there, but rust-analyzer uses different types for each kind of item.
2025-08-25change non-defining use error messagelcnr-6/+58
2025-08-25support non-defining uses in HIR typecklcnr-177/+167
2025-08-25Rollup merge of #145788 - JonathanBrouwer:proper-fix-for-macro-call-target, ↵Stuart Cook-42/+302
r=jdonszelmann Fix attribute target checking for macro calls Fixes https://github.com/rust-lang/rust/issues/145779 r? `@jdonszelmann`
2025-08-25Rollup merge of #145620 - compiler-errors:fake-dyn-to-dyn, r=lcnrStuart Cook-0/+16
Account for impossible bounds making seemingly unsatisfyable dyn-to-dyn casts Fixes https://github.com/rust-lang/rust/issues/141806 When we have an impossible where clause like `dyn Trait<u8>: Sized`, this may make a dyn-to-dyn cast like `dyn Trait<()> -> dyn trait<u8>` to successfully type check as if it were a wide-to-thin ptr cast (discarding metadata): https://github.com/rust-lang/rust/blob/16ad385579cebb6f7d53367c552661b6b51a4a02/compiler/rustc_hir_typeck/src/cast.rs#L862-L865 In borrowck, we are expecting that the only meaningful dyn-to-dyn cast to be a metadata-preserving wide-to-wide ptr cast, which requires that the principals of the dyn pointers are equal. Borrowck additionally assumes that these principals have already been proven equal *modulo regions*, and we thus ICE since `Trait<u8>` and `Trait<()>` do not unify: https://github.com/rust-lang/rust/blob/16ad385579cebb6f7d53367c552661b6b51a4a02/compiler/rustc_borrowck/src/type_check/mod.rs#L1481-L1524 This PR fixes this ICE by checking whether the RHS of the cast is considered to be Sized in the environment of the MIR typeck, and if so then skipping over this dyn->dyn principal compatibility check. r? `@lcnr` perhaps?
2025-08-25add span to struct pattern rest (..)Valdemar Erk-10/+10
2025-08-24Auto merge of #145262 - compiler-errors:prefer-only-param, r=lcnrbors-0/+196
Make sure to treat only param where clauses as inherent See the description in the test file. This PR fixes a bug introduced by rust-lang/rust#141333, where we considered non-`Param` where clauses to be "inherent" for the purpose of method probing, which leads to both changes in method ambiguity (see test) and also import usage linting (and thus fixes https://github.com/rust-lang/rust/issues/145185). r? `@lcnr`
2025-08-24Make sure to treat only param where clauses as inherentMichael Goulet-0/+196
2025-08-24Auto merge of #137229 - GuillaumeGomez:expand-macro, r=lolbinarycatbors-1/+234
Add support for macro expansion in rustdoc source code pages This is what it looks like: ![Screenshot From 2025-02-18 18-08-51](https://github.com/user-attachments/assets/ce2b3806-6218-47df-94bf-e9e9ed40cd41) ![image](https://github.com/user-attachments/assets/891042db-8632-4dba-9343-e28570c058fe) You can test it [here](https://rustdoc.crud.net/imperio/macro-expansion/src/lib/lib.rs.html). In this case, I also enabled the `--generate-link-to-definition` to show that both options work well together. Note: <del>There is a bug currently in firefox where the line numbers are not displayed correctly if they're inside the "macro expansion" span: https://bugzilla.mozilla.org/show_bug.cgi?id=1949948<del> Found a workaround around this bug. r? `@notriddle`
2025-08-24Auto merge of #145812 - karolzwolak:attrs-in-fields-and-variants-section, ↵bors-0/+4
r=GuillaumeGomez rustdoc: render attributes in Field and Variants sections Follow up to rust-lang/rust#145782. Render attributes in Field and Variants sections. Associated constants and methods are already rendered with attributes in their sections, so I figured out fields and variants should too. (no change here) <img width="378" height="265" alt="image" src="https://github.com/user-attachments/assets/b4f45c42-0146-486e-8881-138d2a7ad1c4" /> r? `@GuillaumeGomez` --- Before (left) / after (right): <img width="396" height="519" alt="image" src="https://github.com/user-attachments/assets/18288e13-09e7-448c-ba98-2023fa6df597" /> <img width="382" height="597" alt="image" src="https://github.com/user-attachments/assets/e624dc84-d169-41cc-bb89-7a1c2b2bb3e3" /> <img width="371" height="313" alt="image" src="https://github.com/user-attachments/assets/29833645-0b93-4900-80a8-c5a1e0b541b4" /> <img width="371" height="331" alt="image" src="https://github.com/user-attachments/assets/d5ce4b9e-f7f1-4f36-8ac0-08b0b5077e48" /> <img width="362" height="309" alt="image" src="https://github.com/user-attachments/assets/0436a51d-29a5-4403-a27c-7697524f807a" /> <img width="357" height="332" alt="image" src="https://github.com/user-attachments/assets/9a759fc5-30e7-4bbb-a88a-a3e3d1ed02aa" />
2025-08-24Regression test for attributes on macro callsJonathan Brouwer-42/+302
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-08-24Auto merge of #145384 - ywxt:parallel-tests, r=jieyouxubors-18/+705
Add more tests for the parallel rustc At the moment, the parallel frontend test cases are severely lacking. Althought some reported issues have been resolved, they haven't been added into the tests. This PR arranges the resolved ICE issues and adds tests for them. Whether it is worthwhile to add a separate test suite for the paralel frontend still requires futher discussion. But we are trying coveraging issues being resolved through capability of the existing UI test suite. Discussion: [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/233931-t-compiler.2Fmajor-changes/topic/Proposal.20for.20a.20dedicated.20test.20suite.20for.20t.E2.80.A6.20compiler-team.23906) Related issues: - rust-lang/rust#120760 - rust-lang/rust#124423 fixed by rust-lang/rust#140358 - rust-lang/rust#127971 fxied by rust-lang/rust#140358 - rust-lang/rust#120601 fixed by rust-lang/rust#127311 cc `@jieyouxu`
2025-08-24coverage: Build an "expansion tree" and use it to unexpand raw spansZalathar-21/+27
2025-08-24coverage: Add a specific test for `#[rustfmt::skip]`Zalathar-0/+47
2025-08-24rustdoc: render attributes in Field and Variants sectionsKarol Zwolak-0/+4
2025-08-24fix ICE on stable related to attrs on macrosJana Dönszelmann-1/+46
2025-08-24Port crate name to the new attribute systemJana Dönszelmann-99/+106
2025-08-24Support lints in early attribute parsingJana Dönszelmann-27/+40
2025-08-23Remove arm::t32-specific function pointer test.Zachary S-19/+3
All function pointers are currently treated as unaligned anyway; any change implementing function pointer alignment during consteval should add tests that it works properly on arm::t32 functions.
2025-08-23Rollup merge of #145798 - compiler-errors:unnamed-lt-primary, r=lqdJacob Pratt-119/+116
Use unnamed lifetime spans as primary spans for `MISMATCHED_LIFETIME_SYNTAXES` Fixes https://github.com/rust-lang/rust/issues/145772 This PR changes the primary span(s) of the `MISMATCHED_LIFETIME_SYNTAXES` to point to the *unnamed* lifetime spans in both the inputs and *outputs* of the function signature. As reported in rust-lang/rust#145772, this should make it so that IDEs highlight the spans of the actionable part of this lint, rather than just the (possibly named) input spans like they do today. This could be tweaked further perhaps, for example for `fn foo(_: T<'_>) -> T`, we don't need to highlight the elided lifetime if the actionable part is to change only the return type to `T<'_>`, but I think it's improvement on what's here today, so I think that should be follow-up since I think the logic might get a bit hairy. cc ```@shepmaster```
2025-08-23Rollup merge of #144531 - Urgau:int_to_ptr_transmutes, r=jackh726Jacob Pratt-0/+302
Add lint against integer to pointer transmutes # `integer_to_ptr_transmutes` *warn-by-default* The `integer_to_ptr_transmutes` lint detects integer to pointer transmutes where the resulting pointers are undefined behavior to dereference. ### Example ```rust fn foo(a: usize) -> *const u8 { unsafe { std::mem::transmute::<usize, *const u8>(a) } } ``` ``` warning: transmuting an integer to a pointer creates a pointer without provenance --> a.rs:1:9 | 158 | std::mem::transmute::<usize, *const u8>(a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: this is dangerous because dereferencing the resulting pointer is undefined behavior = note: exposed provenance semantics can be used to create a pointer based on some previously exposed provenance = help: if you truly mean to create a pointer without provenance, use `std::ptr::without_provenance_mut` = help: for more information about transmute, see <https://doc.rust-lang.org/std/mem/fn.transmute.html#transmutation-between-pointers-and-integers> = help: for more information about exposed provenance, see <https://doc.rust-lang.org/std/ptr/index.html#exposed-provenance> = note: `#[warn(integer_to_ptr_transmutes)]` on by default help: use `std::ptr::with_exposed_provenance` instead to use a previously exposed provenance | 158 - std::mem::transmute::<usize, *const u8>(a) 158 + std::ptr::with_exposed_provenance::<u8>(a) | ``` ### Explanation Any attempt to use the resulting pointers are undefined behavior as the resulting pointers won't have any provenance. Alternatively, `std::ptr::with_exposed_provenance` should be used, as they do not carry the provenance requirement or if the wanting to create pointers without provenance `std::ptr::without_provenance_mut` should be used. See [std::mem::transmute] in the reference for more details. [std::mem::transmute]: https://doc.rust-lang.org/std/mem/fn.transmute.html -------- People are getting tripped up on this, see https://github.com/rust-lang/rust/issues/128409 and https://github.com/rust-lang/rust/issues/141220. There are >90 cases like these on [GitHub search](https://github.com/search?q=lang%3Arust+%2Ftransmute%3A%3A%3Cu%5B0-9%5D*.*%2C+%5C*const%2F&type=code). Fixes https://github.com/rust-lang/rust-clippy/issues/13140 Fixes https://github.com/rust-lang/rust/issues/141220 Fixes https://github.com/rust-lang/rust/issues/145523 `@rustbot` labels +I-lang-nominated +T-lang cc `@traviscross` r? compiler
2025-08-23Auto merge of #145796 - samueltardieu:rollup-linfi86, r=samueltardieubors-82/+254
Rollup of 14 pull requests Successful merges: - rust-lang/rust#143898 (opt-dist: rebuild rustc when doing static LLVM builds) - rust-lang/rust#144452 (std/sys/fd: Relax `READ_LIMIT` on Darwin) - rust-lang/rust#145234 (match exhaustiveness diagnostics: show a trailing comma on singleton tuple consructors in witness patterns (and clean up a little)) - rust-lang/rust#145515 (Optimize `char::encode_utf8`) - rust-lang/rust#145540 (interpret/allocation: get_range on ProvenanceMap) - rust-lang/rust#145670 (port `sanitize` attribute to the new parsing infrastructure) - rust-lang/rust#145713 (next-solver: fix `feature(const_trait_impl)` bootstrap) - rust-lang/rust#145729 (Remove two duplicated crates) - rust-lang/rust#145744 (miri: also detect aliasing of in-place argument and return place) - rust-lang/rust#145774 (Remove default opts from config) - rust-lang/rust#145781 (Remove profile section from Clippy) - rust-lang/rust#145782 (rustdoc: make attributes render consistently) - rust-lang/rust#145787 (citool: cleanup `mismatched_lifetime_syntaxes` warnings) - rust-lang/rust#145791 (Fix ICE when validating transmuting ZST to inhabited enum) r? `@ghost` `@rustbot` modify labels: rollup
2025-08-23Use unnamed lifetime spans as primary spans for MISMATCHED_LIFETIME_SYNTAXESMichael Goulet-119/+116
2025-08-24Prefer verbose suggestions for `integer_to_ptr_transmutes` lintUrgau-36/+72
2025-08-24Allow `integer_to_ptr_transmutes` in testsUrgau-0/+1
2025-08-24Add lint against integer to pointer transmutesUrgau-0/+265
2025-08-23Rollup merge of #145791 - samueltardieu:fix-zst-to-enum-mir-validation, ↵Samuel Tardieu-0/+26
r=compiler-errors Fix ICE when validating transmuting ZST to inhabited enum MIR validation attempts to determine the number of bytes needed to represent the size of the source type to compute the discriminant for the inhabited target enum. For a ZST source, there is no source data to use as a discriminant so no proper runtime check can be generated. Since that should never be possible, insert a delayed bug to ensure the problem has been properly reported to the user by the type checker. Fixes rust-lang/rust#145786
2025-08-23Rollup merge of #145782 - ↵Samuel Tardieu-10/+71
karolzwolak:rustdoc-consistent-attributes-rendering, r=GuillaumeGomez rustdoc: make attributes render consistently While working on rust-lang/rust#132304, I discovered that even standard attributes aren't consistently rendered. For some constructs/fields, attributes were missing entirely, and the attributes were only sometimes wrapped in a code-attribute divs so they appear greyed out. In short this PR: * makes attributes render inside code elements and inside divs with class `code-attribute` * renders attributes for macros, associated constants, and struct/union fields Attributes in `Fields` and `Variants` sections are still not rendered (see struct and enum screenshots), because I wasn't sure we want that. [Compirison of tests/rustdoc/attributes.rs](https://github.com/karolzwolak/rust/blob/90aa25a1c5dbae1e94099b1a2015dfb83783dbe0/tests/rustdoc/attributes.rs) Before (left) / after (right): <img width="279" height="97" alt="image" src="https://github.com/user-attachments/assets/baca4b75-f809-4a76-8ac1-e3aa6389aad4" /> <img width="363" height="112" alt="image" src="https://github.com/user-attachments/assets/14970fb0-6fe5-474f-983e-5a95e16175c5" /> <img width="368" height="492" alt="image" src="https://github.com/user-attachments/assets/f9a25583-10e3-49c7-961b-34f3587b552e" /> <img width="415" height="515" alt="image" src="https://github.com/user-attachments/assets/f2fe4aa0-c731-4f2f-a3c2-04e524a858d1" /> <img width="383" height="483" alt="image" src="https://github.com/user-attachments/assets/bccc1b6e-f236-4948-8557-f9b25cad8a07" /> <img width="402" height="528" alt="image" src="https://github.com/user-attachments/assets/2cea9250-37e1-439e-8010-0603905d0f52" /> <img width="372" height="485" alt="image" src="https://github.com/user-attachments/assets/cd49bc0a-90e1-4d08-af0f-084c42af1834" /> <img width="406" height="542" alt="image" src="https://github.com/user-attachments/assets/67fb4ac7-746b-4e20-9c80-97702a71def8" /> <img width="357" height="131" alt="image" src="https://github.com/user-attachments/assets/42769532-1e4d-486d-bdca-6ecc409554b9" /> <img width="366" height="161" alt="image" src="https://github.com/user-attachments/assets/0b4d01d4-dd8e-4467-8cfc-ad58200ba0d7" /> <img width="291" height="65" alt="image" src="https://github.com/user-attachments/assets/43f61335-8eff-491b-a297-1953d17bbfc0" /> <img width="259" height="57" alt="image" src="https://github.com/user-attachments/assets/598618a3-e52f-4a4e-b790-2c8d5f1b4c77" /> r? ``@GuillaumeGomez``
2025-08-23Rollup merge of #145713 - lcnr:const-trait-bootstrap, r=compiler-errorsSamuel Tardieu-0/+53
next-solver: fix `feature(const_trait_impl)` bootstrap rarw r? ``@compiler-errors`` ``@fee1-dead``
2025-08-23Rollup merge of #145670 - jdonszelmann:port-sanitize, r=lcnrSamuel Tardieu-64/+96
port `sanitize` attribute to the new parsing infrastructure
2025-08-23Rollup merge of #145234 - dianne:1-tuple-witnesses, r=jackh726Samuel Tardieu-8/+8
match exhaustiveness diagnostics: show a trailing comma on singleton tuple consructors in witness patterns (and clean up a little) Constructor patterns of type `(T,)` are written `(pat,)`, not `(pat)`. However, exhaustiveness/usefulness diagnostics would print them as `(pat)` when e.g. providing a witness of non-exhaustiveness and suggesting adding arms to make matches exhaustive; this would result in an error when applied. rust-analyzer already prints the trailing comma, so it doesn't need changing. This also includes some cleanup in the second commit, with justification in the commit message.
2025-08-23Auto merge of #145706 - lcnr:uniquification, r=BoxyUwUbors-11/+9
change HIR typeck region uniquification handling approach rust-lang/rust#144405 causes structural lookup of opaque types to not work during HIR typeck, so instead avoid uniquifying goals and instead only reprove them if MIR borrowck actually encounters an error. This doesn't perfectly maintain the property that HIR typeck succeeding implies that MIR typeck succeeds, instead weakening this check to only guarantee that HIR typeck implies that MIR typeck succeeds modulo region uniquification. This means we still get the actually desirable ICEs if we MIR building is broken or we forget to check some property in HIR typeck, without having to deal with the fallout of uniquification in HIR typeck itself. We report errors using the original obligation sources of HIR typeck so diagnostics aren't that negatively impacted either. Here's the history of region uniquification while working on the new trait solver: - rust-lang/rust#107981 - rust-lang/rust#110180 - rust-lang/rust#114117 - rust-lang/rust#130821 - rust-lang/rust#144405 - rust-lang/rust#145706 <- we're here :tada: r? `@BoxyUwU`
2025-08-23Fix ICE when validating transmuting ZST to inhabited enumSamuel Tardieu-0/+26
MIR validation attempts to determine the number of bytes needed to represent the size of the source type to compute the discriminant for the inhabited target enum. For a ZST source, there is no source data to use as a discriminant so no proper runtime check can be generated. Since that should never be possible, insert a delayed bug to ensure the problem has been properly reported to the user by the type checker.
2025-08-23Implement some more checks for `ptr_guaranteed_cmp` in consteval:Zachary S-30/+208
Pointers with different residues modulo their least common allocation alignment are never equal. Pointers to the same static allocation are equal if and only if they have the same offset. Strictly in-bounds (in-bounds and not one-past-the-end) pointers to different static allocations are always unequal. A pointer cannot be equal to an integer if `ptr-int` cannot be null. Also adds more tests for `ptr_guaranteed_cmp`. Co-authored-by: Ralf Jung <post@ralfj.de>
2025-08-23Account for impossible bounds making seemingly unsatisfyable dyn-to-dyn castsMichael Goulet-0/+16