about summary refs log tree commit diff
path: root/tests
AgeCommit message (Collapse)AuthorLines
2023-11-02Always do all the pattern checksNadrieril-4/+22
2023-11-02Add regression test for pattern checksNadrieril-0/+72
2023-11-02Tweak diagnostic for consistencyNadrieril-57/+109
2023-11-01Auto merge of #117029 - rmehri01:mir_opt_filecheck_inline_tests, r=cjgillotbors-51/+156
Add FileCheck annotations to MIR-opt inlining tests Part of #116971, adds FileCheck annotations to MIR-opt tests in `tests/mir-opt/inline`. I left out a few (such as `inline_cycle`) where it mentioned that the particular outcome of inlining isn't important, just that the inliner doesn't get stuck in an infinite loop. r? cjgillot
2023-11-01Auto merge of #117289 - estebank:issue-72298, r=cjgillotbors-0/+94
Account for `ref` and `mut` in the wrong place for pattern ident renaming If the user writes `S { ref field: name }` instead of `S { field: ref name }`, we suggest the correct code. Fix #72298.
2023-11-01fix spans for inline_couroutine panic-abortRyan Mehri-11/+11
2023-11-01Auto merge of #114208 - GKFX:offset_of_enum, r=wesleywiserbors-47/+294
Support enum variants in offset_of! This MR implements support for navigating through enum variants in `offset_of!`, placing the enum variant name in the second argument to `offset_of!`. The RFC placed it in the first argument, but I think it interacts better with nested field access in the second, as you can then write things like ```rust offset_of!(Type, field.Variant.field) ``` Alternatively, a syntactic distinction could be made between variants and fields (e.g. `field::Variant.field`) but I'm not convinced this would be helpful. [RFC 3308 # Enum Support](https://rust-lang.github.io/rfcs/3308-offset_of.html#enum-support-offset_ofsomeenumstructvariant-field_on_variant) Tracking Issue #106655.
2023-11-01Rollup merge of #115626 - clarfonthey:unchecked-math, r=thomccMatthias Krüger-2/+2
Clean up unchecked_math, separate out unchecked_shifts Tracking issue: #85122 Changes: 1. Remove `const_inherent_unchecked_arith` flag and make const-stability flags the same as the method feature flags. Given the number of other unsafe const fns already stabilised, it makes sense to just stabilise these in const context when they're stabilised. 2. Move `unchecked_shl` and `unchecked_shr` into a separate `unchecked_shifts` flag, since the semantics for them are unclear and they'll likely be stabilised separately as a result. 3. Add an `unchecked_neg` method exclusively to signed integers, under the `unchecked_neg` flag. This is because it's a new API and probably needs some time to marinate before it's stabilised, and while it *would* make sense to have a similar version for unsigned integers since `checked_neg` also exists for those there is absolutely no case where that would be a good idea, IMQHO. The longer-term goal here is to prepare the `unchecked_math` methods for an FCP and stabilisation since they've existed for a while, their semantics are clear, and people seem in favour of stabilising them.
2023-11-01Auto merge of #116692 - Nadrieril:half-open-ranges, r=cjgillotbors-198/+215
Match usize/isize exhaustively with half-open ranges The long-awaited finale to the saga of [exhaustiveness checking for integers](https://github.com/rust-lang/rust/pull/50912)! ```rust match 0usize { 0.. => {} // exhaustive! } match 0usize { 0..usize::MAX => {} // helpful error message! } ``` Features: - Half-open ranges behave as expected for `usize`/`isize`; - Trying to use `0..usize::MAX` will tell you that `usize::MAX..` is missing and explain why. No more unhelpful "`_` is missing"; - Everything else stays the same. This should unblock https://github.com/rust-lang/rust/issues/37854. Review-wise: - I recommend looking commit-by-commit; - This regresses perf because of the added complexity in `IntRange`; hopefully not too much; - I measured each `#[inline]`, they all help a bit with the perf regression (tho I don't get why); - I did not touch MIR building; I expect there's an easy PR there that would skip unnecessary comparisons when the range is half-open.
2023-11-01Auto merge of #113970 - cjgillot:assume-all-the-things, r=nikicbors-324/+390
Replace switch to unreachable by assume statements `UnreachablePropagation` currently keeps some switch terminators alive in order to ensure codegen can infer the inequalities on the discriminants. This PR proposes to encode those inequalities as `Assume` statements. This allows to simplify MIR further by removing some useless terminators.
2023-10-31Update based on wesleywiser reviewGeorge Bateman-3/+10
2023-10-31Update MIR tests for offset_ofGeorge Bateman-44/+44
2023-10-31Enums in offset_of: update based on est31, scottmcm & llogiq reviewGeorge Bateman-2/+27
2023-10-31Support enum variants in offset_of!George Bateman-29/+244
2023-10-31Auto merge of #117459 - matthiaskrgr:rollup-t3osb3c, r=matthiaskrgrbors-0/+182
Rollup of 5 pull requests Successful merges: - #113241 (rustdoc: Document lack of object safety on affected traits) - #117388 (Turn const_caller_location from a query to a hook) - #117417 (Add a stable MIR visitor) - #117439 (prepopulate opaque ty storage before using it) - #117451 (Add support for pre-unix-epoch file dates on Apple platforms (#108277)) r? `@ghost` `@rustbot` modify labels: rollup
2023-10-31change inline_retag to after.mirRyan Mehri-66/+60
2023-10-31Rollup merge of #117417 - celinval:smir-visitor, r=oli-obkMatthias Krüger-0/+148
Add a stable MIR visitor This change also adds a few utility functions as well and extend most `mir` and `ty` ADTs to implement `PartialEq` and `Eq`. Fixes https://github.com/rust-lang/project-stable-mir/issues/32 r? `@oli-obk`
2023-10-31Rollup merge of #113241 - poliorcetics:85138-doc-object-safety, r=GuillaumeGomezMatthias Krüger-0/+34
rustdoc: Document lack of object safety on affected traits Closes #85138 I saw the issue didn't have any recent activity, if there is another MR for it I missed it. I want the issue to move forward so here is my proposition. It takes some space just before the "Implementors" section and only if the trait is **not** object safe since it is the only case where special care must be taken in some cases and this has the benefit of avoiding generation of HTML in (I hope) the common case.
2023-10-31Auto merge of #117450 - oli-obk:rustdoc_verify, r=estebankbors-106/+423
Accept less invalid Rust in rustdoc pulled out of https://github.com/rust-lang/rust/pull/117213 where this change was already approved This only affects rustdoc, and has up to [20% perf regressions in rustdoc](https://github.com/rust-lang/rust/pull/117213#issuecomment-1785776288). These are unavoidable, as we are simply doing more checks now, but it's part of the longer term plan of making rustdoc more resistant to ICEs by only accepting valid Rust code.
2023-10-31Accept less invalid Rust in rustdocOli Scherer-106/+423
2023-10-31Auto merge of #117444 - matthiaskrgr:rollup-43s0spc, r=matthiaskrgrbors-3/+116
Rollup of 5 pull requests Successful merges: - #116267 (Some codegen cleanups around SIMD checks) - #116712 (When encountering unclosed delimiters during lexing, check for diff markers) - #117416 (Also consider TAIT to be uncomputable if the MIR body is tainted) - #117421 (coverage: Replace impossible `coverage::Error` with assertions) - #117438 (Do not ICE on constant evaluation failure in GVN.) r? `@ghost` `@rustbot` modify labels: rollup
2023-10-31Rollup merge of #117438 - cjgillot:deterministic-error, r=oli-obkMatthias Krüger-3/+26
Do not ICE on constant evaluation failure in GVN. Fixes https://github.com/rust-lang/rust/issues/117362
2023-10-31Rollup merge of #117416 - compiler-errors:tait-in-bad-body, r=oli-obkMatthias Krüger-0/+31
Also consider TAIT to be uncomputable if the MIR body is tainted Not totally sure if this is the best solution. We could, alternatively, look at the hir typeck results and try to take a type from there instead of just falling back to type error, inferring `u8` instead of `{type error}`. Not certain it really matters, though. Happy to iterate on this. Fixes #117413 r? ``@oli-obk`` cc ``@Nadrieril``
2023-10-31Rollup merge of #116712 - estebank:issue-116252, r=petrochenkovMatthias Krüger-0/+59
When encountering unclosed delimiters during lexing, check for diff markers Fix #116252.
2023-10-31FileCheck uninhabited_enum_branching.Camille GILLOT-245/+126
2023-10-31Only emit `!=` assumptions if the otherwise target is reachable.Camille GILLOT-51/+142
2023-10-31Refactor UninhabitedEnumBranching to mark targets unreachable.Camille GILLOT-6/+37
2023-10-31Simplify assume of a constant.Camille GILLOT-84/+62
2023-10-31Replace SwitchInt to unreachable by an assumption.Camille GILLOT-38/+93
2023-10-31Reorder passes.Camille GILLOT-33/+63
2023-10-31Do not ICE on constant evaluation failure in GVN.Camille GILLOT-3/+26
2023-10-31Auto merge of #117377 - dtolnay:deprecatedsince, r=cjgillotbors-26/+30
Store #[deprecated] attribute's `since` value in parsed form This PR implements the first followup bullet listed in https://github.com/rust-lang/rust/pull/117148#issue-1960240108. We centralize error handling to the attribute parsing code in `compiler/rustc_attr/src/builtin.rs`, and thereby remove some awkward error codepaths from later phases of compilation that had to make sense of these #\[deprecated\] attributes, namely `compiler/rustc_passes/src/stability.rs` and `compiler/rustc_middle/src/middle/stability.rs`.
2023-10-30Preserve deprecation attribute even if 'since' version is missingDavid Tolnay-3/+11
2023-10-30Auto merge of #116405 - estebank:issue-103155, r=davidtwcobors-181/+206
Detect object safety errors when assoc type is missing When an associated type with GATs isn't specified in a `dyn Trait`, emit an object safety error instead of only complaining about the missing associated type, as it will lead the user down a path of three different errors before letting them know that what they were trying to do is impossible to begin with. Fix #103155.
2023-10-30Sort errorsEsteban Küber-9/+9
2023-10-30Add testEsteban Küber-0/+25
2023-10-30Detect object safety errors when assoc type is missingEsteban Küber-181/+181
When an associated type with GATs isn't specified in a `dyn Trait`, emit an object safety error instead of only complaining about the missing associated type, as it will lead the user down a path of three different errors before letting them know that what they were trying to do is impossible to begin with. Fix #103155.
2023-10-30Auto merge of #117415 - matthiaskrgr:rollup-jr2p1t2, r=matthiaskrgrbors-50/+167
Rollup of 7 pull requests Successful merges: - #116862 (Detect when trait is implemented for type and suggest importing it) - #117389 (Some diagnostics improvements of `gen` blocks) - #117396 (Don't treat closures/coroutine types as part of the public API) - #117398 (Correctly handle nested or-patterns in exhaustiveness) - #117403 (Poison check_well_formed if method receivers are invalid to prevent typeck from running on it) - #117411 (Improve some diagnostics around `?Trait` bounds) - #117414 (Don't normalize to an un-revealed opaque when we hit the recursion limit) r? `@ghost` `@rustbot` modify labels: rollup
2023-10-30Also consider TAIT to be uncomputable if the MIR body is taintedMichael Goulet-0/+31
2023-10-30Add a stable MIR visitorCelina G. Val-0/+148
Add a few utility functions as well and extend most `mir` and `ty` ADTs to implement `PartialEq` and `Eq`.
2023-10-30Rollup merge of #117414 - compiler-errors:tait-forevert, r=oli-obkMatthias Krüger-0/+17
Don't normalize to an un-revealed opaque when we hit the recursion limit Currently, we will normalize `Opaque := Option<&Opaque>` to something like `Option<&Option<&Option<&...Opaque>>>`, hitting a limit and bottoming out in an unnormalized opaque after the recursion limit gets hit. Unfortunately, during `layout_of`, we'll simply recurse and try again if the type normalizes to something different than the type: https://github.com/rust-lang/rust/blob/e6e931dda5fffbae0fd87c5b1af753cc95556880/compiler/rustc_ty_utils/src/layout.rs#L58-L60 That means then we'll try to normalize `Option<&Option<&Option<&...Opaque>>>` again, substituting `Opaque` into itself even deeper. Eventually this will get to the point that we're just stack-overflowing on a really deep type before even hitting an opaque again. To fix this, we just bottom out into `ty::Error` instead of the unrevealed opaque type. Fixes #117412 r? `@oli-obk`
2023-10-30Rollup merge of #117411 - oli-obk:query_merge_immobile_game, ↵Matthias Krüger-31/+31
r=compiler-errors,Nilstrieb Improve some diagnostics around `?Trait` bounds * uses better spans * clarifies a message that was only talking about generic params, but applies to `dyn ?Trait` and `impl ?Trait` as well
2023-10-30Rollup merge of #117403 - oli-obk:the_gift_that_keeps_on_giving_116849, ↵Matthias Krüger-4/+19
r=compiler-errors Poison check_well_formed if method receivers are invalid to prevent typeck from running on it fixes #117379 Though if some code invokes typeck without having first invoked `check_well_formed` then we'll encounter this ICE again. This can happen in const and const fn bodies if they are evaluated due to other `check_well_formed` checks or similar
2023-10-30Rollup merge of #117398 - Nadrieril:fix-117378, r=compiler-errorsMatthias Krüger-0/+6
Correctly handle nested or-patterns in exhaustiveness I had assumed nested or-patterns were flattened, and they mostly are but not always. Fixes https://github.com/rust-lang/rust/issues/117378
2023-10-30Rollup merge of #117396 - oli-obk:privacy_visitor_types, r=compiler-errorsMatthias Krüger-0/+44
Don't treat closures/coroutine types as part of the public API Fixes a regression from https://github.com/rust-lang/rust/pull/117076 r? `@compiler-errors`
2023-10-30Rollup merge of #117389 - oli-obk:gen_fn, r=compiler-errorsMatthias Krüger-3/+41
Some diagnostics improvements of `gen` blocks These are leftovers from https://github.com/rust-lang/rust/pull/116447
2023-10-30Don't super-fold types when we hit the recursion limitMichael Goulet-0/+17
2023-10-30Improve some diagnostics around `?Trait` boundsOli Scherer-31/+31
2023-10-30Detect when trait is implemented for type and suggest importing itEsteban Küber-12/+9
Fix #57457.
2023-10-30Rollup merge of #117395 - gurry:117380-wrong-parent-sugg, r=NilstriebGuillaume Gomez-1/+89
Fix missing leading space in suggestion For a local pattern with no space between `let` and `(` e.g.: ```rust let(_a) = 3; ``` we were previously suggesting this illegal code: ```rust let_a = 3; ``` After this change the suggestion will instead be: ```rust let _a = 3; ``` Fixes #117380