Question:
Inlining introduces unsized temporaries. This is problematic since unsized temporaries fail to uphold alignment requirements as described in . For example:
The unsized locals alignment issue itself was fixed in .

<ins> - // MIR for `caller` before Inline + // MIR for `caller` after Inline fn caller(_1: Box<[i32]>) -> () { debug x => _1;                       // in scope 0 at $DIR/unsized_argument.rs:+0:11: +0:12 let mut _0: ();                      // return place in scope 0 at $DIR/unsized_argument.rs:+0:26: +0:26 let _2: ();                          // in scope 0 at $DIR/unsized_argument.rs:+1:5: +1:15 let mut _3: std::boxed::Box<[i32]>;  // in scope 0 at $DIR/unsized_argument.rs:+1:13: +1:14 let mut _4: ();                      // in scope 0 at $DIR/unsized_argument.rs:+1:14: +1:15 let mut _5: ();                      // in scope 0 at $DIR/unsized_argument.rs:+1:14: +1:15 let mut _6: ();                      // in scope 0 at $DIR/unsized_argument.rs:+1:14: +1:15 let mut _7: *const [i32];            // in scope 0 at $DIR/unsized_argument.rs:+1:13: +1:14 bb0: { StorageLive(_2);                 // scope 0 at $DIR/unsized_argument.rs:+1:5: +1:15 StorageLive(_3);                 // scope 0 at $DIR/unsized_argument.rs:+1:13: +1:14 _3 = move _1;                    // scope 0 at $DIR/unsized_argument.rs:+1:13: +1:14 _7 = (((_3.0: std::ptr::Unique<[i32]>).0: std::ptr::NonNull<[i32]>).0: *const [i32]); // scope 0 at $DIR/unsized_argument.rs:+1:5: +1:15 _2 = callee(move (*_7)) -> [return: bb3, unwind: bb4]; // scope 0 at $DIR/unsized_argument.rs:+1:5: +1:15 // mir::Constant // + span: $DIR/unsized_argument.rs:9:5: 9:11 // + literal: Const { ty: fn([i32]) {callee}, val: Value(<ZST>) } } bb1: { StorageDead(_3);                 // scope 0 at $DIR/unsized_argument.rs:+1:14: +1:15 StorageDead(_2);                 // scope 0 at $DIR/unsized_argument.rs:+1:15: +1:16 _0 = const ();                   // scope 0 at $DIR/unsized_argument.rs:+0:26: +2:2 return;                          // scope 0 at $DIR/unsized_argument.rs:+2:2: +2:2 } bb2 (cleanup): { resume;                          // scope 0 at $DIR/unsized_argument.rs:+0:1: +2:2 } bb3: { _4 = alloc::alloc::box_free::<[i32], std::alloc::Global>(move (_3.0: std::ptr::Unique<[i32]>), move (_3.1: std::alloc::Global)) -> bb1; // scope 0 at $DIR/unsized_argument.rs:+1:14: +1:15 // mir::Constant // + span: $DIR/unsized_argument.rs:9:14: 9:15 // + literal: Const { ty: unsafe fn(Unique<[i32]>, std::alloc::Global) {alloc::alloc::box_free::<[i32], std::alloc::Global>}, val: Value(<ZST>) } } bb4 (cleanup): { _6 = alloc::alloc::box_free::<[i32], std::alloc::Global>(move (_3.0: std::ptr::Unique<[i32]>), move (_3.1: std::alloc::Global)) -> [return: bb2, unwind terminate]; // scope 0 at $DIR/unsized_argument.rs:+1:14: +1:15 // mir::Constant // + span: $DIR/unsized_argument.rs:9:14: 9:15 // + literal: Const { ty: unsafe fn(Unique<[i32]>, std::alloc::Global) {alloc::alloc::box_free::<[i32], std::alloc::Global>}, val: Value(<ZST>) } } } </ins>


Question:
Inlining introduces unsized temporaries. This is problematic since unsized temporaries fail to uphold alignment requirements as described in . For example:
The unsized locals alignment issue itself was fixed in .

<ins> // needs-unwind #![feature(unsized_fn_params)] #[inline(always)] fn callee(y: [i32]) {} // EMIT_MIR unsized_argument.caller.Inline.diff fn caller(x: Box<[i32]>) { callee(*x); } fn main() { let b = Box::new([1]); caller(b); } </ins>


Question: OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:

} } <del> /// Whether `check_binop` allows overloaded operators to be invoked. </del> <ins> /// Whether `check_binop` is part of an assignment or not. /// Used to know wether we allow user overloads and to print /// better messages on error. </ins> #[deriving(Eq)] <del> enum AllowOverloadedOperatorsFlag { AllowOverloadedOperators, DontAllowOverloadedOperators, </del> <ins> enum IsBinopAssignment{ SimpleBinop, BinopAssignment, </ins> } #[deriving(Clone)]


Question: OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:

rhs: @ast::Expr, // Used only in the error case expected_result: Option<ty::t>, <del> allow_overloaded_operators: AllowOverloadedOperatorsFlag </del> <ins> is_binop_assignment: IsBinopAssignment </ins> ) { let tcx = fcx.ccx.tcx;


Question: OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:

} <del> // Check for overloaded operators if allowed. </del> <ins> // Check for overloaded operators if not an assignment. </ins> let result_t; <del> if allow_overloaded_operators == AllowOverloadedOperators { </del> <ins> if is_binop_assignment == SimpleBinop { </ins> result_t = check_user_binop(fcx, callee_id, expr,


Question: OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:

} else { fcx.type_error_message(expr.span, |actual| { <del> format!("binary operation {} cannot be  applied to type `{}`", ast_util::binop_to_str(op), actual) </del> <ins> format!("binary assignment operation  {}= cannot be applied to type `{}`", ast_util::binop_to_str(op), actual) </ins> }, lhs_t, None); <ins> check_expr(fcx, rhs); </ins> result_t = ty::mk_err(); }


Question: OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:

lhs, rhs, expected, <del> AllowOverloadedOperators); </del> <ins> SimpleBinop); </ins> let lhs_ty = fcx.expr_ty(lhs); let rhs_ty = fcx.expr_ty(rhs);


Question: OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:

lhs, rhs, expected, <del> DontAllowOverloadedOperators); </del> <ins> BinopAssignment); </ins> let lhs_t = fcx.expr_ty(lhs); let result_t = fcx.expr_ty(expr);


Question: OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. struct Foo; fn main() { let mut a = Foo; let ref b = Foo; a += *b; //~ Error: binary assignment operation += cannot be applied to type `Foo` } </ins>


Question: OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:

// Regression test for issue #5239 fn main() { <del> let x: |int| -> int = |ref x| { x += 1; }; //~ ERROR binary operation + cannot be applied to type `&int` </del> <ins> let x: |int| -> int = |ref x| { x += 1; }; //~ ERROR binary assignment operation += cannot be applied to type `&int` </ins> }


Question:
This is with Rust 1.69 but was probably always the case. Example: Compiling with prints Similarly when providing nothing changes. I didn't really follow how collects the libraries but I think it's via the query in which claims so this should be included AFAIU. Also the rationale of was to provide all libraries needed to link to the resulting , which is not the case in the above example. CC who originally implemented this feature.
It works as expected if the attribute is used in a dependencies. It seems to me that the function, is forgetting to add the current native libs. Doing something like this correctly adds to the output (even when passed via the command line) but I don't know if it's the right thing to do (cc
Yeah, I think adding is the correct fix. That adds the same information as does for dependencies.
Beware that is rather quirky. Originally Rust printed lines during build with information which link flags need to be to use the static library it builds, and is a blunt way of redirecting these "warnings". I don't know whether omission of is a bug or the old warnings just weren't meant to print them.
I can't imagine it to be a deliberate omission as is the only way to know how to correctly link any arbitrary staticlib afaik.

} } <ins> all_native_libs.extend_from_slice(&codegen_results.crate_info.used_libraries); </ins> if sess.opts.prints.contains(&PrintRequest::NativeStaticLibs) { print_native_static_libs(sess, &all_native_libs, &all_rust_dylibs); }


Question:
This is with Rust 1.69 but was probably always the case. Example: Compiling with prints Similarly when providing nothing changes. I didn't really follow how collects the libraries but I think it's via the query in which claims so this should be included AFAIU. Also the rationale of was to provide all libraries needed to link to the resulting , which is not the case in the above example. CC who originally implemented this feature.
It works as expected if the attribute is used in a dependencies. It seems to me that the function, is forgetting to add the current native libs. Doing something like this correctly adds to the output (even when passed via the command line) but I don't know if it's the right thing to do (cc
Yeah, I think adding is the correct fix. That adds the same information as does for dependencies.
Beware that is rather quirky. Originally Rust printed lines during build with information which link flags need to be to use the static library it builds, and is a blunt way of redirecting these "warnings". I don't know whether omission of is a bug or the old warnings just weren't meant to print them.
I can't imagine it to be a deliberate omission as is the only way to know how to correctly link any arbitrary staticlib afaik.

<ins> include ../tools.mk # ignore-cross-compile # ignore-wasm all: $(RUSTC) --crate-type rlib -lbar_cli bar.rs $(RUSTC) foo.rs -lfoo_cli --crate-type staticlib --print native-static-libs 2>&1  | grep 'note: native-static-libs: '  | sed 's/note: native-static-libs: (.*)/1/' > $(TMPDIR)/libs.txt cat $(TMPDIR)/libs.txt | grep -F "glib-2.0" # in bar.rs cat $(TMPDIR)/libs.txt | grep -F "systemd" # in foo.rs cat $(TMPDIR)/libs.txt | grep -F "bar_cli" cat $(TMPDIR)/libs.txt | grep -F "foo_cli" </ins>


Question:
This is with Rust 1.69 but was probably always the case. Example: Compiling with prints Similarly when providing nothing changes. I didn't really follow how collects the libraries but I think it's via the query in which claims so this should be included AFAIU. Also the rationale of was to provide all libraries needed to link to the resulting , which is not the case in the above example. CC who originally implemented this feature.
It works as expected if the attribute is used in a dependencies. It seems to me that the function, is forgetting to add the current native libs. Doing something like this correctly adds to the output (even when passed via the command line) but I don't know if it's the right thing to do (cc
Yeah, I think adding is the correct fix. That adds the same information as does for dependencies.
Beware that is rather quirky. Originally Rust printed lines during build with information which link flags need to be to use the static library it builds, and is a blunt way of redirecting these "warnings". I don't know whether omission of is a bug or the old warnings just weren't meant to print them.
I can't imagine it to be a deliberate omission as is the only way to know how to correctly link any arbitrary staticlib afaik.

<ins> #[no_mangle] pub extern "C" fn my_bar_add(left: i32, right: i32) -> i32 { // Obviously makes no sense but... unsafe { g_free(std::ptr::null_mut()); } left + right } #[link(name = "glib-2.0")] extern "C" { fn g_free(p: *mut ()); } </ins>


Question:
This is with Rust 1.69 but was probably always the case. Example: Compiling with prints Similarly when providing nothing changes. I didn't really follow how collects the libraries but I think it's via the query in which claims so this should be included AFAIU. Also the rationale of was to provide all libraries needed to link to the resulting , which is not the case in the above example. CC who originally implemented this feature.
It works as expected if the attribute is used in a dependencies. It seems to me that the function, is forgetting to add the current native libs. Doing something like this correctly adds to the output (even when passed via the command line) but I don't know if it's the right thing to do (cc
Yeah, I think adding is the correct fix. That adds the same information as does for dependencies.
Beware that is rather quirky. Originally Rust printed lines during build with information which link flags need to be to use the static library it builds, and is a blunt way of redirecting these "warnings". I don't know whether omission of is a bug or the old warnings just weren't meant to print them.
I can't imagine it to be a deliberate omission as is the only way to know how to correctly link any arbitrary staticlib afaik.

<ins> extern crate bar; #[no_mangle] pub extern "C" fn my_foo_add(left: i32, right: i32) -> i32 { // Obviously makes no sense but... unsafe { init(std::ptr::null_mut()); } bar::my_bar_add(left, right) } #[link(name = "systemd")] extern "C" { fn init(p: *mut ()); } </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc is this fixed by one of your PRs? This looked like it might be , but while was bisected to this one was bisected to , not sure what to make of it :thinking:
Yes, this issue is fixed in (ice → errors): <details<summarystderr</summary</detailsI'm not sure why the bisection points differ, they all share the same root cause. It doesn't really matter though. Btw, I saw about another new reproducer but I dismissed it as irrelevant since I assumed it required , too (I did run it but didn't notice I could omit that flag). Sorry about that. Thanks for opening a separate issue because now we actually have 2 beautiful regression tests for the bug fixed in ! So let's not close this issue then but wait for to get merged and then I will open a separate PR with the regression tests & assign you. claim

<ins> #![feature(inherent_associated_types)] #![allow(incomplete_features)] // Check that we don't crash when printing inherent projections in diagnostics. pub struct Carrier<'a>(&'a ()); pub type User = for<'b> fn(Carrier<'b>::Focus<i32>); impl<'a> Carrier<'a> { pub type Focus<T> = &'a mut User; //~ ERROR overflow evaluating associated type } fn main() {} </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc is this fixed by one of your PRs? This looked like it might be , but while was bisected to this one was bisected to , not sure what to make of it :thinking:
Yes, this issue is fixed in (ice → errors): <details<summarystderr</summary</detailsI'm not sure why the bisection points differ, they all share the same root cause. It doesn't really matter though. Btw, I saw about another new reproducer but I dismissed it as irrelevant since I assumed it required , too (I did run it but didn't notice I could omit that flag). Sorry about that. Thanks for opening a separate issue because now we actually have 2 beautiful regression tests for the bug fixed in ! So let's not close this issue then but wait for to get merged and then I will open a separate PR with the regression tests & assign you. claim

<ins> error: overflow evaluating associated type `Carrier<'b>::Focus<i32>` --> $DIR/issue-111879-0.rs:11:25 | LL |     pub type Focus<T> = &'a mut User; |                         ^^^^^^^^^^^^ error: aborting due to previous error </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc is this fixed by one of your PRs? This looked like it might be , but while was bisected to this one was bisected to , not sure what to make of it :thinking:
Yes, this issue is fixed in (ice → errors): <details<summarystderr</summary</detailsI'm not sure why the bisection points differ, they all share the same root cause. It doesn't really matter though. Btw, I saw about another new reproducer but I dismissed it as irrelevant since I assumed it required , too (I did run it but didn't notice I could omit that flag). Sorry about that. Thanks for opening a separate issue because now we actually have 2 beautiful regression tests for the bug fixed in ! So let's not close this issue then but wait for to get merged and then I will open a separate PR with the regression tests & assign you. claim

<ins> #![feature(inherent_associated_types)] #![allow(incomplete_features)] // Check that we don't crash when printing inherent projections in diagnostics. struct Foo<T>(T); impl<'a> Foo<fn(&'a ())> { type Assoc = &'a (); } fn main(_: for<'a> fn(Foo<fn(&'a ())>::Assoc)) {} //~ ERROR `main` function has wrong type </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc is this fixed by one of your PRs? This looked like it might be , but while was bisected to this one was bisected to , not sure what to make of it :thinking:
Yes, this issue is fixed in (ice → errors): <details<summarystderr</summary</detailsI'm not sure why the bisection points differ, they all share the same root cause. It doesn't really matter though. Btw, I saw about another new reproducer but I dismissed it as irrelevant since I assumed it required , too (I did run it but didn't notice I could omit that flag). Sorry about that. Thanks for opening a separate issue because now we actually have 2 beautiful regression tests for the bug fixed in ! So let's not close this issue then but wait for to get merged and then I will open a separate PR with the regression tests & assign you. claim

<ins> error[E0580]: `main` function has wrong type --> $DIR/issue-111879-1.rs:12:1 | LL | fn main(_: for<'a> fn(Foo<fn(&'a ())>::Assoc)) {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ incorrect number of function parameters | = note: expected fn pointer `fn()` found fn pointer `fn(for<'a> fn(Foo<fn(&'a ())>::Assoc))` error: aborting due to previous error For more information about this error, try `rustc --explain E0580`. </ins>


Question:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --My code does not compile any more after updating to 1.70.0. The project can be found I tried to create a minimal reproducer. It has something to do with glib's clone macro, which I use. Here is the reproducer that compiles fine on 1.69 but not on 1.70.0. I left some comments in the code describing what I observed so far. It needs and dependency): Output I expected to see this happen: The type is correctly inferred Instead, this happened: The compiler tells me that it doesn't know the type, although the type can be inferred <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.69.0 <!-- Provide the version you are using that has the regression. --:
regressed in cc slightly minimized and removed dependencies: Putting the identity function back (or wrapping the async block in a block) seems to "fix" the error: <details<summarybisector output</summarysearched nightlies: from nightly-2023-03-01 to nightly-2023-06-01 regressed nightly: nightly-2023-03-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details</details label -regression-untriaged +regression-from-stable-to-stable +A-inference +A-async-await
It is not only an identity function that makes this suddenly work, but putting the async block in a block works as well. Permuting what to wrap in a block, only a single case out of the four fails: Out of curiousity I tried the patch in thats supposed to fix to make async blocks "provide inference guidance", but that doesn’t work either.
This happens due to a hack in typeck, where function arguments that aren't closures, including block expressions that return closures, are typechecked before function parameters that are closures. Note that async blocks are desugared to closures. This basically means that closures and async blocks in function arguments behave as if they were ordered after all non-closure non-async-block arguments and you now get the same inference error that you would get on older compilers if you manually swapped the function arguments. (Also, looks like this hack has existed .)
Wow, that is a very good catch! And also good news, as it means "fixing" the regression should be a oneliner, which I will try tomorrow. However that does smell like a very gross hack, and I wonder if there will eventually be a better way altogether. But that is for a different day.
Note that just excluding desugared async block closures from this hack breaks inference for different programs that are now accepted on stable, for example:
you mean which are only accepted as of 1.70?
Yeah, I mean stable 1.70. But I guess it's better to break a constructed program that compiled for one stable version instead of breaking a real codebase that compiled for several stable versions.
I'd be fine landing a PR that excludes future-desugared async blocks from this hack.
I opened with a fix and regression test. Thanks so much for finding the code responsible for this, I sure would have gone crazy with this :-D As both the culprit PR and the 1.70 beta went through a crater run, we are wondering why this was never caught earlier? Is it correct to assume your code exhibiting this problem is closed source? Or is it in some public repo that is not yet scraped by crater?
My code is GPLv3 and can be found on GitHub. I've never heard of and I don't think it is scraped. But it would really cool if it could scrape my project, too. To actually build it, you also need some system libraries installed like glib2, gtk4, libadwaita, etc. No idea whether can handle this special case.
Crater should automatically pick up any public Rust project on github. But I’m not an expert on it by any means. Its quite possible that it ignores certain crates that depend on specific system libraries.
Your repo is on crater under the name "symphony", but it's failing to build due to outdated system libraries. <details<summarycrater log</summary</details
WG-prioritization assigning priority (). label -I-prioritize +P-high Note: unsure if we wanted to keep issues open when the fix is nominated for a backport

continue; } <del> let is_closure = matches!(arg.kind, ExprKind::Closure { .. }); </del> <ins> // For this check, we do *not* want to treat async generator closures (async blocks) // as proper closures. Doing so would regress type inference when feeding // the return value of an argument-position async block to an argument-position // closure wrapped in a block. // See <https://github.com/rust-lang/rust/issues/112225>. let is_closure = if let ExprKind::Closure(closure) = arg.kind { !tcx.generator_is_async(closure.def_id.to_def_id()) } else { false }; </ins> if is_closure != check_closures { continue; }


Question:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --My code does not compile any more after updating to 1.70.0. The project can be found I tried to create a minimal reproducer. It has something to do with glib's clone macro, which I use. Here is the reproducer that compiles fine on 1.69 but not on 1.70.0. I left some comments in the code describing what I observed so far. It needs and dependency): Output I expected to see this happen: The type is correctly inferred Instead, this happened: The compiler tells me that it doesn't know the type, although the type can be inferred <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.69.0 <!-- Provide the version you are using that has the regression. --:
regressed in cc slightly minimized and removed dependencies: Putting the identity function back (or wrapping the async block in a block) seems to "fix" the error: <details<summarybisector output</summarysearched nightlies: from nightly-2023-03-01 to nightly-2023-06-01 regressed nightly: nightly-2023-03-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details</details label -regression-untriaged +regression-from-stable-to-stable +A-inference +A-async-await
It is not only an identity function that makes this suddenly work, but putting the async block in a block works as well. Permuting what to wrap in a block, only a single case out of the four fails: Out of curiousity I tried the patch in thats supposed to fix to make async blocks "provide inference guidance", but that doesn’t work either.
This happens due to a hack in typeck, where function arguments that aren't closures, including block expressions that return closures, are typechecked before function parameters that are closures. Note that async blocks are desugared to closures. This basically means that closures and async blocks in function arguments behave as if they were ordered after all non-closure non-async-block arguments and you now get the same inference error that you would get on older compilers if you manually swapped the function arguments. (Also, looks like this hack has existed .)
Wow, that is a very good catch! And also good news, as it means "fixing" the regression should be a oneliner, which I will try tomorrow. However that does smell like a very gross hack, and I wonder if there will eventually be a better way altogether. But that is for a different day.
Note that just excluding desugared async block closures from this hack breaks inference for different programs that are now accepted on stable, for example:
you mean which are only accepted as of 1.70?
Yeah, I mean stable 1.70. But I guess it's better to break a constructed program that compiled for one stable version instead of breaking a real codebase that compiled for several stable versions.
I'd be fine landing a PR that excludes future-desugared async blocks from this hack.
I opened with a fix and regression test. Thanks so much for finding the code responsible for this, I sure would have gone crazy with this :-D As both the culprit PR and the 1.70 beta went through a crater run, we are wondering why this was never caught earlier? Is it correct to assume your code exhibiting this problem is closed source? Or is it in some public repo that is not yet scraped by crater?
My code is GPLv3 and can be found on GitHub. I've never heard of and I don't think it is scraped. But it would really cool if it could scrape my project, too. To actually build it, you also need some system libraries installed like glib2, gtk4, libadwaita, etc. No idea whether can handle this special case.
Crater should automatically pick up any public Rust project on github. But I’m not an expert on it by any means. Its quite possible that it ignores certain crates that depend on specific system libraries.
Your repo is on crater under the name "symphony", but it's failing to build due to outdated system libraries. <details<summarycrater log</summary</details
WG-prioritization assigning priority (). label -I-prioritize +P-high Note: unsure if we wanted to keep issues open when the fix is nominated for a backport

<ins> // check-pass // edition:2021 use core::future::Future; fn main() { do_async(async { (0,) }, { // closure must be inside block |info| println!("{:?}", info.0) }); } fn do_async<R, Fut, F>(_tokio_fut: Fut, _glib_closure: F) where Fut: Future<Output = R>, F: FnOnce(R), { } </ins>


Question:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --My code does not compile any more after updating to 1.70.0. The project can be found I tried to create a minimal reproducer. It has something to do with glib's clone macro, which I use. Here is the reproducer that compiles fine on 1.69 but not on 1.70.0. I left some comments in the code describing what I observed so far. It needs and dependency): Output I expected to see this happen: The type is correctly inferred Instead, this happened: The compiler tells me that it doesn't know the type, although the type can be inferred <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.69.0 <!-- Provide the version you are using that has the regression. --:
regressed in cc slightly minimized and removed dependencies: Putting the identity function back (or wrapping the async block in a block) seems to "fix" the error: <details<summarybisector output</summarysearched nightlies: from nightly-2023-03-01 to nightly-2023-06-01 regressed nightly: nightly-2023-03-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details</details label -regression-untriaged +regression-from-stable-to-stable +A-inference +A-async-await
It is not only an identity function that makes this suddenly work, but putting the async block in a block works as well. Permuting what to wrap in a block, only a single case out of the four fails: Out of curiousity I tried the patch in thats supposed to fix to make async blocks "provide inference guidance", but that doesn’t work either.
This happens due to a hack in typeck, where function arguments that aren't closures, including block expressions that return closures, are typechecked before function parameters that are closures. Note that async blocks are desugared to closures. This basically means that closures and async blocks in function arguments behave as if they were ordered after all non-closure non-async-block arguments and you now get the same inference error that you would get on older compilers if you manually swapped the function arguments. (Also, looks like this hack has existed .)
Wow, that is a very good catch! And also good news, as it means "fixing" the regression should be a oneliner, which I will try tomorrow. However that does smell like a very gross hack, and I wonder if there will eventually be a better way altogether. But that is for a different day.
Note that just excluding desugared async block closures from this hack breaks inference for different programs that are now accepted on stable, for example:
you mean which are only accepted as of 1.70?
Yeah, I mean stable 1.70. But I guess it's better to break a constructed program that compiled for one stable version instead of breaking a real codebase that compiled for several stable versions.
I'd be fine landing a PR that excludes future-desugared async blocks from this hack.
I opened with a fix and regression test. Thanks so much for finding the code responsible for this, I sure would have gone crazy with this :-D As both the culprit PR and the 1.70 beta went through a crater run, we are wondering why this was never caught earlier? Is it correct to assume your code exhibiting this problem is closed source? Or is it in some public repo that is not yet scraped by crater?
My code is GPLv3 and can be found on GitHub. I've never heard of and I don't think it is scraped. But it would really cool if it could scrape my project, too. To actually build it, you also need some system libraries installed like glib2, gtk4, libadwaita, etc. No idea whether can handle this special case.
Crater should automatically pick up any public Rust project on github. But I’m not an expert on it by any means. Its quite possible that it ignores certain crates that depend on specific system libraries.
Your repo is on crater under the name "symphony", but it's failing to build due to outdated system libraries. <details<summarycrater log</summary</details
WG-prioritization assigning priority (). label -I-prioritize +P-high Note: unsure if we wanted to keep issues open when the fix is nominated for a backport

<ins> // edition:2021 // With the current compiler logic, we cannot have both the `112225-1` case, // and this `112225-2` case working, as the type inference depends on the evaluation // order, and there is some explicit ordering going on. // See the `check_closures` part in `FnCtxt::check_argument_types`. // The `112225-1` case was a regression in real world code, whereas the `112225-2` // case never used to work prior to 1.70. use core::future::Future; fn main() { let x = Default::default(); //~^ ERROR: type annotations needed do_async( async { x.0; }, { || { let _: &(i32,) = &x; } }, ); } fn do_async<Fut, T>(_fut: Fut, _val: T, ) {} </ins>


Question:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --My code does not compile any more after updating to 1.70.0. The project can be found I tried to create a minimal reproducer. It has something to do with glib's clone macro, which I use. Here is the reproducer that compiles fine on 1.69 but not on 1.70.0. I left some comments in the code describing what I observed so far. It needs and dependency): Output I expected to see this happen: The type is correctly inferred Instead, this happened: The compiler tells me that it doesn't know the type, although the type can be inferred <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.69.0 <!-- Provide the version you are using that has the regression. --:
regressed in cc slightly minimized and removed dependencies: Putting the identity function back (or wrapping the async block in a block) seems to "fix" the error: <details<summarybisector output</summarysearched nightlies: from nightly-2023-03-01 to nightly-2023-06-01 regressed nightly: nightly-2023-03-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details</details label -regression-untriaged +regression-from-stable-to-stable +A-inference +A-async-await
It is not only an identity function that makes this suddenly work, but putting the async block in a block works as well. Permuting what to wrap in a block, only a single case out of the four fails: Out of curiousity I tried the patch in thats supposed to fix to make async blocks "provide inference guidance", but that doesn’t work either.
This happens due to a hack in typeck, where function arguments that aren't closures, including block expressions that return closures, are typechecked before function parameters that are closures. Note that async blocks are desugared to closures. This basically means that closures and async blocks in function arguments behave as if they were ordered after all non-closure non-async-block arguments and you now get the same inference error that you would get on older compilers if you manually swapped the function arguments. (Also, looks like this hack has existed .)
Wow, that is a very good catch! And also good news, as it means "fixing" the regression should be a oneliner, which I will try tomorrow. However that does smell like a very gross hack, and I wonder if there will eventually be a better way altogether. But that is for a different day.
Note that just excluding desugared async block closures from this hack breaks inference for different programs that are now accepted on stable, for example:
you mean which are only accepted as of 1.70?
Yeah, I mean stable 1.70. But I guess it's better to break a constructed program that compiled for one stable version instead of breaking a real codebase that compiled for several stable versions.
I'd be fine landing a PR that excludes future-desugared async blocks from this hack.
I opened with a fix and regression test. Thanks so much for finding the code responsible for this, I sure would have gone crazy with this :-D As both the culprit PR and the 1.70 beta went through a crater run, we are wondering why this was never caught earlier? Is it correct to assume your code exhibiting this problem is closed source? Or is it in some public repo that is not yet scraped by crater?
My code is GPLv3 and can be found on GitHub. I've never heard of and I don't think it is scraped. But it would really cool if it could scrape my project, too. To actually build it, you also need some system libraries installed like glib2, gtk4, libadwaita, etc. No idea whether can handle this special case.
Crater should automatically pick up any public Rust project on github. But I’m not an expert on it by any means. Its quite possible that it ignores certain crates that depend on specific system libraries.
Your repo is on crater under the name "symphony", but it's failing to build due to outdated system libraries. <details<summarycrater log</summary</details
WG-prioritization assigning priority (). label -I-prioritize +P-high Note: unsure if we wanted to keep issues open when the fix is nominated for a backport

<ins> error[E0282]: type annotations needed --> $DIR/issue-112225-2.rs:13:9 | LL |     let x = Default::default(); |         ^ ... LL |         async { x.0; }, |                 - type must be known at this point | help: consider giving `x` an explicit type | LL |     let x: /* Type */ = Default::default(); |          ++++++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0282`. </ins>


Question:
Sometimes when changing compiler internals, I run to make sure I didn't break tools and codegen backends. This also checks rust-analyzer by default, which is not very useful, I cannot break that. If we want to keep that, it would at least be useful to put it last so I can Ctrl-C out of it. Currently, rustfmt is checked after rust-analyzer. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
mentoring instructions: switch the order of these two lines:
points out that Cargo also isn't checked by default, so for consistency it would be nice for RustAnalyzer not to be either:
claim

check::CargoMiri, check::MiroptTestTools, check::Rls, <del> check::RustAnalyzer, </del> check::Rustfmt, <ins> check::RustAnalyzer, </ins> check::Bootstrap ), Kind::Test => describe!(


Question:
Sometimes when changing compiler internals, I run to make sure I didn't break tools and codegen backends. This also checks rust-analyzer by default, which is not very useful, I cannot break that. If we want to keep that, it would at least be useful to put it last so I can Ctrl-C out of it. Currently, rustfmt is checked after rust-analyzer. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
mentoring instructions: switch the order of these two lines:
points out that Cargo also isn't checked by default, so for consistency it would be nice for RustAnalyzer not to be either:
claim

impl Step for RustAnalyzer { type Output = (); const ONLY_HOSTS: bool = true; <del> const DEFAULT: bool = true; </del> <ins> const DEFAULT: bool = false; </ins> fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/tools/rust-analyzer")


Question:
I tried to enable vendoring in and then following the instructions given by . I expected to see this happen: All dependencies are vendored. Instead, this happened: To work around this, I need to explicitly use a nightly cargo. Caused by enabling the unstable cargo feature.
This also broke the rust-analyzer config as rust-analyzer fetches the workspace layout using the default toolchain which for most users is stable.
can we override the cargo that rust-analyzer uses? we should use the beta toolchain for consistency.
I can't find any configuration for that.
ok. i think we should consider reverting . why did you need a new cargo feature to make that PR work?
So, how are people going to dogfood unstable Cargo features before they get stabilized if rust-analyzer breaks on it? In any case, I used an unstable Cargo feature because I wanted to use the private dependency metadata in the rlib, and that means Cargo needs to actually mark the dependency as private, and that means needs to communicate this information to Cargo.
As a hack you could handle marking deps as private and public in .
I am stumbling over this too. So is the only workaround ?
You can also put between and to override the toolchain to use for just a single call. I'm not aware of any other workaround than using nightly or using the unstable with a recent enough stable/beta cargo.
This is no longer a problem since I think?
Does that also add RUSTC_BOOTSTRAP=1 to the vendor command shown by x.py?
Oh wait, I didn't see the manually invoked part.

if toml_val is not None: env["{}_{}".format(var_name, host_triple_sanitized)] = toml_val <ins> # In src/etc/rust_analyzer_settings.json, we configure rust-analyzer to # pass RUSTC_BOOTSTRAP=1 to all cargo invocations because the standard # library uses unstable Cargo features. Without RUSTC_BOOTSTRAP, # rust-analyzer would fail to fetch workspace layout when the system's # default toolchain is not nightly. # # But that setting has the collateral effect of rust-analyzer also # passing RUSTC_BOOTSTRAP=1 to all x.py invocations too (the various # overrideCommand). For compiling bootstrap, that is unwanted and can # cause spurious rebuilding of bootstrap when rust-analyzer x.py # invocations are interleaved with handwritten ones on the command line. env.pop("RUSTC_BOOTSTRAP", None) </ins> # preserve existing RUSTFLAGS env.setdefault("RUSTFLAGS", "")


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Hello! :wave: I tried this code on Windows: I expected to see this happen: Success for an available address like and blocking forever (or until TCP timeout) for just like on Linux. Instead, this happened: the call never succeeds, not even for on Windows. Related: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Thanks for the report! My best guess from quickly glancing at the code is that the problem is here: This is using to convert seconds into an (aka ). Which means that it can become a negative timeout. If I'm right then the fix here would be to limit the timeout to or less.
claim
thanks for your work on this and pushing it over the finish line! :+1: :pray:

} #[test] <ins> #[cfg_attr(target_env = "sgx", ignore)] // FIXME: https://github.com/fortanix/rust-sgx/issues/31 fn connect_timeout_error() { let socket_addr = next_test_ip4(); let result = TcpStream::connect_timeout(&socket_addr, Duration::MAX); assert!(!matches!(result, Err(e) if e.kind() == ErrorKind::TimedOut)); let _listener = TcpListener::bind(&socket_addr).unwrap(); assert!(TcpStream::connect_timeout(&socket_addr, Duration::MAX).is_ok()); } #[test] </ins> fn listen_localhost() { let socket_addr = next_test_ip4(); let listener = t!(TcpListener::bind(&socket_addr));


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Hello! :wave: I tried this code on Windows: I expected to see this happen: Success for an available address like and blocking forever (or until TCP timeout) for just like on Linux. Instead, this happened: the call never succeeds, not even for on Windows. Related: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Thanks for the report! My best guess from quickly glancing at the code is that the problem is here: This is using to convert seconds into an (aka ). Which means that it can become a negative timeout. If I'm right then the fix here would be to limit the timeout to or less.
claim
thanks for your work on this and pushing it over the finish line! :+1: :pray:

} let mut timeout = c::timeval { <del> tv_sec: timeout.as_secs() as c_long, </del> <ins> tv_sec: cmp::min(timeout.as_secs(), c_long::MAX as u64) as c_long, </ins> tv_usec: (timeout.subsec_nanos() / 1000) as c_long, };


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.58:
This was , whoops. I can work on this. claim

} let mut new_abis = Vec::new(); <del> loop { </del> <ins> while !p.eat(&token::CloseDelim(Delimiter::Parenthesis)) { </ins> match p.parse_str_lit() { Ok(str_lit) => { new_abis.push((str_lit.symbol_unescaped, str_lit.span)); } Err(opt_lit) => { <del> // If the non-string literal is a closing paren then it's the end of the list and is fine if p.eat(&token::CloseDelim(Delimiter::Parenthesis)) { break; } </del> let span = opt_lit.map_or(p.token.span, |lit| lit.span); let mut err = p.sess.span_diagnostic.struct_span_err(span, "expected string literal");


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.58:
This was , whoops. I can work on this. claim

<ins> // needs-asm-support #![feature(asm_const)] use std::arch::{asm, global_asm}; fn main() { let mut foo = 0; let mut bar = 0; unsafe { asm!(); //~^ ERROR requires at least a template string argument asm!(foo); //~^ ERROR asm template must be a string literal asm!("{}" foo); //~^ ERROR expected token: `,` asm!("{}", foo); //~^ ERROR expected operand, clobber_abi, options, or additional template string asm!("{}", in foo); //~^ ERROR expected `(`, found `foo` asm!("{}", in(reg foo)); //~^ ERROR expected `)`, found `foo` asm!("{}", in(reg)); //~^ ERROR expected expression, found end of macro arguments asm!("{}", inout(=) foo => bar); //~^ ERROR expected register class or explicit register asm!("{}", inout(reg) foo =>); //~^ ERROR expected expression, found end of macro arguments asm!("{}", in(reg) foo => bar); //~^ ERROR expected one of `!`, `,`, `.`, `::`, `?`, `{`, or an operator, found `=>` asm!("{}", sym foo + bar); //~^ ERROR expected a path for argument to `sym` asm!("", options(foo)); //~^ ERROR expected one of asm!("", options(nomem foo)); //~^ ERROR expected one of asm!("", options(nomem, foo)); //~^ ERROR expected one of asm!("{}", options(), const foo); //~^ ERROR attempt to use a non-constant value in a constant // test that asm!'s clobber_abi doesn't accept non-string literals // see also https://github.com/rust-lang/rust/issues/112635 asm!("", clobber_abi()); //~^ ERROR at least one abi must be provided asm!("", clobber_abi(foo)); //~^ ERROR expected string literal asm!("", clobber_abi("C" foo)); //~^ ERROR expected one of `)` or `,`, found `foo` asm!("", clobber_abi("C", foo)); //~^ ERROR expected string literal asm!("", clobber_abi(1)); //~^ ERROR expected string literal asm!("", clobber_abi(())); //~^ ERROR expected string literal asm!("", clobber_abi(uwu)); //~^ ERROR expected string literal asm!("", clobber_abi({})); //~^ ERROR expected string literal asm!("", clobber_abi(loop {})); //~^ ERROR expected string literal asm!("", clobber_abi(if)); //~^ ERROR expected string literal asm!("", clobber_abi(do)); //~^ ERROR expected string literal asm!("", clobber_abi(<)); //~^ ERROR expected string literal asm!("", clobber_abi(.)); //~^ ERROR expected string literal asm!("{}", clobber_abi("C"), const foo); //~^ ERROR attempt to use a non-constant value in a constant asm!("", options(), clobber_abi("C")); asm!("{}", options(), clobber_abi("C"), const foo); //~^ ERROR attempt to use a non-constant value in a constant asm!("{a}", a = const foo, a = const bar); //~^ ERROR duplicate argument named `a` //~^^ ERROR argument never used //~^^^ ERROR attempt to use a non-constant value in a constant //~^^^^ ERROR attempt to use a non-constant value in a constant asm!("", options(), ""); //~^ ERROR expected one of asm!("{}", in(reg) foo, "{}", out(reg) foo); //~^ ERROR expected one of asm!(format!("{{{}}}", 0), in(reg) foo); //~^ ERROR asm template must be a string literal asm!("{1}", format!("{{{}}}", 0), in(reg) foo, out(reg) bar); //~^ ERROR asm template must be a string literal asm!("{}", in(reg) _); //~^ ERROR _ cannot be used for input operands asm!("{}", inout(reg) _); //~^ ERROR _ cannot be used for input operands asm!("{}", inlateout(reg) _); //~^ ERROR _ cannot be used for input operands } } const FOO: i32 = 1; const BAR: i32 = 2; global_asm!(); //~^ ERROR requires at least a template string argument global_asm!(FOO); //~^ ERROR asm template must be a string literal global_asm!("{}" FOO); //~^ ERROR expected token: `,` global_asm!("{}", FOO); //~^ ERROR expected operand, options, or additional template string global_asm!("{}", const); //~^ ERROR expected expression, found end of macro arguments global_asm!("{}", const(reg) FOO); //~^ ERROR expected one of global_asm!("", options(FOO)); //~^ ERROR expected one of global_asm!("", options(nomem FOO)); //~^ ERROR expected one of global_asm!("", options(nomem, FOO)); //~^ ERROR expected one of global_asm!("{}", options(), const FOO); global_asm!("", clobber_abi(FOO)); //~^ ERROR expected string literal global_asm!("", clobber_abi("C" FOO)); //~^ ERROR expected one of `)` or `,`, found `FOO` global_asm!("", clobber_abi("C", FOO)); //~^ ERROR expected string literal global_asm!("{}", clobber_abi("C"), const FOO); //~^ ERROR `clobber_abi` cannot be used with `global_asm!` global_asm!("", options(), clobber_abi("C")); //~^ ERROR `clobber_abi` cannot be used with `global_asm!` global_asm!("{}", options(), clobber_abi("C"), const FOO); //~^ ERROR `clobber_abi` cannot be used with `global_asm!` global_asm!("", clobber_abi("C"), clobber_abi("C")); //~^ ERROR `clobber_abi` cannot be used with `global_asm!` global_asm!("{a}", a = const FOO, a = const BAR); //~^ ERROR duplicate argument named `a` //~^^ ERROR argument never used global_asm!("", options(), ""); //~^ ERROR expected one of global_asm!("{}", const FOO, "{}", const FOO); //~^ ERROR expected one of global_asm!(format!("{{{}}}", 0), const FOO); //~^ ERROR asm template must be a string literal global_asm!("{1}", format!("{{{}}}", 0), const FOO, const BAR); //~^ ERROR asm template must be a string literal </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.58:
This was , whoops. I can work on this. claim

<ins> error: requires at least a template string argument --> $DIR/parse-error.rs:11:9 | LL |         asm!(); |         ^^^^^^ error: asm template must be a string literal --> $DIR/parse-error.rs:13:14 | LL |         asm!(foo); |              ^^^ error: expected token: `,` --> $DIR/parse-error.rs:15:19 | LL |         asm!("{}" foo); |                   ^^^ expected `,` error: expected operand, clobber_abi, options, or additional template string --> $DIR/parse-error.rs:17:20 | LL |         asm!("{}", foo); |                    ^^^ expected operand, clobber_abi, options, or additional template string error: expected `(`, found `foo` --> $DIR/parse-error.rs:19:23 | LL |         asm!("{}", in foo); |                       ^^^ expected `(` error: expected `)`, found `foo` --> $DIR/parse-error.rs:21:27 | LL |         asm!("{}", in(reg foo)); |                           ^^^ expected `)` error: expected expression, found end of macro arguments --> $DIR/parse-error.rs:23:27 | LL |         asm!("{}", in(reg)); |                           ^ expected expression error: expected register class or explicit register --> $DIR/parse-error.rs:25:26 | LL |         asm!("{}", inout(=) foo => bar); |                          ^ error: expected expression, found end of macro arguments --> $DIR/parse-error.rs:27:37 | LL |         asm!("{}", inout(reg) foo =>); |                                     ^ expected expression error: expected one of `!`, `,`, `.`, `::`, `?`, `{`, or an operator, found `=>` --> $DIR/parse-error.rs:29:32 | LL |         asm!("{}", in(reg) foo => bar); |                                ^^ expected one of 7 possible tokens error: expected a path for argument to `sym` --> $DIR/parse-error.rs:31:24 | LL |         asm!("{}", sym foo + bar); |                        ^^^^^^^^^ error: expected one of `)`, `att_syntax`, `may_unwind`, `nomem`, `noreturn`, `nostack`, `preserves_flags`, `pure`, `raw`, or `readonly`, found `foo` --> $DIR/parse-error.rs:33:26 | LL |         asm!("", options(foo)); |                          ^^^ expected one of 10 possible tokens error: expected one of `)` or `,`, found `foo` --> $DIR/parse-error.rs:35:32 | LL |         asm!("", options(nomem foo)); |                                ^^^ expected one of `)` or `,` error: expected one of `)`, `att_syntax`, `may_unwind`, `nomem`, `noreturn`, `nostack`, `preserves_flags`, `pure`, `raw`, or `readonly`, found `foo` --> $DIR/parse-error.rs:37:33 | LL |         asm!("", options(nomem, foo)); |                                 ^^^ expected one of 10 possible tokens error: at least one abi must be provided as an argument to `clobber_abi` --> $DIR/parse-error.rs:44:30 | LL |         asm!("", clobber_abi()); |                              ^ error: expected string literal --> $DIR/parse-error.rs:46:30 | LL |         asm!("", clobber_abi(foo)); |                              ^^^ not a string literal error: expected one of `)` or `,`, found `foo` --> $DIR/parse-error.rs:48:34 | LL |         asm!("", clobber_abi("C" foo)); |                                  ^^^ expected one of `)` or `,` error: expected string literal --> $DIR/parse-error.rs:50:35 | LL |         asm!("", clobber_abi("C", foo)); |                                   ^^^ not a string literal error: expected string literal --> $DIR/parse-error.rs:52:30 | LL |         asm!("", clobber_abi(1)); |                              ^ not a string literal error: expected string literal --> $DIR/parse-error.rs:54:30 | LL |         asm!("", clobber_abi(())); |                              ^ not a string literal error: expected string literal --> $DIR/parse-error.rs:56:30 | LL |         asm!("", clobber_abi(uwu)); |                              ^^^ not a string literal error: expected string literal --> $DIR/parse-error.rs:58:30 | LL |         asm!("", clobber_abi({})); |                              ^ not a string literal error: expected string literal --> $DIR/parse-error.rs:60:30 | LL |         asm!("", clobber_abi(loop {})); |                              ^^^^ not a string literal error: expected string literal --> $DIR/parse-error.rs:62:30 | LL |         asm!("", clobber_abi(if)); |                              ^^ not a string literal error: expected string literal --> $DIR/parse-error.rs:64:30 | LL |         asm!("", clobber_abi(do)); |                              ^^ not a string literal error: expected string literal --> $DIR/parse-error.rs:66:30 | LL |         asm!("", clobber_abi(<)); |                              ^ not a string literal error: expected string literal --> $DIR/parse-error.rs:68:30 | LL |         asm!("", clobber_abi(.)); |                              ^ not a string literal error: duplicate argument named `a` --> $DIR/parse-error.rs:76:36 | LL |         asm!("{a}", a = const foo, a = const bar); |                     -------------  ^^^^^^^^^^^^^ duplicate argument |                     | |                     previously here error: argument never used --> $DIR/parse-error.rs:76:36 | LL |         asm!("{a}", a = const foo, a = const bar); |                                    ^^^^^^^^^^^^^ argument never used | = help: if this argument is intentionally unused, consider using it in an asm comment: `"/* {1} */"` error: expected one of `clobber_abi`, `const`, `in`, `inlateout`, `inout`, `lateout`, `options`, `out`, or `sym`, found `""` --> $DIR/parse-error.rs:82:29 | LL |         asm!("", options(), ""); |                             ^^ expected one of 9 possible tokens error: expected one of `clobber_abi`, `const`, `in`, `inlateout`, `inout`, `lateout`, `options`, `out`, or `sym`, found `"{}"` --> $DIR/parse-error.rs:84:33 | LL |         asm!("{}", in(reg) foo, "{}", out(reg) foo); |                                 ^^^^ expected one of 9 possible tokens error: asm template must be a string literal --> $DIR/parse-error.rs:86:14 | LL |         asm!(format!("{{{}}}", 0), in(reg) foo); |              ^^^^^^^^^^^^^^^^^^^^ | = note: this error originates in the macro `format` (in Nightly builds, run with -Z macro-backtrace for more info) error: asm template must be a string literal --> $DIR/parse-error.rs:88:21 | LL |         asm!("{1}", format!("{{{}}}", 0), in(reg) foo, out(reg) bar); |                     ^^^^^^^^^^^^^^^^^^^^ | = note: this error originates in the macro `format` (in Nightly builds, run with -Z macro-backtrace for more info) error: _ cannot be used for input operands --> $DIR/parse-error.rs:90:28 | LL |         asm!("{}", in(reg) _); |                            ^ error: _ cannot be used for input operands --> $DIR/parse-error.rs:92:31 | LL |         asm!("{}", inout(reg) _); |                               ^ error: _ cannot be used for input operands --> $DIR/parse-error.rs:94:35 | LL |         asm!("{}", inlateout(reg) _); |                                   ^ error: requires at least a template string argument --> $DIR/parse-error.rs:101:1 | LL | global_asm!(); | ^^^^^^^^^^^^^ error: asm template must be a string literal --> $DIR/parse-error.rs:103:13 | LL | global_asm!(FOO); |             ^^^ error: expected token: `,` --> $DIR/parse-error.rs:105:18 | LL | global_asm!("{}" FOO); |                  ^^^ expected `,` error: expected operand, options, or additional template string --> $DIR/parse-error.rs:107:19 | LL | global_asm!("{}", FOO); |                   ^^^ expected operand, options, or additional template string error: expected expression, found end of macro arguments --> $DIR/parse-error.rs:109:24 | LL | global_asm!("{}", const); |                        ^ expected expression error: expected one of `,`, `.`, `?`, or an operator, found `FOO` --> $DIR/parse-error.rs:111:30 | LL | global_asm!("{}", const(reg) FOO); |                              ^^^ expected one of `,`, `.`, `?`, or an operator error: expected one of `)`, `att_syntax`, or `raw`, found `FOO` --> $DIR/parse-error.rs:113:25 | LL | global_asm!("", options(FOO)); |                         ^^^ expected one of `)`, `att_syntax`, or `raw` error: expected one of `)`, `att_syntax`, or `raw`, found `nomem` --> $DIR/parse-error.rs:115:25 | LL | global_asm!("", options(nomem FOO)); |                         ^^^^^ expected one of `)`, `att_syntax`, or `raw` error: expected one of `)`, `att_syntax`, or `raw`, found `nomem` --> $DIR/parse-error.rs:117:25 | LL | global_asm!("", options(nomem, FOO)); |                         ^^^^^ expected one of `)`, `att_syntax`, or `raw` error: expected string literal --> $DIR/parse-error.rs:120:29 | LL | global_asm!("", clobber_abi(FOO)); |                             ^^^ not a string literal error: expected one of `)` or `,`, found `FOO` --> $DIR/parse-error.rs:122:33 | LL | global_asm!("", clobber_abi("C" FOO)); |                                 ^^^ expected one of `)` or `,` error: expected string literal --> $DIR/parse-error.rs:124:34 | LL | global_asm!("", clobber_abi("C", FOO)); |                                  ^^^ not a string literal error: `clobber_abi` cannot be used with `global_asm!` --> $DIR/parse-error.rs:126:19 | LL | global_asm!("{}", clobber_abi("C"), const FOO); |                   ^^^^^^^^^^^^^^^^ error: `clobber_abi` cannot be used with `global_asm!` --> $DIR/parse-error.rs:128:28 | LL | global_asm!("", options(), clobber_abi("C")); |                            ^^^^^^^^^^^^^^^^ error: `clobber_abi` cannot be used with `global_asm!` --> $DIR/parse-error.rs:130:30 | LL | global_asm!("{}", options(), clobber_abi("C"), const FOO); |                              ^^^^^^^^^^^^^^^^ error: `clobber_abi` cannot be used with `global_asm!` --> $DIR/parse-error.rs:132:17 | LL | global_asm!("", clobber_abi("C"), clobber_abi("C")); |                 ^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^ error: duplicate argument named `a` --> $DIR/parse-error.rs:134:35 | LL | global_asm!("{a}", a = const FOO, a = const BAR); |                    -------------  ^^^^^^^^^^^^^ duplicate argument |                    | |                    previously here error: argument never used --> $DIR/parse-error.rs:134:35 | LL | global_asm!("{a}", a = const FOO, a = const BAR); |                                   ^^^^^^^^^^^^^ argument never used | = help: if this argument is intentionally unused, consider using it in an asm comment: `"/* {1} */"` error: expected one of `clobber_abi`, `const`, `options`, or `sym`, found `""` --> $DIR/parse-error.rs:137:28 | LL | global_asm!("", options(), ""); |                            ^^ expected one of `clobber_abi`, `const`, `options`, or `sym` error: expected one of `clobber_abi`, `const`, `options`, or `sym`, found `"{}"` --> $DIR/parse-error.rs:139:30 | LL | global_asm!("{}", const FOO, "{}", const FOO); |                              ^^^^ expected one of `clobber_abi`, `const`, `options`, or `sym` error: asm template must be a string literal --> $DIR/parse-error.rs:141:13 | LL | global_asm!(format!("{{{}}}", 0), const FOO); |             ^^^^^^^^^^^^^^^^^^^^ | = note: this error originates in the macro `format` (in Nightly builds, run with -Z macro-backtrace for more info) error: asm template must be a string literal --> $DIR/parse-error.rs:143:20 | LL | global_asm!("{1}", format!("{{{}}}", 0), const FOO, const BAR); |                    ^^^^^^^^^^^^^^^^^^^^ | = note: this error originates in the macro `format` (in Nightly builds, run with -Z macro-backtrace for more info) error[E0435]: attempt to use a non-constant value in a constant --> $DIR/parse-error.rs:39:37 | LL |     let mut foo = 0; |     ----------- help: consider using `const` instead of `let`: `const foo` ... LL |         asm!("{}", options(), const foo); |                                     ^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/parse-error.rs:71:44 | LL |     let mut foo = 0; |     ----------- help: consider using `const` instead of `let`: `const foo` ... LL |         asm!("{}", clobber_abi("C"), const foo); |                                            ^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/parse-error.rs:74:55 | LL |     let mut foo = 0; |     ----------- help: consider using `const` instead of `let`: `const foo` ... LL |         asm!("{}", options(), clobber_abi("C"), const foo); |                                                       ^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/parse-error.rs:76:31 | LL |     let mut foo = 0; |     ----------- help: consider using `const` instead of `let`: `const foo` ... LL |         asm!("{a}", a = const foo, a = const bar); |                               ^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/parse-error.rs:76:46 | LL |     let mut bar = 0; |     ----------- help: consider using `const` instead of `let`: `const bar` ... LL |         asm!("{a}", a = const foo, a = const bar); |                                              ^^^ non-constant value error: aborting due to 63 previous errors For more information about this error, try `rustc --explain E0435`. </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.58:
This was , whoops. I can work on this. claim

<del> // only-x86_64 #![feature(asm_const)] use std::arch::{asm, global_asm}; fn main() { let mut foo = 0; let mut bar = 0; unsafe { asm!(); //~^ ERROR requires at least a template string argument asm!(foo); //~^ ERROR asm template must be a string literal asm!("{}" foo); //~^ ERROR expected token: `,` asm!("{}", foo); //~^ ERROR expected operand, clobber_abi, options, or additional template string asm!("{}", in foo); //~^ ERROR expected `(`, found `foo` asm!("{}", in(reg foo)); //~^ ERROR expected `)`, found `foo` asm!("{}", in(reg)); //~^ ERROR expected expression, found end of macro arguments asm!("{}", inout(=) foo => bar); //~^ ERROR expected register class or explicit register asm!("{}", inout(reg) foo =>); //~^ ERROR expected expression, found end of macro arguments asm!("{}", in(reg) foo => bar); //~^ ERROR expected one of `!`, `,`, `.`, `::`, `?`, `{`, or an operator, found `=>` asm!("{}", sym foo + bar); //~^ ERROR expected a path for argument to `sym` asm!("", options(foo)); //~^ ERROR expected one of asm!("", options(nomem foo)); //~^ ERROR expected one of asm!("", options(nomem, foo)); //~^ ERROR expected one of asm!("{}", options(), const foo); //~^ ERROR attempt to use a non-constant value in a constant asm!("", clobber_abi()); //~^ ERROR at least one abi must be provided asm!("", clobber_abi(foo)); //~^ ERROR expected string literal asm!("", clobber_abi("C" foo)); //~^ ERROR expected one of `)` or `,`, found `foo` asm!("", clobber_abi("C", foo)); //~^ ERROR expected string literal asm!("{}", clobber_abi("C"), const foo); //~^ ERROR attempt to use a non-constant value in a constant asm!("", options(), clobber_abi("C")); asm!("{}", options(), clobber_abi("C"), const foo); //~^ ERROR attempt to use a non-constant value in a constant asm!("{a}", a = const foo, a = const bar); //~^ ERROR duplicate argument named `a` //~^^ ERROR argument never used //~^^^ ERROR attempt to use a non-constant value in a constant //~^^^^ ERROR attempt to use a non-constant value in a constant asm!("", a = in("eax") foo); //~^ ERROR explicit register arguments cannot have names asm!("{a}", in("eax") foo, a = const bar); //~^ ERROR attempt to use a non-constant value in a constant asm!("{a}", in("eax") foo, a = const bar); //~^ ERROR attempt to use a non-constant value in a constant asm!("{1}", in("eax") foo, const bar); //~^ ERROR positional arguments cannot follow named arguments or explicit register arguments //~^^ ERROR attempt to use a non-constant value in a constant asm!("", options(), ""); //~^ ERROR expected one of asm!("{}", in(reg) foo, "{}", out(reg) foo); //~^ ERROR expected one of asm!(format!("{{{}}}", 0), in(reg) foo); //~^ ERROR asm template must be a string literal asm!("{1}", format!("{{{}}}", 0), in(reg) foo, out(reg) bar); //~^ ERROR asm template must be a string literal asm!("{}", in(reg) _); //~^ ERROR _ cannot be used for input operands asm!("{}", inout(reg) _); //~^ ERROR _ cannot be used for input operands asm!("{}", inlateout(reg) _); //~^ ERROR _ cannot be used for input operands } } const FOO: i32 = 1; const BAR: i32 = 2; global_asm!(); //~^ ERROR requires at least a template string argument global_asm!(FOO); //~^ ERROR asm template must be a string literal global_asm!("{}" FOO); //~^ ERROR expected token: `,` global_asm!("{}", FOO); //~^ ERROR expected operand, options, or additional template string global_asm!("{}", const); //~^ ERROR expected expression, found end of macro arguments global_asm!("{}", const(reg) FOO); //~^ ERROR expected one of global_asm!("", options(FOO)); //~^ ERROR expected one of global_asm!("", options(nomem FOO)); //~^ ERROR expected one of global_asm!("", options(nomem, FOO)); //~^ ERROR expected one of global_asm!("{}", options(), const FOO); global_asm!("", clobber_abi(FOO)); //~^ ERROR expected string literal global_asm!("", clobber_abi("C" FOO)); //~^ ERROR expected one of `)` or `,`, found `FOO` global_asm!("", clobber_abi("C", FOO)); //~^ ERROR expected string literal global_asm!("{}", clobber_abi("C"), const FOO); //~^ ERROR `clobber_abi` cannot be used with `global_asm!` global_asm!("", options(), clobber_abi("C")); //~^ ERROR `clobber_abi` cannot be used with `global_asm!` global_asm!("{}", options(), clobber_abi("C"), const FOO); //~^ ERROR `clobber_abi` cannot be used with `global_asm!` global_asm!("", clobber_abi("C"), clobber_abi("C")); //~^ ERROR `clobber_abi` cannot be used with `global_asm!` global_asm!("{a}", a = const FOO, a = const BAR); //~^ ERROR duplicate argument named `a` //~^^ ERROR argument never used global_asm!("", options(), ""); //~^ ERROR expected one of global_asm!("{}", const FOO, "{}", const FOO); //~^ ERROR expected one of global_asm!(format!("{{{}}}", 0), const FOO); //~^ ERROR asm template must be a string literal global_asm!("{1}", format!("{{{}}}", 0), const FOO, const BAR); //~^ ERROR asm template must be a string literal </del>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.58:
This was , whoops. I can work on this. claim

<del> error: requires at least a template string argument --> $DIR/parse-error.rs:11:9 | LL |         asm!(); |         ^^^^^^ error: asm template must be a string literal --> $DIR/parse-error.rs:13:14 | LL |         asm!(foo); |              ^^^ error: expected token: `,` --> $DIR/parse-error.rs:15:19 | LL |         asm!("{}" foo); |                   ^^^ expected `,` error: expected operand, clobber_abi, options, or additional template string --> $DIR/parse-error.rs:17:20 | LL |         asm!("{}", foo); |                    ^^^ expected operand, clobber_abi, options, or additional template string error: expected `(`, found `foo` --> $DIR/parse-error.rs:19:23 | LL |         asm!("{}", in foo); |                       ^^^ expected `(` error: expected `)`, found `foo` --> $DIR/parse-error.rs:21:27 | LL |         asm!("{}", in(reg foo)); |                           ^^^ expected `)` error: expected expression, found end of macro arguments --> $DIR/parse-error.rs:23:27 | LL |         asm!("{}", in(reg)); |                           ^ expected expression error: expected register class or explicit register --> $DIR/parse-error.rs:25:26 | LL |         asm!("{}", inout(=) foo => bar); |                          ^ error: expected expression, found end of macro arguments --> $DIR/parse-error.rs:27:37 | LL |         asm!("{}", inout(reg) foo =>); |                                     ^ expected expression error: expected one of `!`, `,`, `.`, `::`, `?`, `{`, or an operator, found `=>` --> $DIR/parse-error.rs:29:32 | LL |         asm!("{}", in(reg) foo => bar); |                                ^^ expected one of 7 possible tokens error: expected a path for argument to `sym` --> $DIR/parse-error.rs:31:24 | LL |         asm!("{}", sym foo + bar); |                        ^^^^^^^^^ error: expected one of `)`, `att_syntax`, `may_unwind`, `nomem`, `noreturn`, `nostack`, `preserves_flags`, `pure`, `raw`, or `readonly`, found `foo` --> $DIR/parse-error.rs:33:26 | LL |         asm!("", options(foo)); |                          ^^^ expected one of 10 possible tokens error: expected one of `)` or `,`, found `foo` --> $DIR/parse-error.rs:35:32 | LL |         asm!("", options(nomem foo)); |                                ^^^ expected one of `)` or `,` error: expected one of `)`, `att_syntax`, `may_unwind`, `nomem`, `noreturn`, `nostack`, `preserves_flags`, `pure`, `raw`, or `readonly`, found `foo` --> $DIR/parse-error.rs:37:33 | LL |         asm!("", options(nomem, foo)); |                                 ^^^ expected one of 10 possible tokens error: at least one abi must be provided as an argument to `clobber_abi` --> $DIR/parse-error.rs:41:30 | LL |         asm!("", clobber_abi()); |                              ^ error: expected string literal --> $DIR/parse-error.rs:43:30 | LL |         asm!("", clobber_abi(foo)); |                              ^^^ not a string literal error: expected one of `)` or `,`, found `foo` --> $DIR/parse-error.rs:45:34 | LL |         asm!("", clobber_abi("C" foo)); |                                  ^^^ expected one of `)` or `,` error: expected string literal --> $DIR/parse-error.rs:47:35 | LL |         asm!("", clobber_abi("C", foo)); |                                   ^^^ not a string literal error: duplicate argument named `a` --> $DIR/parse-error.rs:54:36 | LL |         asm!("{a}", a = const foo, a = const bar); |                     -------------  ^^^^^^^^^^^^^ duplicate argument |                     | |                     previously here error: argument never used --> $DIR/parse-error.rs:54:36 | LL |         asm!("{a}", a = const foo, a = const bar); |                                    ^^^^^^^^^^^^^ argument never used | = help: if this argument is intentionally unused, consider using it in an asm comment: `"/* {1} */"` error: explicit register arguments cannot have names --> $DIR/parse-error.rs:59:18 | LL |         asm!("", a = in("eax") foo); |                  ^^^^^^^^^^^^^^^^^ error: positional arguments cannot follow named arguments or explicit register arguments --> $DIR/parse-error.rs:65:36 | LL |         asm!("{1}", in("eax") foo, const bar); |                     -------------  ^^^^^^^^^ positional argument |                     | |                     explicit register argument error: expected one of `clobber_abi`, `const`, `in`, `inlateout`, `inout`, `lateout`, `options`, `out`, or `sym`, found `""` --> $DIR/parse-error.rs:68:29 | LL |         asm!("", options(), ""); |                             ^^ expected one of 9 possible tokens error: expected one of `clobber_abi`, `const`, `in`, `inlateout`, `inout`, `lateout`, `options`, `out`, or `sym`, found `"{}"` --> $DIR/parse-error.rs:70:33 | LL |         asm!("{}", in(reg) foo, "{}", out(reg) foo); |                                 ^^^^ expected one of 9 possible tokens error: asm template must be a string literal --> $DIR/parse-error.rs:72:14 | LL |         asm!(format!("{{{}}}", 0), in(reg) foo); |              ^^^^^^^^^^^^^^^^^^^^ | = note: this error originates in the macro `format` (in Nightly builds, run with -Z macro-backtrace for more info) error: asm template must be a string literal --> $DIR/parse-error.rs:74:21 | LL |         asm!("{1}", format!("{{{}}}", 0), in(reg) foo, out(reg) bar); |                     ^^^^^^^^^^^^^^^^^^^^ | = note: this error originates in the macro `format` (in Nightly builds, run with -Z macro-backtrace for more info) error: _ cannot be used for input operands --> $DIR/parse-error.rs:76:28 | LL |         asm!("{}", in(reg) _); |                            ^ error: _ cannot be used for input operands --> $DIR/parse-error.rs:78:31 | LL |         asm!("{}", inout(reg) _); |                               ^ error: _ cannot be used for input operands --> $DIR/parse-error.rs:80:35 | LL |         asm!("{}", inlateout(reg) _); |                                   ^ error: requires at least a template string argument --> $DIR/parse-error.rs:87:1 | LL | global_asm!(); | ^^^^^^^^^^^^^ error: asm template must be a string literal --> $DIR/parse-error.rs:89:13 | LL | global_asm!(FOO); |             ^^^ error: expected token: `,` --> $DIR/parse-error.rs:91:18 | LL | global_asm!("{}" FOO); |                  ^^^ expected `,` error: expected operand, options, or additional template string --> $DIR/parse-error.rs:93:19 | LL | global_asm!("{}", FOO); |                   ^^^ expected operand, options, or additional template string error: expected expression, found end of macro arguments --> $DIR/parse-error.rs:95:24 | LL | global_asm!("{}", const); |                        ^ expected expression error: expected one of `,`, `.`, `?`, or an operator, found `FOO` --> $DIR/parse-error.rs:97:30 | LL | global_asm!("{}", const(reg) FOO); |                              ^^^ expected one of `,`, `.`, `?`, or an operator error: expected one of `)`, `att_syntax`, or `raw`, found `FOO` --> $DIR/parse-error.rs:99:25 | LL | global_asm!("", options(FOO)); |                         ^^^ expected one of `)`, `att_syntax`, or `raw` error: expected one of `)`, `att_syntax`, or `raw`, found `nomem` --> $DIR/parse-error.rs:101:25 | LL | global_asm!("", options(nomem FOO)); |                         ^^^^^ expected one of `)`, `att_syntax`, or `raw` error: expected one of `)`, `att_syntax`, or `raw`, found `nomem` --> $DIR/parse-error.rs:103:25 | LL | global_asm!("", options(nomem, FOO)); |                         ^^^^^ expected one of `)`, `att_syntax`, or `raw` error: expected string literal --> $DIR/parse-error.rs:106:29 | LL | global_asm!("", clobber_abi(FOO)); |                             ^^^ not a string literal error: expected one of `)` or `,`, found `FOO` --> $DIR/parse-error.rs:108:33 | LL | global_asm!("", clobber_abi("C" FOO)); |                                 ^^^ expected one of `)` or `,` error: expected string literal --> $DIR/parse-error.rs:110:34 | LL | global_asm!("", clobber_abi("C", FOO)); |                                  ^^^ not a string literal error: `clobber_abi` cannot be used with `global_asm!` --> $DIR/parse-error.rs:112:19 | LL | global_asm!("{}", clobber_abi("C"), const FOO); |                   ^^^^^^^^^^^^^^^^ error: `clobber_abi` cannot be used with `global_asm!` --> $DIR/parse-error.rs:114:28 | LL | global_asm!("", options(), clobber_abi("C")); |                            ^^^^^^^^^^^^^^^^ error: `clobber_abi` cannot be used with `global_asm!` --> $DIR/parse-error.rs:116:30 | LL | global_asm!("{}", options(), clobber_abi("C"), const FOO); |                              ^^^^^^^^^^^^^^^^ error: `clobber_abi` cannot be used with `global_asm!` --> $DIR/parse-error.rs:118:17 | LL | global_asm!("", clobber_abi("C"), clobber_abi("C")); |                 ^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^ error: duplicate argument named `a` --> $DIR/parse-error.rs:120:35 | LL | global_asm!("{a}", a = const FOO, a = const BAR); |                    -------------  ^^^^^^^^^^^^^ duplicate argument |                    | |                    previously here error: argument never used --> $DIR/parse-error.rs:120:35 | LL | global_asm!("{a}", a = const FOO, a = const BAR); |                                   ^^^^^^^^^^^^^ argument never used | = help: if this argument is intentionally unused, consider using it in an asm comment: `"/* {1} */"` error: expected one of `clobber_abi`, `const`, `options`, or `sym`, found `""` --> $DIR/parse-error.rs:123:28 | LL | global_asm!("", options(), ""); |                            ^^ expected one of `clobber_abi`, `const`, `options`, or `sym` error: expected one of `clobber_abi`, `const`, `options`, or `sym`, found `"{}"` --> $DIR/parse-error.rs:125:30 | LL | global_asm!("{}", const FOO, "{}", const FOO); |                              ^^^^ expected one of `clobber_abi`, `const`, `options`, or `sym` error: asm template must be a string literal --> $DIR/parse-error.rs:127:13 | LL | global_asm!(format!("{{{}}}", 0), const FOO); |             ^^^^^^^^^^^^^^^^^^^^ | = note: this error originates in the macro `format` (in Nightly builds, run with -Z macro-backtrace for more info) error: asm template must be a string literal --> $DIR/parse-error.rs:129:20 | LL | global_asm!("{1}", format!("{{{}}}", 0), const FOO, const BAR); |                    ^^^^^^^^^^^^^^^^^^^^ | = note: this error originates in the macro `format` (in Nightly builds, run with -Z macro-backtrace for more info) error[E0435]: attempt to use a non-constant value in a constant --> $DIR/parse-error.rs:39:37 | LL |     let mut foo = 0; |     ----------- help: consider using `const` instead of `let`: `const foo` ... LL |         asm!("{}", options(), const foo); |                                     ^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/parse-error.rs:49:44 | LL |     let mut foo = 0; |     ----------- help: consider using `const` instead of `let`: `const foo` ... LL |         asm!("{}", clobber_abi("C"), const foo); |                                            ^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/parse-error.rs:52:55 | LL |     let mut foo = 0; |     ----------- help: consider using `const` instead of `let`: `const foo` ... LL |         asm!("{}", options(), clobber_abi("C"), const foo); |                                                       ^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/parse-error.rs:54:31 | LL |     let mut foo = 0; |     ----------- help: consider using `const` instead of `let`: `const foo` ... LL |         asm!("{a}", a = const foo, a = const bar); |                               ^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/parse-error.rs:54:46 | LL |     let mut bar = 0; |     ----------- help: consider using `const` instead of `let`: `const bar` ... LL |         asm!("{a}", a = const foo, a = const bar); |                                              ^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/parse-error.rs:61:46 | LL |     let mut bar = 0; |     ----------- help: consider using `const` instead of `let`: `const bar` ... LL |         asm!("{a}", in("eax") foo, a = const bar); |                                              ^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/parse-error.rs:63:46 | LL |     let mut bar = 0; |     ----------- help: consider using `const` instead of `let`: `const bar` ... LL |         asm!("{a}", in("eax") foo, a = const bar); |                                              ^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/parse-error.rs:65:42 | LL |     let mut bar = 0; |     ----------- help: consider using `const` instead of `let`: `const bar` ... LL |         asm!("{1}", in("eax") foo, const bar); |                                          ^^^ non-constant value error: aborting due to 59 previous errors For more information about this error, try `rustc --explain E0435`. </del>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.58:
This was , whoops. I can work on this. claim

<ins> // only-x86_64 #![feature(asm_const)] use std::arch::asm; fn main() { let mut foo = 0; let mut bar = 0; unsafe { asm!("", a = in("eax") foo); //~^ ERROR explicit register arguments cannot have names asm!("{a}", in("eax") foo, a = const bar); //~^ ERROR attempt to use a non-constant value in a constant asm!("{a}", in("eax") foo, a = const bar); //~^ ERROR attempt to use a non-constant value in a constant asm!("{1}", in("eax") foo, const bar); //~^ ERROR positional arguments cannot follow named arguments or explicit register arguments //~^^ ERROR attempt to use a non-constant value in a constant } } </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.58:
This was , whoops. I can work on this. claim

<ins> error: explicit register arguments cannot have names --> $DIR/x86_64_parse_error.rs:11:18 | LL |         asm!("", a = in("eax") foo); |                  ^^^^^^^^^^^^^^^^^ error: positional arguments cannot follow named arguments or explicit register arguments --> $DIR/x86_64_parse_error.rs:17:36 | LL |         asm!("{1}", in("eax") foo, const bar); |                     -------------  ^^^^^^^^^ positional argument |                     | |                     explicit register argument error[E0435]: attempt to use a non-constant value in a constant --> $DIR/x86_64_parse_error.rs:13:46 | LL |     let mut bar = 0; |     ----------- help: consider using `const` instead of `let`: `const bar` ... LL |         asm!("{a}", in("eax") foo, a = const bar); |                                              ^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/x86_64_parse_error.rs:15:46 | LL |     let mut bar = 0; |     ----------- help: consider using `const` instead of `let`: `const bar` ... LL |         asm!("{a}", in("eax") foo, a = const bar); |                                              ^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/x86_64_parse_error.rs:17:42 | LL |     let mut bar = 0; |     ----------- help: consider using `const` instead of `let`: `const bar` ... LL |         asm!("{1}", in("eax") foo, const bar); |                                          ^^^ non-constant value error: aborting due to 5 previous errors For more information about this error, try `rustc --explain E0435`. </ins>


Question:
This code previously compiled fine, but as of ~2 weeks ago it began to fail on nightly and has continued to do so since. p.s. Is the output of suppose to be one day behind compared to the toolchain name? In any case, was the last working version, and onward trigger the error. modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc
I can put up a fix for this. I suspected this might cause an issue but couldn't think how.

// They can denote both statically and dynamically-sized byte arrays. let mut pat_ty = ty; if let hir::ExprKind::Lit(Spanned { node: ast::LitKind::ByteStr(..), .. }) = lt.kind { <del> if let ty::Ref(_, inner_ty, _) = *self.structurally_resolved_type(span, expected).kind() && self.structurally_resolved_type(span, inner_ty).is_slice() </del> <ins> let expected = self.structurally_resolved_type(span, expected); if let ty::Ref(_, inner_ty, _) = expected.kind() && matches!(inner_ty.kind(), ty::Slice(_)) </ins> { let tcx = self.tcx; trace!(?lt.hir_id.local_id, "polymorphic byte string lit");


Question:
This code previously compiled fine, but as of ~2 weeks ago it began to fail on nightly and has continued to do so since. p.s. Is the output of suppose to be one day behind compared to the toolchain name? In any case, was the last working version, and onward trigger the error. modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc
I can put up a fix for this. I suspected this might cause an issue but couldn't think how.

<ins> // check-pass fn load<L>() -> Option<L> { todo!() } fn main() { while let Some(tag) = load() { match &tag { b"NAME" => {} b"DATA" => {} _ => {} } } } </ins>


Question:
This code previously compiled fine, but as of ~2 weeks ago it began to fail on nightly and has continued to do so since. p.s. Is the output of suppose to be one day behind compared to the toolchain name? In any case, was the last working version, and onward trigger the error. modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc
I can put up a fix for this. I suspected this might cause an issue but couldn't think how.

// compile-flags: -Ztrait-solver=next <del> // check-pass </del> <ins> // known-bug: rust-lang/trait-system-refactor-initiative#38 </ins> fn test(s: &[u8]) { match &s[0..3] {


Question:
This code previously compiled fine, but as of ~2 weeks ago it began to fail on nightly and has continued to do so since. p.s. Is the output of suppose to be one day behind compared to the toolchain name? In any case, was the last working version, and onward trigger the error. modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc
I can put up a fix for this. I suspected this might cause an issue but couldn't think how.

<ins> error[E0271]: type mismatch resolving `[u8; 3] <: <Range<usize> as SliceIndex<[u8]>>::Output` --> $DIR/slice-match-byte-lit.rs:6:9 | LL |     match &s[0..3] { |           -------- this expression has type `&<std::ops::Range<usize> as SliceIndex<[u8]>>::Output` LL |         b"uwu" => {} |         ^^^^^^ types differ error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </ins>


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --The generated page HTML contains , which is not valid as per the (which only allows ). This has been the case since , which moved this div from the body to the header. I believe browsers will open the body if an invalid tag is encountered in the header (which you can see in inspect elements, where every item in between are inside of ), or something like that. This causes at least one bug: the attribute, which expands into a , is not displayed on Chrome and Chromium-based browsers. You can see this in the  crate on Chrome ! Firefox ! Generated HTML: vs : Manually moving the tag to the header correctly displays the favicon: ! !
label A-rustdoc-ui T-rustdoc
Thanks for the detailed report! Fixing it tomorrow.

map.insert("toggle-all-docs".into(), 1); map.insert("all-types".into(), 1); map.insert("default-settings".into(), 1); <del> map.insert("rustdoc-vars".into(), 1); </del> map.insert("sidebar-vars".into(), 1); map.insert("copy-path".into(), 1); map.insert("TOC".into(), 1);