jiebi/CodeConvo huggingface dataset:
Change:
Unfortunately I can't get a backtrace as running inside a debugger prevents it from crashing. Reproduction: Clone Checkout commit and follow the instructions on the top of the readme. Sometimes the execution succeeds, so you may have to remove the dir when it succeeded.
Got backtraces for all thread by loading a core dump:
After trying compiling it many times it does succeed, but the resulting wasm file is corrupt: . This may have the same cause, but I am not sure.
Based on ^-- I'm tentatively labeling as a soundness hole since it seems that type preservation is violated? (Haven't looked closely)
Reduced repro: <details</summary</detailsEdit: Reduced it even more.
I've got a bit more specific one from
LLVM IR for reproducer: Running this through against current LLVM master gives the following assertion failure: With backtrace:
Reduced test case:
Upstream report:
Fixed upstream:
Thanks so much for tracking that down and fixing it! I've opened an update of our submodule at

Discussion:
<del> Subproject commit 84abffda0e03b03c62bdfc3cfeda1c2cf1f88c85 </del> <ins> Subproject commit eb38a1888d1d29b2d2c6b31428a5201cd8fba0ff </ins>
Change:
adds: Like with , the input pointed type does not need to be but the output pointed type does, because we wouldn’t know what appropriate pointer metadata (slice length, trait object vtable, …) to insert. The actual requirement is that the pointer is thin, but is the closest approximation we have (until we add something like ).
Let’s? fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Getting this issue when executing: More detail:
Your Rust installation is out of date.

Discussion:
} /// Cast to a pointer to a different type <del> #[unstable(feature = "ptr_cast", issue = "60602")] </del> <ins> #[stable(feature = "ptr_cast", since = "1.38.0")] </ins> #[inline] pub const fn cast<U>(self) -> *const U { self as _

} /// Cast to a pointer to a different type <del> #[unstable(feature = "ptr_cast", issue = "60602")] </del> <ins> #[stable(feature = "ptr_cast", since = "1.38.0")] </ins> #[inline] pub const fn cast<U>(self) -> *mut U { self as _
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.

Discussion:
<del> Subproject commit fc96aa036884183ddc68d2659f4633e6f138b4e0 </del> <ins> Subproject commit 341c96afd331195beeb001436535c1feb479ff9d </ins>
Change:
This one is very interesting IMHO. The "original" ICE was introduced between ..., but if I prepend the before (the outcommented line), there's a second ICE that is there forever (at least since Rust 1.11). modify labels: I-ICE C-bug
modify labels: I-ICE C-bug T-compiler (seems that I cannot ping rustbot from the thread start itself)
Reduced:
This issue exists all the way back to at least 1.7.0.

Discussion:
} } def => { <del> span_bug!(pat.span, "tuple struct pattern didn't resolve  to variant or struct {:?}", def); </del> <ins> debug!( "tuple struct pattern didn't resolve to variant or struct {:?} at {:?}", def, pat.span, ); self.tcx.sess.delay_span_bug(pat.span, &format!( "tuple struct pattern didn't resolve to variant or struct {:?}", def, )); return Err(()); </ins> } };

<ins> struct A {} impl A { fn new() {} } fn hof<F>(_: F) where F: FnMut(()) {} fn ice() { hof(|c| match c { A::new() => (), //~ ERROR expected tuple struct/variant, found method _ => () }) } fn main() {} </ins>

<ins> error[E0164]: expected tuple struct/variant, found method `<A>::new` --> $DIR/fn-in-pat.rs:11:9 | LL |         A::new() => (), |         ^^^^^^^^ not a tuple variant or struct error: aborting due to previous error For more information about this error, try `rustc --explain E0164`. </ins>
Change:
cc
Am I correct in assuming that this should not compile, but report an error about returning a reference to the local variable ? Or is the self-borrowing generator part what makes this work? so the is part of the generator struct and the is the yielded thing? I'll try pretty printing to the expanded HIR, since I'm not sure what's going on there
Expanded version:
No, this should definitely compile. isn't yielded, but yes, it's a local variable inside the generator (that references another local variable in the generator).
Hmm, so because the generator contains references, it has lifetimes, but these lifetimes actually refer to the generator again? Do we have a special kind of lifetime that we use for this? We should just ignore those generator lifetimes for existential types.
There's no special lifetime afaik (cc
We should ignore all bound regions. Function pointers have the same issue:

Discussion:
let hir_id = self.tcx().hir().as_local_hir_id(def_id).unwrap(); let instantiated_ty = self.resolve(&opaque_defn.concrete_ty, &hir_id); <ins> debug_assert!(!instantiated_ty.has_escaping_bound_vars()); </ins> let generics = self.tcx().generics_of(def_id); let definition_ty = if generics.parent.is_some() {

}, lt_op: |region| { match region { <del> // ignore static regions ty::ReStatic => region, </del> <ins> // Skip static and bound regions: they don't // require substitution. ty::ReStatic | ty::ReLateBound(..) => region, </ins> _ => { trace!("checking {:?}", region); for (subst, p) in opaque_defn.substs.iter().zip(&generics.params) {

<ins> // Test that existential types are allowed to contain late-bound regions. // compile-pass // edition:2018 #![feature(async_await, existential_type)] use std::future::Future; pub existential type Func: Sized; // Late bound region should be allowed to escape the function, since it's bound // in the type. fn null_function_ptr() -> Func { None::<for<'a> fn(&'a ())> } async fn async_nop(_: &u8) {} pub existential type ServeFut: Future<Output=()>; // Late bound regions occur in the generator witness type here. fn serve() -> ServeFut { async move { let x = 5; async_nop(&x).await } } fn main() {} </ins>
Change:
expanded with yields we should not print that extra
Hi, I will like to work on this issue.
awesome! Most likely all that is required is to remove you can check if there's a test in that has a comment with in it. If there is, just add the above test line to it and run tests with . If there is no such test, add such a test ;)
I think I fixed this in one of my PRs, but not sure when it will merge, so go for it. :-)
While adding test, I am getting following error message: The existing test can be seen here:
you need to add to the test
Added that, many thanks!

Discussion:
self.print_where_clause(&exist.generics.where_clause)?; self.s.space()?; <del> self.word_space(":")?; </del> let mut real_bounds = Vec::with_capacity(exist.bounds.len()); for b in exist.bounds.iter() { if let GenericBound::Trait(ref ptr, hir::TraitBoundModifier::Maybe) = *b {

<ins> // compile-pass // compile-flags: -Z unpretty=hir #![feature(existential_type)] trait Animal { } fn main() { pub existential type ServeFut: Animal; } </ins>

<ins> // compile-pass // compile-flags: -Z unpretty=hir #![feature(existential_type)] #[prelude_import] use ::std::prelude::v1::*; #[macro_use] extern crate std; trait Animal { } fn main() { pub existential type ServeFut : Animal; } </ins>
Change:
produces: which is clearly incorrect.
What I believe is happening here is that is no longer treated as a parameter, because it's in brackets. It's a when it gets to rather than a parameter.

Discussion:
ty, }; <del> let expr = &tcx.hir().body(ast_const.body).value; </del> <ins> let mut expr = &tcx.hir().body(ast_const.body).value; // Unwrap a block, so that e.g. `{ P }` is recognised as a parameter. Const arguments // currently have to be wrapped in curly brackets, so it's necessary to special-case. if let ExprKind::Block(block, _) = &expr.node { if block.stmts.is_empty() { if let Some(trailing) = &block.expr { expr = &trailing; } } } </ins> if let ExprKind::Path(ref qpath) = expr.node { if let hir::QPath::Resolved(_, ref path) = qpath { if let Res::Def(DefKind::ConstParam, def_id) = path.res {

<ins> // run-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct S<const X: u32>; impl<const X: u32> S<{X}> { fn x() -> u32 { X } } fn main() { assert_eq!(S::<19>::x(), 19); } </ins>

<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/impl-const-generic-struct.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ </ins>
Change:
I noticed the keyword seems to be missing from the [official documentation][docs]. Keywords like and are documented. Nor does come up when searching at the top. Is there a reason for it missing? [docs]:
These are probably just missing because nobody documentation for them yet, so feel free to send a PR.
If anyone is interested, you need to add documentation here:
I will take care of this one :)
Cool! Wanted to do it, but haven't been able to start on it yet. Perfect if you can take it over.
In that case, it will be nice to have you review the PR:
Partially resolved by I think this can be closed in favor of . What do you think ?
will close this when merged, and it addresses specifically, so we can also wait for that to land

Discussion:
/// [Reference]: ../reference/statements.html#let-statements mod let_keyword { } <ins> #[doc(keyword = "while")] // /// Loop while a condition is upheld. /// /// A `while` expression is used for predicate loops. The `while` expression runs the conditional /// expression before running the loop body, then runs the loop body if the conditional /// expression evaluates to `true`, or exits the loop otherwise. /// /// ```rust /// let mut counter = 0; /// /// while counter < 10 { ///     println!("{}", counter); ///     counter += 1; /// } /// ``` /// /// Like the [`for`] expression, we can use `break` and `continue`. A `while` expression /// cannot break with a value and always evaluates to `()` unlike [`loop`]. /// /// ```rust /// let mut i = 1; /// /// while i < 100 { ///     i *= 2; ///     if i == 64 { ///         break; // Exit when `i` is 64. ///     } /// } /// ``` /// /// As `if` expressions have their pattern matching variant in `if let`, so too do `while` /// expressions with `while let`. The `while let` expression matches the pattern against the /// expression, then runs the loop body if pattern matching succeeds, or exits the loop otherwise. /// We can use `break` and `continue` in `while let` expressions just like in `while`. /// /// ```rust /// let mut counter = Some(0); /// /// while let Some(i) = counter { ///     if i == 10 { ///         counter = None; ///     } else { ///         println!("{}", i); ///         counter = Some (i + 1); ///     } /// } /// ``` /// /// For more information on `while` and loops in general, see the [reference]. /// /// [`for`]: keyword.for.html /// [`loop`]: keyword.loop.html /// [reference]: ../reference/expressions/loop-expr.html#predicate-loops mod while_keyword { } </ins> #[doc(keyword = "loop")] // /// Loop indefinitely.

/// [not yet complete]: https://github.com/rust-lang/rust/issues/34601 mod where_keyword { } <del> #[doc(keyword = "while")] // /// Loop while a condition is upheld. /// /// The documentation for this keyword is [not yet complete]. Pull requests welcome! /// /// [not yet complete]: https://github.com/rust-lang/rust/issues/34601 mod while_keyword { } </del> // 2018 Edition keywords #[unstable(feature = "async_await", issue = "50547")]
Change:
This code produce compiling error: () Errors: But when non aliased trait used, then no error occured. That is when we replace with
May be "F-trait_alias" label needed for this issue.
Fixed on latest nightly 2023-01-15. label: +F-trait_alias +E-needs-test

Discussion:
<ins> // check-pass #![feature(trait_alias)] struct MyStruct {} trait MyFn = Fn(&MyStruct); fn foo(_: impl MyFn) {} fn main() { foo(|_| {}); } </ins>
Change:
When a fails because there was no panic it should produce an error message to that effect. For example, the following test: when run with produces the following output: There is no indication why it failed. Which can be problematic if the test itself is created by a macro. Example:
I'm not familiar with the code, but I'd guess that you just need to change in here: to . (And add a test to make sure it works.)
Thanks.I would like to work on this.
go ahead! If you have any questions, feel free to ask them here.
Hi.I've the in and trying to write a test but is this right approach?
actually, I think you can get away with just changing this line: to update it to your , because such a test already exists for this case.
Thanks
The previous fix was closed, so this issue is open again. The contains detailed instructions.
I'd like to finish this out if is no longer working on it.

Discussion:
} } } <ins> (&ShouldPanic::Yes, Ok(())) => TrFailedMsg("test did not panic as expected".to_string()), </ins> _ if desc.allow_fail => TrAllowedFail, _ => TrFailed, }

use crate::test::{ filter_tests, parse_opts, run_test, DynTestFn, DynTestName, MetricMap, RunIgnored, <del> ShouldPanic, StaticTestName, TestDesc, TestDescAndFn, TestOpts, TrFailed, TrFailedMsg, </del> <ins> ShouldPanic, StaticTestName, TestDesc, TestDescAndFn, TestOpts, TrFailedMsg, </ins> TrIgnored, TrOk, }; use std::sync::mpsc::channel;

let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, tx, Concurrent::No); let (_, res, _, _) = rx.recv().unwrap(); <del> assert!(res == TrFailed); </del> <ins> assert!(res == TrFailedMsg("test did not panic as expected".to_string())); </ins> } fn report_time_test_template(report_time: bool) -> Option<TestExecTime> {
Change:
The "log is too long" error in reminded me about this possibility. will avoid printing installation messages for up-to-date files into the log. There are many of them in the log as you can see.
Ok, since it turned out to be a real problem blocking PRs, I'll try to implement it myself today.
Fixed in

Discussion:
fn configure_cmake(builder: &Builder<'_>, target: Interned<String>, cfg: &mut cmake::Config) { <ins> // Do not print installation messages for up-to-date files. // LLVM and LLD builds can produce a lot of those and hit CI limits on log size. cfg.define("CMAKE_INSTALL_MESSAGE", "LAZY"); </ins> if builder.config.ninja { cfg.generator("Ninja"); }
Change:
Currently, the compiler is allowed to inline naked functions if it wants to. For a normal function, inlining is fine because the compiler can remove the function prologue/epilogue and the remaining will behave as expected. However for naked functions, the developer provides the prologue/epilogue and those aren't removed by the compiler. This almost surely will result in incorrect behavior. Accordingly I think it would make sense for the compiler to not inline naked functions unless the developer explicitly opted-in.
In the other thread, alistair23 found that
Yes, functions should imply .

Discussion:
} } <del> #[derive(Clone, PartialEq, Encodable, Decodable)] </del> <ins> #[derive(Copy, Clone, PartialEq, Encodable, Decodable)] </ins> pub enum InlineAttr { None, Hint,

/// Mark LLVM function to use provided inline heuristic. #[inline] <del> fn inline(cx: &CodegenCx<'ll, '_>, val: &'ll Value, inline: InlineAttr, requires_inline: bool) { </del> <ins> fn inline(cx: &CodegenCx<'ll, '_>, val: &'ll Value, inline: InlineAttr) { </ins> use self::InlineAttr::*; match inline { Hint => Attribute::InlineHint.apply_llfn(Function, val),

Attribute::NoInline.apply_llfn(Function, val); } } <del> None if requires_inline => Attribute::InlineHint.apply_llfn(Function, val), </del> None => {} }; }

} } <del> inline(cx, llfn, codegen_fn_attrs.inline.clone(), instance.def.requires_inline(cx.tcx)); </del> <ins> let inline_attr = if codegen_fn_attrs.flags.contains(CodegenFnAttrFlags::NAKED) { InlineAttr::Never } else if codegen_fn_attrs.inline == InlineAttr::None && instance.def.requires_inline(cx.tcx) { InlineAttr::Hint } else { codegen_fn_attrs.inline }; inline(cx, llfn, inline_attr); </ins> // The `uwtable` attribute according to LLVM is: //

self.tcx.sess.opts.debugging_opts.inline_mir_threshold }; <ins> if codegen_fn_attrs.flags.contains(CodegenFnAttrFlags::NAKED) { debug!("#[naked] present - not inlining"); return false; } </ins> if codegen_fn_attrs.flags.contains(CodegenFnAttrFlags::COLD) { debug!("#[cold] present - not inlining"); return false;

<ins> // Checks that naked functions are never inlined. // compile-flags: -O -Zmir-opt-level=2 // ignore-wasm32 #![crate_type = "lib"] #![feature(asm)] #![feature(naked_functions)] #[inline(always)] #[naked] #[no_mangle] pub unsafe extern "C" fn f() { // Check that f has naked and noinline attributes. // // CHECK:       define void @f() unnamed_addr [[ATTR:#[0-9]+]] // CHECK-NEXT:  start: // CHECK-NEXT:    call void asm asm!("", options(noreturn)); } #[no_mangle] pub unsafe fn g() { // Check that call to f is not inlined. // // CHECK-LABEL: define void @g() // CHECK-NEXT:  start: // CHECK-NEXT:    call void @f() f(); } // CHECK: attributes [[ATTR]] = { naked noinline{{.*}} } </ins>
Change:
This is a tracking issue for reverting the change introduced in which disabled the toolstate check for the edition-guide. It is currently blocked on which is causing a test failure in the edition-guide. I will reinstate the check as soon as that issue is fixed. has requested the labels t-release and I-nominated.
Tags are so that we don't forget this, we should keep it nominated until it's fixed.
The check was reinstated in PR
I think you have the wrong issue? There were two things (rls and edition guide). The PR you noted just reverted the RLS change. The edition-guide was separate (and done in a different way). It's still blocked on .
, that's what happen when I read just half of the title :sweat_smile:
triage: P-high. Assigning to self. Will likewise triage . Removing nominated tag.
actually I'll leave nominated tag, since this is for a team other than T-compiler so I don't want to mess with their tags.

Discussion:
check_dispatch $1 beta nomicon src/doc/nomicon check_dispatch $1 beta reference src/doc/reference check_dispatch $1 beta rust-by-example src/doc/rust-by-example <del> # Temporarily disabled until # https://github.com/rust-lang/rust/issues/60459 is fixed. # check_dispatch $1 beta edition-guide src/doc/edition-guide </del> <ins> check_dispatch $1 beta edition-guide src/doc/edition-guide </ins> check_dispatch $1 beta rls src/tools/rls check_dispatch $1 beta rustfmt src/tools/rustfmt check_dispatch $1 beta clippy-driver src/tools/clippy
Change:
When I click on the link of a function in the rendered documentation, if the function's line number is greater than , the browser navigates to line instead of the proper location. I found the relevant code here: What's the rationale behind this limitation? Can it be lifted?
Interestingly, it looks like if this limit were removed, the for loop might be a problem. Then, maybe, someone could link to a url such as which would make the page freeze up, since the loop won't exit early if the line doesn't exist. I don't know if this would be considered harmful, however. The edit would simply be to change the line to , obviously
The freeze in that loop can be avoided with something like this:
Wo, super strange old code as it seems. Good catch!

Discussion:
var i, from, to, match = window.location.hash.match(/^#?(d+)(?:-(d+))?$/); if (match) { from = parseInt(match[1], 10); <del> to = Math.min(50000, parseInt(match[2] || match[1], 10)); from = Math.min(from, to); </del> <ins> to = from; if (typeof match[2] !== "undefined") { to = parseInt(match[2], 10); } if (to < from) { var tmp = to; to = from; from = tmp; } </ins> elem = document.getElementById(from); if (!elem) { return;

}); }); for (i = from; i <= to; ++i) { <del> addClass(document.getElementById(i), "line-highlighted"); </del> <ins> elem = document.getElementById(i); if (!elem) { break; } addClass(elem, "line-highlighted"); </ins> } } else if (ev !== null && search && !hasClass(search, "hidden") && ev.newURL) { addClass(search, "hidden");
Change:
On type mismatch with a suggestion to borrow in order to dereference a into a , we should notice unnecessary calls: and suggest their removal: From

Discussion:
} }; if self.can_coerce(ref_ty, expected) { <del> if let Ok(src) = cm.span_to_snippet(sp) { </del> <ins> let mut sugg_sp = sp; if let hir::ExprKind::MethodCall(segment, _sp, args) = &expr.node { let clone_trait = self.tcx.lang_items().clone_trait().unwrap(); if let ([arg], Some(true), "clone") = ( &args[..], self.tables.borrow().type_dependent_def_id(expr.hir_id).map(|did| { let ai = self.tcx.associated_item(did); ai.container == ty::TraitContainer(clone_trait) }), &segment.ident.as_str()[..], ) { // If this expression had a clone call when suggesting borrowing // we want to suggest removing it because it'd now be unecessary. sugg_sp = arg.span; } } if let Ok(src) = cm.span_to_snippet(sugg_sp) { </ins> let needs_parens = match expr.node { // parenthesize if needed (Issue #46756) hir::ExprKind::Cast(_, _) |

} } } return Some(match mutability { hir::Mutability::MutMutable => ( sp,

<ins> fn main() { let x = String::new(); foo(x.clone()); //~ ERROR mismatched types } fn foo(_: &str) {} </ins>

<ins> error[E0308]: mismatched types --> $DIR/issue-61106.rs:3:9 | LL |     foo(x.clone()); |         ^^^^^^^^^ |         | |         expected &str, found struct `std::string::String` |         help: consider borrowing here: `&x` | = note: expected type `&str` found type `std::string::String` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>
Change:
Today's nightly (25-05-2019) is missing rust-std for: : https://rust- : https://rust-
This was pointed out in and looks to be fixed in It seems that flew in under the radar of where the actual change to disable these targets happened. want to send a PR to revert the changes so the targets are built again?
Yes, I will do it today.

Discussion:
RUN /tmp/build-cloudabi-toolchain.sh x86_64-unknown-cloudabi COPY dist-various-2/build-fuchsia-toolchain.sh /tmp/ RUN /tmp/build-fuchsia-toolchain.sh <del> # FIXME(#61022) - reenable solaris # COPY dist-various-2/build-solaris-toolchain.sh /tmp/ # RUN /tmp/build-solaris-toolchain.sh x86_64  amd64   solaris-i386 # RUN /tmp/build-solaris-toolchain.sh sparcv9 sparcv9 solaris-sparc </del> <ins> COPY dist-various-2/build-solaris-toolchain.sh /tmp/ RUN /tmp/build-solaris-toolchain.sh x86_64  amd64   solaris-i386 RUN /tmp/build-solaris-toolchain.sh sparcv9 sparcv9 solaris-sparc </ins> COPY dist-various-2/build-x86_64-fortanix-unknown-sgx-toolchain.sh /tmp/ # We pass the commit id of the port of LLVM's libunwind to the build script. # Any update to the commit id here, should cause the container image to be re-built from this point on.

ENV TARGETS=$TARGETS,aarch64-fuchsia ENV TARGETS=$TARGETS,wasm32-unknown-unknown ENV TARGETS=$TARGETS,wasm32-wasi <del> # FIXME(#61022) - reenable solaris # ENV TARGETS=$TARGETS,sparcv9-sun-solaris # ENV TARGETS=$TARGETS,x86_64-sun-solaris </del> <ins> ENV TARGETS=$TARGETS,sparcv9-sun-solaris ENV TARGETS=$TARGETS,x86_64-sun-solaris </ins> ENV TARGETS=$TARGETS,x86_64-unknown-linux-gnux32 ENV TARGETS=$TARGETS,x86_64-unknown-cloudabi ENV TARGETS=$TARGETS,x86_64-fortanix-unknown-sgx