about summary refs log tree commit diff
path: root/compiler
AgeCommit message (Collapse)AuthorLines
2024-04-25Auto merge of #124360 - matthiaskrgr:rollup-k6bffhd, r=matthiaskrgrbors-90/+79
Rollup of 3 pull requests Successful merges: - #124257 (Rewrite the `no-input-file.stderr` test in Rust and support diff) - #124324 (Minor AST cleanups) - #124327 (CI: implement job skipping in Python matrix calculation) r? `@ghost` `@rustbot` modify labels: rollup
2024-04-25Auto merge of #121298 - nikic:writable, r=cuviperbors-0/+27
Set writable and dead_on_unwind attributes for sret arguments Set the `writable` and `dead_on_unwind` attributes for `sret` arguments. This allows call slot optimization to remove more memcpy's. See https://llvm.org/docs/LangRef.html#parameter-attributes for the specification of these attributes. In short, the statement we're making here is that: * The return slot is writable. * The return slot will not be read if the function unwinds. Fixes https://github.com/rust-lang/rust/issues/90595.
2024-04-25Rollup merge of #124324 - nnethercote:minor-ast-cleanups, r=estebankMatthias Krüger-90/+79
Minor AST cleanups r? ``@estebank``
2024-04-25Set writable and dead_on_unwind attributes for sret argumentsNikita Popov-0/+27
2024-04-25Auto merge of #124136 - estebank:clone-o-rama-2, r=nnethercotebors-26/+213
Provide more context and suggestions in borrowck errors involving closures Start pointing to where bindings where declared when they are captured in closures: ``` error[E0597]: `x` does not live long enough --> $DIR/suggest-return-closure.rs:23:9 | LL | let x = String::new(); | - binding `x` declared here ... LL | |c| { | --- value captured here LL | x.push(c); | ^ borrowed value does not live long enough ... LL | } | -- borrow later used here | | | `x` dropped here while still borrowed ``` Suggest cloning in more cases involving closures: ``` error[E0507]: cannot move out of `foo` in pattern guard --> $DIR/issue-27282-move-ref-mut-into-guard.rs:11:19 | LL | if { (|| { let mut bar = foo; bar.take() })(); false } => {}, | ^^ --- move occurs because `foo` has type `&mut Option<&i32>`, which does not implement the `Copy` trait | | | `foo` is moved here | = note: variables bound in patterns cannot be moved from until after the end of the pattern guard help: consider cloning the value if the performance cost is acceptable | LL | if { (|| { let mut bar = foo.clone(); bar.take() })(); false } => {}, | ++++++++ ``` Mention when type parameter could be Clone ``` error[E0382]: use of moved value: `t` --> $DIR/use_of_moved_value_copy_suggestions.rs:7:9 | LL | fn duplicate_t<T>(t: T) -> (T, T) { | - move occurs because `t` has type `T`, which does not implement the `Copy` trait ... LL | (t, t) | - ^ value used here after move | | | value moved here | help: if `T` implemented `Clone`, you could clone the value --> $DIR/use_of_moved_value_copy_suggestions.rs:4:16 | LL | fn duplicate_t<T>(t: T) -> (T, T) { | ^ consider constraining this type parameter with `Clone` ... LL | (t, t) | - you could clone this value help: consider restricting type parameter `T` | LL | fn duplicate_t<T: Copy>(t: T) -> (T, T) { | ++++++ ``` The `help` is new. On ADTs, we also extend the output with span labels: ``` error[E0507]: cannot move out of static item `FOO` --> $DIR/issue-17718-static-move.rs:6:14 | LL | let _a = FOO; | ^^^ move occurs because `FOO` has type `Foo`, which does not implement the `Copy` trait | note: if `Foo` implemented `Clone`, you could clone the value --> $DIR/issue-17718-static-move.rs:1:1 | LL | struct Foo; | ^^^^^^^^^^ consider implementing `Clone` for this type ... LL | let _a = FOO; | --- you could clone this value help: consider borrowing here | LL | let _a = &FOO; | + ``` Suggest cloning captured binding in move closure ``` error[E0507]: cannot move out of `bar`, a captured variable in an `FnMut` closure --> $DIR/borrowck-move-by-capture.rs:9:29 | LL | let bar: Box<_> = Box::new(3); | --- captured outer variable LL | let _g = to_fn_mut(|| { | -- captured by this `FnMut` closure LL | let _h = to_fn_once(move || -> isize { *bar }); | ^^^^^^^^^^^^^^^^ ---- | | | | | variable moved due to use in closure | | move occurs because `bar` has type `Box<isize>`, which does not implement the `Copy` trait | `bar` is moved here | help: clone the value before moving it into the closure 1 | LL ~ let value = bar.clone(); LL ~ let _h = to_fn_once(move || -> isize { value }); | ```
2024-04-25Add comments about attribute tokens.Nicholas Nethercote-0/+2
This clarifies something that has puzzled me for some time.
2024-04-24Suggest cloning captured binding in `move` closureEsteban Küber-9/+146
``` error[E0507]: cannot move out of `bar`, a captured variable in an `FnMut` closure --> $DIR/borrowck-move-by-capture.rs:9:29 | LL | let bar: Box<_> = Box::new(3); | --- captured outer variable LL | let _g = to_fn_mut(|| { | -- captured by this `FnMut` closure LL | let _h = to_fn_once(move || -> isize { *bar }); | ^^^^^^^^^^^^^^^^ ---- | | | | | variable moved due to use in closure | | move occurs because `bar` has type `Box<isize>`, which does not implement the `Copy` trait | `bar` is moved here | help: clone the value before moving it into the closure | LL ~ let value = bar.clone(); LL ~ let _h = to_fn_once(move || -> isize { value }); | ```
2024-04-24Mention when type parameter could be `Clone`Esteban Küber-8/+51
``` error[E0382]: use of moved value: `t` --> $DIR/use_of_moved_value_copy_suggestions.rs:7:9 | LL | fn duplicate_t<T>(t: T) -> (T, T) { | - move occurs because `t` has type `T`, which does not implement the `Copy` trait ... LL | (t, t) | - ^ value used here after move | | | value moved here | help: if `T` implemented `Clone`, you could clone the value --> $DIR/use_of_moved_value_copy_suggestions.rs:4:16 | LL | fn duplicate_t<T>(t: T) -> (T, T) { | ^ consider constraining this type parameter with `Clone` ... LL | (t, t) | - you could clone this value help: consider restricting type parameter `T` | LL | fn duplicate_t<T: Copy>(t: T) -> (T, T) { | ++++++ ``` The `help` is new. On ADTs, we also extend the output with span labels: ``` error[E0507]: cannot move out of static item `FOO` --> $DIR/issue-17718-static-move.rs:6:14 | LL | let _a = FOO; | ^^^ move occurs because `FOO` has type `Foo`, which does not implement the `Copy` trait | note: if `Foo` implemented `Clone`, you could clone the value --> $DIR/issue-17718-static-move.rs:1:1 | LL | struct Foo; | ^^^^^^^^^^ consider implementing `Clone` for this type ... LL | let _a = FOO; | --- you could clone this value help: consider borrowing here | LL | let _a = &FOO; | + ```
2024-04-24Modify `find_expr` from `Span` to better account for closuresEsteban Küber-10/+17
Start pointing to where bindings were declared when they are captured in closures: ``` error[E0597]: `x` does not live long enough --> $DIR/suggest-return-closure.rs:23:9 | LL | let x = String::new(); | - binding `x` declared here ... LL | |c| { | --- value captured here LL | x.push(c); | ^ borrowed value does not live long enough ... LL | } | -- borrow later used here | | | `x` dropped here while still borrowed ``` Suggest cloning in more cases involving closures: ``` error[E0507]: cannot move out of `foo` in pattern guard --> $DIR/issue-27282-move-ref-mut-into-guard.rs:11:19 | LL | if { (|| { let mut bar = foo; bar.take() })(); false } => {}, | ^^ --- move occurs because `foo` has type `&mut Option<&i32>`, which does not implement the `Copy` trait | | | `foo` is moved here | = note: variables bound in patterns cannot be moved from until after the end of the pattern guard help: consider cloning the value if the performance cost is acceptable | LL | if { (|| { let mut bar = foo.clone(); bar.take() })(); false } => {}, | ++++++++ ```
2024-04-25Rollup merge of #124335 - ChrisDenton:stabilize-absolute, r=dtolnayMatthias Krüger-2/+0
Stabilize `std::path::absolute` FCP complete in https://github.com/rust-lang/rust/issues/92750#issuecomment-2075046985
2024-04-25Rollup merge of #124333 - Urgau:better-bad-print, r=fmeaseMatthias Krüger-3/+6
Improve diagnostic for unknown `--print` request This PR improves the diagnostic when encountering a unknown `--print` request. It also moves the run-make test to a simple UI test.
2024-04-25Rollup merge of #124322 - whosehang:master, r=NilstriebMatthias Krüger-2/+2
chore: fix some typos in comments
2024-04-24Auto merge of #124330 - fmease:rollup-a98y7jf, r=fmeasebors-1/+2
Rollup of 6 pull requests Successful merges: - #123316 (Test `#[unix_sigpipe = "inherit"]` with both `SIG_DFL` and `SIG_IGN`) - #123794 (More DefineOpaqueTypes::Yes) - #123881 (Bump Fuchsia versions) - #124281 (fix weak memory bug in TLS on Windows) - #124282 (windows fill_utf16_buf: explain the expected return value) - #124308 (Add diagnostic item for `std::iter::Enumerate`) r? `@ghost` `@rustbot` modify labels: rollup
2024-04-24Auto merge of #104087 - nbdd0121:const, r=scottmcmbors-8/+5
Stabilise inline_const # Stabilisation Report ## Summary This PR will stabilise `inline_const` feature in expression position. `inline_const_pat` is still unstable and will *not* be stabilised. The feature will allow code like this: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from https://github.com/rust-lang/rfcs/pull/2920 and is tracked in #76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in #77124. ## Difference from RFC There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content *within* it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. #89964). The inference is implemented in #89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body. This allows code like: ```rust let v: Vec<i32> = const { Vec::new() }; ``` Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in #96557. This allows code like: ```rust fn create_none_array<T, const N: usize>() -> [Option<T>; N] { [const { None::<T> }; N] } ``` This enhancement also makes inline const usable as static asserts: ```rust fn require_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) } } ``` ## Documentation Reference: rust-lang/reference#1295 ## Unresolved issues We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation: * expr fragment specifier issue: #86730 * ~~`const {}` behaves similar to `async {}` but not to `{}` and `unsafe {}` (they are treated as `ExpressionWithoutBlock` rather than `ExpressionWithBlock`): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453~~ ## Tests There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const
2024-04-24Stabilize `std::path::absolute`Chris Denton-2/+0
2024-04-24Improve diagnostic for unknown --print requestUrgau-3/+6
2024-04-24Stabilise `inline_const`Gary Guo-8/+5
2024-04-24Rollup merge of #124308 - CBSpeir:diagnostic-item-enumerate, r=compiler-errorsLeón Orell Valerian Liehr-0/+1
Add diagnostic item for `std::iter::Enumerate` This adds a diagnostic item for `std::iter::Enumerate`. The change will be used by the clippy `unused_enumerate_index` lint to move away from type paths to using diagnostic items. see: https://github.com/rust-lang/rust-clippy/issues/5393
2024-04-24Rollup merge of #123794 - oli-obk:define_opaque_types2, r=lcnrLeón Orell Valerian Liehr-1/+1
More DefineOpaqueTypes::Yes This accepts more code on stable. It is now possible to have match arms return a function item `foo::<ConcreteType>` and a function item `foo::<OpaqueTypeInDefiningScope>` in another, and that will constrain `OpaqueTypeInDefiningScope` to have the hidden type `ConcreteType`. So the following function will now compile, but on master it errors with a type mismatch on the second match arm ```rust // The function item whose generic params we want to merge. fn foo<T>(t: T) -> T { t } // Helper ensuring we can constrain `T` on `F` without explicitly specifying it fn bind<T, F: FnOnce(T) -> T>(_: T, f: F) -> F { f } fn k() -> impl Sized { let x = match true { true => { // `f` is `FnDef(foo, [infer_var])` let f = foo; // Get a value of an opaque type on stable let t = k(); // this returns `FnDef(foo, [k::return])` bind(t, f) } false => foo::<()>, }; todo!() } ``` r? ``@compiler-errors`` cc https://github.com/rust-lang/rust/issues/116652
2024-04-24Auto merge of #122500 - petrochenkov:deleg, r=fmeasebors-100/+124
delegation: Support renaming, and async, const, extern "ABI" and C-variadic functions Also allow delegating to functions with opaque types (`impl Trait`). The delegation item will refer to the original opaque type from the callee, fresh opaque type won't be created, which seems like a reasonable behavior. (Such delegation items will cause query cycles when used in trait impls, but it can be fixed later.) Part of https://github.com/rust-lang/rust/issues/118212.
2024-04-24Register hidden types when equating function definitions in coercionOli Scherer-1/+1
2024-04-24Error on using `yield` without also using `#[coroutine]` on the closureOli Scherer-101/+135
And suggest adding the `#[coroutine]` to the closure
2024-04-24Add explicit syntax for coroutines instead of relying on closures having ↵Oli Scherer-1/+17
`yield` expressions
2024-04-24Whitespace fixes.Nicholas Nethercote-10/+6
2024-04-24Remove unnecessary `pub`s in `mut_visit.rs`.Nicholas Nethercote-65/+60
This makes it clearer what is actually used outside of this crate.
2024-04-24Rename `NestedMetaItem::name_value_literal`.Nicholas Nethercote-4/+5
It's a highly misleading name, because it's completely different to `MetaItem::name_value_literal`. Specifically, it doesn't match `MetaItemKind::NameValue` (e.g. `#[foo = 3]`), it matches `MetaItemKind::List` (e.g. `#[foo(3)]`).
2024-04-24Remove `MetaItemKind::value_str`.Nicholas Nethercote-8/+4
`MetaItem::value_str` is good enough. And this makes `MetaItem::value_str` more like `MetaItem::meta_item_list` and `name_value_literal`.
2024-04-24Make `LazyAttrTokenStream::encode` panic.Nicholas Nethercote-3/+2
It's unreachable, because AST JSON printing support was removed some time ago.
2024-04-24chore: fix some typos in commentswhosehang-2/+2
Signed-off-by: whosehang <whosehang@outlook.com>
2024-04-24Auto merge of #122053 - erikdesjardins:alloca, r=nikicbors-34/+29
Stop using LLVM struct types for alloca The alloca type has no semantic meaning, only the size (and alignment, but we specify it explicitly) matter. Using `[N x i8]` is a more direct way to specify that we want `N` bytes, and avoids relying on LLVM's struct layout. It is likely that a future LLVM version will change to an untyped alloca representation. Split out from #121577. r? `@ghost`
2024-04-23Auto merge of #121557 - RalfJung:const-fn-call-promotion, r=oli-obkbors-71/+162
restrict promotion of `const fn` calls We only promote them in `const`/`static` initializers, but even that is still unfortunate -- we still cannot add promoteds to required_consts. But we should add them there to make sure it's always okay to evaluate every const we encounter in a MIR body. That effort of not promoting things that can fail to evaluate is tracked in https://github.com/rust-lang/rust/issues/80619. These `const fn` calls are the last missing piece. So I propose that we do not promote const-fn calls in const when that may fail without the entire const failing, thereby completing https://github.com/rust-lang/rust/issues/80619. Unfortunately we can't just reject promoting these functions outright due to backwards compatibility. So let's see if we can find a hack that makes crater happy... For the record, this is the [crater analysis](https://github.com/rust-lang/rust/pull/80243#issuecomment-751885520) from when I tried to entirely forbid this kind of promotion. It's a tiny amount of breakage and if we had a nice alternative for code like that, we could conceivably push it through... but sadly, inline const expressions are still blocked on t-lang concerns about post-monomorphization errors and we haven't yet figured out an implementation that can resolve those concerns. So we're forced to make progress via other means, such as terrible hacks like this. Attempt one: only promote calls on the "safe path" at the beginning of a MIR block. This is the path that starts at the start block and continues via gotos and calls, but stops at the first branch. If we had imposed this restriction before stabilizing `if` and `match` in `const`, this would have definitely been sufficient... EDIT: Turns out that works. :) **Here's the t-lang [nomination comment](https://github.com/rust-lang/rust/pull/121557#issuecomment-1990902440).** And here's the [FCP comment](https://github.com/rust-lang/rust/pull/121557#issuecomment-2010306165). r? `@oli-obk`
2024-04-23Add diagnostic item for std::iter::EnumerateChristopher B. Speir-0/+1
2024-04-23filter required_consts during inliningRalf Jung-5/+8
2024-04-23properly fill a promoted's required_constsRalf Jung-45/+30
then we can also make all_required_consts_are_checked a constant instead of a function
2024-04-23interpret: sanity-check that required_consts captures all consts that can failRalf Jung-34/+56
2024-04-23compute required_consts before promotion, and add promoteds that may failRalf Jung-23/+43
2024-04-23promotion: do not promote const-fn calls in const when that may fail without ↵Ralf Jung-26/+87
the entire const failing
2024-04-23Auto merge of #123126 - oli-obk:feed_crate_num, r=davidtwcobors-48/+61
Enable `CrateNum` query feeding via `TyCtxt` Instead of having a magic function that violates some `TyCtxtFeed` invariants, add a `create_def` equivalent for `CrateNum`s. Note that this still isn't tracked by the query system (unlike `create_def`), and that feeding most `CrateNum` queries for crates other than the local one will likely cause performance regressions. These things should be attempted on their own separately, but this PR should stand on its own
2024-04-23delegation: Support async, const, extern "ABI" and C-variadic functionsVadim Petrochenkov-91/+106
Also allow `impl Trait` in delegated functions. The delegation item will refer to the original opaque type from the callee, fresh opaque type won't be created.
2024-04-23delegation: Support renamingVadim Petrochenkov-9/+18
2024-04-23Auto merge of #124302 - matthiaskrgr:rollup-2aya8n8, r=matthiaskrgrbors-247/+250
Rollup of 3 pull requests Successful merges: - #124003 (Dellvmize some intrinsics (use `u32` instead of `Self` in some integer intrinsics)) - #124169 (Don't fatal when calling `expect_one_of` when recovering arg in `parse_seq`) - #124286 (Subtree sync for rustc_codegen_cranelift) r? `@ghost` `@rustbot` modify labels: rollup
2024-04-23Rollup merge of #124286 - bjorn3:sync_cg_clif-2024-04-23, r=bjorn3Matthias Krüger-212/+189
Subtree sync for rustc_codegen_cranelift This fixes a crash when compiling the standard library. In addition the Cranelift update fixes all the 128bit int abi incompatibility between cg_clif and cg_llvm. r? ``@ghost`` ``@rustbot`` label +A-codegen +A-cranelift +T-compiler
2024-04-23Rollup merge of #124169 - compiler-errors:parser-fatal, r=oli-obkMatthias Krüger-0/+1
Don't fatal when calling `expect_one_of` when recovering arg in `parse_seq` In `parse_seq`, when parsing a sequence of token-separated items, if we don't see a separator, we try to parse another item eagerly in order to give a good diagnostic and recover from a missing separator: https://github.com/rust-lang/rust/blob/d1a0fa5ed3ffe52d72f761d3c95cbeb0a9cdfe66/compiler/rustc_parse/src/parser/mod.rs#L900-L901 If parsing the item itself calls `expect_one_of`, then we will fatal because of #58903: https://github.com/rust-lang/rust/blob/d1a0fa5ed3ffe52d72f761d3c95cbeb0a9cdfe66/compiler/rustc_parse/src/parser/mod.rs#L513-L516 For `precise_capturing` feature I implemented, we do end up calling `expected_one_of`: https://github.com/rust-lang/rust/blob/d1a0fa5ed3ffe52d72f761d3c95cbeb0a9cdfe66/compiler/rustc_parse/src/parser/ty.rs#L712-L714 This leads the compiler to fatal *before* having emitted the first error, leading to absolutely no useful information for the user about what happened in the parser. This PR makes it so that we stop doing that. Fixes #124195
2024-04-23Rollup merge of #124003 - WaffleLapkin:dellvmization, r=scottmcm,RalfJung,antoyoMatthias Krüger-35/+60
Dellvmize some intrinsics (use `u32` instead of `Self` in some integer intrinsics) This implements https://github.com/rust-lang/compiler-team/issues/693 minus what was implemented in #123226. Note: I decided to _not_ change `shl`/... builder methods, as it just doesn't seem worth it. r? ``@scottmcm``
2024-04-23Auto merge of #124295 - fmease:rollup-i3apkc6, r=fmeasebors-466/+907
Rollup of 7 pull requests Successful merges: - #120929 (Wrap dyn type with parentheses in suggestion) - #122591 (Suggest using type args directly instead of equality constraint) - #122598 (deref patterns: lower deref patterns to MIR) - #123048 (alloc::Layout: explicitly document size invariant on the type level) - #123993 (Do `check_coroutine_obligations` once per typeck root) - #124218 (Allow nesting subdiagnostics in #[derive(Subdiagnostic)]) - #124285 (Mark ``@RUSTC_BUILTIN`` search path usage as unstable) r? `@ghost` `@rustbot` modify labels: rollup
2024-04-23Rollup merge of #124285 - ferrocene:unstable-L-rust-builtin, r=petrochenkovLeón Orell Valerian Liehr-1/+17
Mark `@RUSTC_BUILTIN` search path usage as unstable Follow up to https://github.com/rust-lang/rust/pull/121843 r? `@petrochenkov`
2024-04-23Rollup merge of #124218 - Xiretza:subsubdiagnostics, r=davidtwcoLeón Orell Valerian Liehr-113/+134
Allow nesting subdiagnostics in #[derive(Subdiagnostic)]
2024-04-23Rollup merge of #123993 - compiler-errors:coroutine-obl, r=lcnrLeón Orell Valerian Liehr-61/+66
Do `check_coroutine_obligations` once per typeck root We only need to do `check_coroutine_obligations` once per typeck root, especially since the new solver can't really (easily) associate which obligations correspond to which coroutines. This requires us to move the checks for sized coroutine fields into `mir_coroutine_witnesses`, but that's fine imo. r? lcnr
2024-04-23Rollup merge of #122598 - Nadrieril:full-derefpats, r=matthewjasperLeón Orell Valerian Liehr-221/+442
deref patterns: lower deref patterns to MIR This lowers deref patterns to MIR. This is a bit tricky because this is the first kind of pattern that requires storing a value in a temporary. Thanks to https://github.com/rust-lang/rust/pull/123324 false edges are no longer a problem. The thing I'm not confident about is the handling of fake borrows. This PR ignores any fake borrows inside a deref pattern. We are guaranteed to at least fake borrow the place of the first pointer value, which could be enough, but I'm not certain.
2024-04-23Rollup merge of #122591 - gurry:122162-impl-type-binding-suggestion, r=fmeaseLeón Orell Valerian Liehr-11/+114
Suggest using type args directly instead of equality constraint When type arguments are written erroneously using an equality constraint we suggest specifying them directly without the equality constraint. Fixes #122162 Changes the diagnostic in the issue from: ```rust error[E0229]: associated type bindings are not allowed here 9 | impl std::cmp::PartialEq<Rhs = T> for S { | ^^^^^^^ associated type not allowed here | ``` to ```rust error[E0229]: associated type bindings are not allowed here 9 | impl std::cmp::PartialEq<Rhs = T> for S { | ^^^^^^^ associated type not allowed here | help: to use `T` as a generic argument specify it directly | | impl std::cmp::PartialEq<T> for S { | ~ ```