about summary refs log tree commit diff
path: root/tests
AgeCommit message (Collapse)AuthorLines
2024-12-07Auto merge of #133978 - matthiaskrgr:rollup-6gh1iho, r=matthiaskrgrbors-81/+64
Rollup of 7 pull requests Successful merges: - #130209 (Stabilize `std::io::ErrorKind::CrossesDevices`) - #130254 (Stabilize `std::io::ErrorKind::QuotaExceeded`) - #132187 (Add Extend impls for tuples of arity 1 through 12) - #133875 (handle `--json-output` properly) - #133934 (Do not implement unsafe auto traits for types with unsafe fields) - #133954 (Hide errors whose suggestions would contain error constants or types) - #133960 (rustdoc: remove eq for clean::Attributes) r? `@ghost` `@rustbot` modify labels: rollup
2024-12-07Auto merge of #133883 - saethlin:remove-polymorphization, r=compiler-errorsbors-1985/+7
Remove polymorphization This PR removes the flag `-Zpolymorphize` and all the infrastructure in the compiler that exists only to support it, per https://github.com/rust-lang/compiler-team/issues/810.
2024-12-06Auto merge of #118159 - EliasHolzmann:formatting_options, r=m-ou-sebors-8/+8
Implementation of `fmt::FormattingOptions` Tracking issue: #118117 Public API: ```rust #[derive(Copy, Clone, Debug, PartialEq, Eq)] pub struct FormattingOptions { … } #[derive(Copy, Clone, Debug, PartialEq, Eq)] pub enum Sign { Plus, Minus } #[derive(Copy, Clone, Debug, PartialEq, Eq)] pub enum DebugAsHex { Lower, Upper } impl FormattingOptions { pub fn new() -> Self; pub fn sign(&mut self, sign: Option<Sign>) -> &mut Self; pub fn sign_aware_zero_pad(&mut self, sign_aware_zero_pad: bool) -> &mut Self; pub fn alternate(&mut self, alternate: bool) -> &mut Self; pub fn fill(&mut self, fill: char) -> &mut Self; pub fn align(&mut self, alignment: Option<Alignment>) -> &mut Self; pub fn width(&mut self, width: Option<usize>) -> &mut Self; pub fn precision(&mut self, precision: Option<usize>) -> &mut Self; pub fn debug_as_hex(&mut self, debug_as_hex: Option<DebugAsHex>) -> &mut Self; pub fn get_sign(&self) -> Option<Sign>; pub fn get_sign_aware_zero_pad(&self) -> bool; pub fn get_alternate(&self) -> bool; pub fn get_fill(&self) -> char; pub fn get_align(&self) -> Option<Alignment>; pub fn get_width(&self) -> Option<usize>; pub fn get_precision(&self) -> Option<usize>; pub fn get_debug_as_hex(&self) -> Option<DebugAsHex>; pub fn create_formatter<'a>(self, write: &'a mut (dyn Write + 'a)) -> Formatter<'a>; } impl<'a> Formatter<'a> { pub fn new(write: &'a mut (dyn Write + 'a), options: FormattingOptions) -> Self; pub fn with_options<'b>(&'b mut self, options: FormattingOptions) -> Formatter<'b>; pub fn sign(&self) -> Option<Sign>; pub fn options(&self) -> FormattingOptions; } ``` Relevant changes from the public API in the tracking issue (I'm leaving out some stuff I consider obvious mistakes, like missing `#[derive(..)]`s and `pub` specifiers): - `enum DebugAsHex`/`FormattingOptions::debug_as_hex`/`FormattingOptions::get_debug_as_hex`: To support `{:x?}` as well as `{:X?}`. I had completely missed these options in the ACP. I'm open for any and all bikeshedding, not married to the name. - `fill`/`get_fill` now takes/returns `char` instead of `Option<char>`. This simply mirrors what `Formatter::fill` returns (with default being `' '`). - Changed `zero_pad`/`get_zero_pad` to `sign_aware_zero_pad`/`get_sign_aware_zero_pad`. This also mirrors `Formatter::sign_aware_zero_pad`. While I'm not a fan of this quite verbose name, I do believe that having the interface of `Formatter` and `FormattingOptions` be compatible is more important. - For the same reason, renamed `alignment`/`get_alignment` to `aling`/`get_align`. - Deviating from my initial idea, `Formatter::with_options` returns a `Formatter` which has the lifetime of the `self` reference as its generic lifetime parameter (in the original API spec, the generic lifetime of the returned `Formatter` was the generic lifetime used by `self` instead). Otherwise, one could construct two `Formatter`s that both mutably borrow the same underlying buffer, which would be unsound. This solution still has performance benefits over simply using `Formatter::new`, so I believe it is worthwhile to keep this method.
2024-12-06Remove polymorphizationBen Kimock-1985/+7
2024-12-06Rollup merge of #133954 - oli-obk:push-lxrmszqzszzu, r=jieyouxuMatthias Krüger-81/+4
Hide errors whose suggestions would contain error constants or types best reviewed commit-by-commit. This is work towards cleaning up everything around `lit_to_const` and its mir equivalent. fixes #123809
2024-12-06Rollup merge of #133934 - jswrenn:unsafe-fields-auto-traits, r=compiler-errorsMatthias Krüger-0/+60
Do not implement unsafe auto traits for types with unsafe fields If a type has unsafe fields, its safety invariants are not simply the conjunction of its field types' safety invariants. Consequently, it's invalid to reason about the safety properties of these types in a purely structural manner — i.e., the manner in which `auto` traits are implemented. Consequently, auto implementations of unsafe auto traits should not be generated for types with unsafe fields. Tracking: #132922 r? `@compiler-errors`
2024-12-06Auto merge of #133089 - eholk:stabilize-noop-waker, r=dtolnaybors-112/+95
Stabilize noop_waker Tracking Issue: #98286 This is a handy feature that's been used widely in tests and example async code and it'd be nice to make it available to users. cc `@rust-lang/wg-async`
2024-12-06Hide errors whose suggestions would contain error constants or typesOli Scherer-6/+0
2024-12-06Silence follow-up errors from `lit_to_const`Oli Scherer-77/+6
2024-12-06Rollup merge of #130777 - azhogin:azhogin/reg-struct-return, r=workingjubileeMatthias Krüger-0/+235
rust_for_linux: -Zreg-struct-return commandline flag for X86 (#116973) Command line flag `-Zreg-struct-return` for X86 (32-bit) for rust-for-linux. This flag enables the same behavior as the `abi_return_struct_as_int` target spec key. - Tracking issue: https://github.com/rust-lang/rust/issues/116973
2024-12-06Auto merge of #133559 - ↵bors-34/+42
compiler-errors:structurally-resolve-adjust-for-branch, r=lcnr Structurally resolve in `adjust_for_branches` r? lcnr
2024-12-05do not implement unsafe auto traits for types with unsafe fieldsJack Wrenn-0/+60
If a type has unsafe fields, its safety invariants are not simply the conjunction of its field types' safety invariants. Consequently, it's invalid to reason about the safety properties of these types in a purely structural manner — i.e., the manner in which `auto` traits are implemented. Makes progress towards #132922.
2024-12-05Rollup merge of #133921 - TimNN:nuw-infer, r=nikicGuillaume Gomez-15/+15
Adapt codegen tests for NUW inference These were broken by https://github.com/llvm/llvm-project/commit/462cb3cd6cecd0511ecaf0e3ebcaba455ece587d Let me know if you think we should have a FIXME / tracking issue to update the tests after the LLVM 20 upgrade to make these required. `@rustbot` label: +llvm-main r? `@nikic`
2024-12-05Rollup merge of #133910 - TimNN:llvm-target-cpus, r=jieyouxuGuillaume Gomez-0/+6
Normalize target-cpus.rs stdout test for LLVM changes LLVM has recently added support for the `lime1` CPU in https://github.com/llvm/llvm-project/commit/35cce408eef1a253df12c0023c993d78b180b1f3, so the `target-cpus.rs` test currently produces different output depending on the LLVM version. This CL adds a normalization directive, to remove the new CPU from the output list. Alternatives fixes I can think of: * Add two revisions of the test (one per LLVM version) * Ignore the test on one of the LLVM versions * I dislike this, because it's possible that the test won't get updated for the next LLVM version. I don't think the exact list of target CPUs is relevant for this test, so it shouldn't be too bad if the normalization sticks around longer than necessary. `@rustbot` label: +llvm-main
2024-12-05Rollup merge of #133821 - Kobzol:replace-black-with-ruff, r=onur-ozkanGuillaume Gomez-0/+9
Replace black with ruff in `tidy` `ruff` can both lint and format Python code (in fact, it should be a mostly drop-in replacement for `black` in terms of formatting), so it's not needed to use `black` anymore. This PR removes `black` and replaces it with `ruff`, to get rid of one Python dependency, and also to make Python formatting faster (although that's a small thing). If we decide to merge this, we'll need to "reformat the world" - `ruff` is not perfectly compatible with `black`, and it also looks like `black` was actually ignoring some files before. I tried it locally (`./x test tidy --extra-checks=py:fmt --bless`) and it also reformatted some code in subtrees (e.g. `clippy` or `rustc_codegen_gcc`) - I'm not sure how to handle that.
2024-12-05Rollup merge of #133607 - WaffleLapkin:tail-call-checks, r=compiler-errorsGuillaume Gomez-12/+461
implement checks for tail calls Quoting the [RFC draft](https://github.com/phi-go/rfcs/blob/guaranteed-tco/text/0000-explicit-tail-calls.md): > The argument to become is a function (or method) call, that exactly matches the function signature and calling convention of the callee. The intent is to ensure a matching ABI. Note that lifetimes may differ as long as they pass borrow checking, see [below](https://github.com/phi-go/rfcs/blob/guaranteed-tco/text/0000-explicit-tail-calls.md#return-type-coercion) for specifics on the return type. > Tail calling closures and tail calling from closures is not allowed. This is due to the high implementation effort, see below, this restriction can be lifted by a future RFC. > Invocations of operators were considered as valid targets but were rejected on grounds of being too error-prone. In any case, these can still be called as methods. > Tail calling [variadic functions](https://doc.rust-lang.org/beta/unstable-book/language-features/c-variadic.html) and tail calling from variadic functions is not allowed. As support for variadic function is stabilized on a per target level, support for tail-calls regarding variadic functions would need to follow a similar approach. To avoid this complexity and to minimize implementation effort for backends, this interaction is currently not allowed but support can be added with a future RFC. ----- The checks are implemented as a query, similarly to `check_unsafety`. The code is cherry-picked straight out of #112657 which was written more than a year ago, so I expect we might need to change some things ^^"
2024-12-05Stabilize noop_wakerEric Holk-112/+95
Co-authored-by: zachs18 <8355914+zachs18@users.noreply.github.com>
2024-12-05Update GUI test after rebaseGuillaume Gomez-7/+3
2024-12-05Improve positioning of "..." in collapsed impl blockGuillaume Gomez-2/+33
2024-12-05Update GUI testsGuillaume Gomez-2/+2
2024-12-05Add GUI test for impl block doc displayGuillaume Gomez-0/+50
2024-12-05Access members of `FormattingOptions` directly instead of via getters/settersElias Holzmann-146/+148
2024-12-05Fixed funky_arms (broken mir-opt test due to refactoring fmt::FormattingOptions)Elias Holzmann-208/+144
2024-12-05Fixed mir-opt test broken because of `std::Formatter` changesElias Holzmann-28/+90
2024-12-05Adapt codegen tests for NUW inferenceTim Neumann-15/+15
2024-12-05Normalize target-cpus.rs stdout test for LLVM changesTim Neumann-0/+6
2024-12-05Auto merge of #133893 - fmease:rollup-11pi6fg, r=fmeasebors-487/+1381
Rollup of 10 pull requests Successful merges: - #118833 (Add lint against function pointer comparisons) - #122161 (Fix suggestion when shorthand `self` has erroneous type) - #133233 (Add context to "const in pattern" errors) - #133761 (Update books) - #133843 (Do not emit empty suggestion) - #133863 (Rename `core_pattern_type` and `core_pattern_types` lib feature gates to `pattern_type_macro`) - #133872 (No need to create placeholders for GAT args in confirm_object_candidate) - #133874 (`fn_sig_for_fn_abi` should return a `ty::FnSig`, no need for a binder) - #133890 (Add a new test ui/incoherent-inherent-impls/no-other-unrelated-errors to check E0116 does not cause unrelated errors) - #133892 (Revert #133817) r? `@ghost` `@rustbot` modify labels: rollup
2024-12-05Rollup merge of #133890 - kei519:fix-125814, r=compiler-errorsLeón Orell Valerian Liehr-0/+19
Add a new test ui/incoherent-inherent-impls/no-other-unrelated-errors to check E0116 does not cause unrelated errors rustc xxx (we do not know) to 1.82.0 emits unrelated errors when E0116 is present (see #125814). We do not know what caused and fixed it, but add a test to confirm rustc does not cause the same error in the future.
2024-12-05Rollup merge of #133863 - oli-obk:push-pystoxvtvssx, r=lqdLeón Orell Valerian Liehr-60/+48
Rename `core_pattern_type` and `core_pattern_types` lib feature gates to `pattern_type_macro` That's what the gates are actually gating, and the single char difference in naming was not helpful either fixes #128987
2024-12-05Rollup merge of #133843 - estebank:empty-semi-sugg, r=jieyouxuLeón Orell Valerian Liehr-0/+76
Do not emit empty suggestion The `println!();` statement's span doesn't include the `;`, and the modified suggestions where trying to get the `;` by getting the differenece between the statement's and the expression's spans, which was an empty suggestion. Fix #133833, fix #133834.
2024-12-05Rollup merge of #133233 - estebank:const-errors, r=NadrierilLeón Orell Valerian Liehr-427/+810
Add context to "const in pattern" errors *Each commit addresses specific diagnostics.* - Add primary span labels - Point at `const` item, and `const` generic param definition - Reword messages and notes - Point at generic param through which an associated `const` is being referenced - Silence const in pattern with evaluation errors when they come from `const` items that already emit a diagnostic - On non-structural type in const used as pattern, point at the type that should derive `PartialEq`
2024-12-05Rollup merge of #122161 - compiler-errors:shorthand-self, r=fmeaseLeón Orell Valerian Liehr-0/+64
Fix suggestion when shorthand `self` has erroneous type Fixes #122086 r? estebank
2024-12-05Rollup merge of #118833 - Urgau:lint_function_pointer_comparisons, r=cjgillotLeón Orell Valerian Liehr-0/+364
Add lint against function pointer comparisons This is kind of a follow-up to https://github.com/rust-lang/rust/pull/117758 where we added a lint against wide pointer comparisons for being ambiguous and unreliable; well function pointer comparisons are also unreliable. We should IMO follow a similar logic and warn people about it. ----- ## `unpredictable_function_pointer_comparisons` *warn-by-default* The `unpredictable_function_pointer_comparisons` lint checks comparison of function pointer as the operands. ### Example ```rust fn foo() {} let a = foo as fn(); let _ = a == foo; ``` ### Explanation Function pointers comparisons do not produce meaningful result since they are never guaranteed to be unique and could vary between different code generation units. Furthermore different function could have the same address after being merged together. ---- This PR also uplift the very similar `clippy::fn_address_comparisons` lint, which only linted on if one of the operand was an `ty::FnDef` while this PR lints proposes to lint on all `ty::FnPtr` and `ty::FnDef`. ```@rustbot``` labels +I-lang-nominated ~~Edit: Blocked on https://github.com/rust-lang/libs-team/issues/323 being accepted and it's follow-up pr~~
2024-12-05Auto merge of #133828 - compiler-errors:incr-sad, r=lcnrbors-0/+25
Make sure to record deps from cached task in new solver on first run We weren't actually performing a read of the dep node in `with_cached_task` in the new solver, which meant that all queries that computed a goal for the first time were just not recording the query dependencies that we call in that query. In the incremental test, the typeck query for `fn poll` isn't being marked red even tho it's invalidated due to its writeback results changing. This happens b/c we normalize `Self::Error` into `Error`, which should call `type_of` which is a red query (since `ty::Adt` contains an `AdtDef`, and that `AdtDef`'s stable hash changes since it's ). However, since we weren't tracking deps in that normalize query, the typeck result was remaining green, and we were trying to decode a def id that no longer exists (the field that got removed). r? lcnr
2024-12-05Add a new test ui/incoherent-inherent-impls/no-other-unrelated-errors to ↵kei519-0/+19
check E0116 does not cause unrelated errors rustc xxx (we do not know) to 1.82.0 emits unrelated errors when E0116 is present (see #125814). We do not know what caused and fixed it, but add a test to confirm rustc does not cause the same error in the future.
2024-12-05Resolve moreMichael Goulet-34/+34
2024-12-04Reformat Python code with `ruff`Jakub Beránek-0/+9
2024-12-04review comments: reword messages and simplify logicEsteban Küber-25/+25
2024-12-04fix testEsteban Küber-7/+1
2024-12-04Add more context to fall-through "const pattern of non-structural type" errorEsteban Küber-4/+12
Point at types that need to be marked with `#[derive(PartialEq)]`. We use a visitor to look at a type that isn't structural, looking for all ADTs that don't derive `PartialEq`. These can either be manual `impl PartialEq`s or no `impl` at all, so we differentiate between those two cases to provide more context to the user. We also only point at types and impls from the local crate, otherwise show only a note. ``` error: constant of non-structural type `&[B]` in a pattern --> $DIR/issue-61188-match-slice-forbidden-without-eq.rs:15:9 | LL | struct B(i32); | -------- must be annotated with `#[derive(PartialEq)]` to be usable in patterns LL | LL | const A: &[B] = &[]; | ------------- constant defined here ... LL | A => (), | ^ constant of non-structural type | = note: see https://doc.rust-lang.org/stable/std/marker/trait.StructuralPartialEq.html for details ```
2024-12-04Add context to fall-through "const pattern of non-structural type" errorEsteban Küber-0/+12
Unify wording with the regular non-structural type error.
2024-12-04Add additional context for non-sructural type constant used in patternEsteban Küber-164/+312
- Point at type that should derive `PartialEq` to be structural. - Point at manual `impl PartialEq`, explaining that it is not sufficient to be structural. ``` error: constant of non-structural type `MyType` in a pattern --> $DIR/const-partial_eq-fallback-ice.rs:14:12 | LL | struct MyType; | ------------- `MyType` must be annotated with `#[derive(PartialEq)]` to be usable in patterns ... LL | const CONSTANT: &&MyType = &&MyType; | ------------------------ constant defined here ... LL | if let CONSTANT = &&MyType { | ^^^^^^^^ constant of non-structural type | note: the `PartialEq` trait must be derived, manual `impl`s are not sufficient; see https://doc.rust-lang.org/stable/std/marker/trait.StructuralPartialEq.html for details --> $DIR/const-partial_eq-fallback-ice.rs:5:1 | LL | impl PartialEq<usize> for MyType { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ```
2024-12-04Reword message for non-structural type constant in patternEsteban Küber-9/+8
2024-12-04Specify type kind of constant that can't be used in patternsEsteban Küber-14/+14
``` error: trait object `dyn Send` cannot be used in patterns --> $DIR/issue-70972-dyn-trait.rs:6:9 | LL | const F: &'static dyn Send = &7u32; | -------------------------- constant defined here ... LL | F => panic!(), | ^ trait object can't be used in patterns ```
2024-12-04Tweak output of some const pattern errorsEsteban Küber-19/+28
- Add primary span labels. - Point at const generic parameter used as pattern. - Point at statics used as pattern. - Point at let bindings used in const pattern.
2024-12-04Point at generic param through which a const is used in a patternEsteban Küber-18/+35
``` error[E0158]: constant pattern depends on a generic parameter, which is not allowed --> $DIR/associated-const-type-parameter-pattern.rs:20:9 | LL | pub trait Foo { | ------------- LL | const X: EFoo; | ------------- constant defined here ... LL | pub fn test<A: Foo, B: Foo>(arg: EFoo) { | - constant depends on this generic param LL | match arg { LL | A::X => println!("A::X"), | ^^^^ `const` depends on a generic parameter ```
2024-12-04Tweak ptr in pattern errorEsteban Küber-52/+104
Conform to error style guide.
2024-12-04Tweak unevaluated constant in pattern errorEsteban Küber-164/+25
Silence errors that are implied by the errors in the `const` item definition. Add a primary span label.
2024-12-04On `const` pattern errors, point at the `const` item definitionEsteban Küber-10/+293
Centralize emitting an error in `const_to_pat` so that all errors from that evaluating a `const` in a pattern can add addditional information. With this, now point at the `const` item's definition: ``` error[E0158]: constant pattern depends on a generic parameter --> $DIR/associated-const-type-parameter-pattern.rs:20:9 | LL | pub trait Foo { | ------------- LL | const X: EFoo; | ------------- constant defined here ... LL | A::X => println!("A::X"), | ^^^^ ```
2024-12-04Fix suggestion when shorthand self has erroneous typeMichael Goulet-0/+64