jiebi/CodeConvo huggingface dataset:
Change:
} gate_all!(if_let_guard, "`if let` guard is not implemented"); gate_all!(let_chains, "`let` expressions in this position are experimental"); <del> gate_all!(async_closure, "async closures are unstable"); </del> <ins> gate_all!( async_closure, "async closures are unstable", "to use an async block, remove the `||`: `async {`" ); </ins> gate_all!(generators, "yield syntax is experimental"); gate_all!(or_patterns, "or-patterns syntax is experimental"); gate_all!(raw_ref_op, "raw address of syntax is experimental");

Discussion:
This code (): prints out This is pretty unhelpful for beginners - normally this happens when they try to use in a closure, which tells them they need async: But when they do they get an error about async being unstable, which they have no idea how to solve. The fix is to remove the pipe symbols: However, this requires knowledge that async blocks desugar internally into closures, which is not at all clear from the syntax. It would be better for the compiler to suggest it:
Hey, I saw this and it looked like it might be easy so I took a shot with I haven't fixed the tests yet because I wasn't sure if this approach is reasonable or not. You end up with Re-ordering the note and help, or adding a nested span on to put the help would be considerably more involved.
Given the current is equivalent to , it may be preferable to suggest instead of .
the point of this is that the user didn't mean though. If you add then you can no longer await it: For context, the original code was something like , where the user tried to use outside of an async function.
Thanks for clarifying. What suggestion is preferable seems to depend on the expected return type. Perhaps it is preferable to have both notes?
Change:
<ins> #![feature(prelude_import)] #![no_std] #![feature(postfix_match)] #[prelude_import] use ::std::prelude::rust_2015::*; #[macro_use] extern crate std; use std::ops::Add; //@ pretty-mode:expanded //@ pp-exact:precedence.pp macro_rules! repro { ($e:expr) => { $e.match { _ => {} } }; } struct Struct {} impl Add<Struct> for usize { type Output = (); fn add(self, _: Struct) -> () { () } } pub fn main() { let a; ( { 1 } + 1).match { _ => {} }; (4 as usize).match { _ => {} }; (return).match { _ => {} }; (a = 42).match { _ => {} }; (|| {}).match { _ => {} }; (42..101).match { _ => {} }; (1 + Struct {}).match { _ => {} }; } </ins>

Discussion:
As of current nightly, produces this: which is not valid Rust syntax. The correct output would contain . tracking issue:
Change:
let size = bx.const_usize(dest.layout.size.bytes()); // Use llvm.memset.p0i8.* to initialize all zero arrays <del> if bx.cx().const_to_opt_uint(v) == Some(0) { </del> <ins> if bx.cx().const_to_opt_u128(v, false) == Some(0) { </ins> let fill = bx.cx().const_u8(0); bx.memset(start, fill, size, dest.align, MemFlags::empty()); return bx;

Discussion:
Array created using repeat expression and returned from a function actually returns . Interestingly the problem does not happen when using the list syntax to create the array. I tried this code: I expected to see this happen: the second should pass Instead, this happened: the second fails screaming that Problem exists on stable, beta and nightly : <details<summaryBacktrace</summary<p</p</details
I wonder if is at fault here. It does look to be inappropriately turning the repeat into a memset (when looking at the llvm IR)
Compiling this: with Yields: Which does not seem right. We shouldn't be emitting a memset to 0 there.
This program hits an LLVM assertion if compiled with an LLVM that has assertions enabled:
This appeared in . Until the sample would code emit a compile error (), maybe that would shadow the error? A bisection between those two stable releases points to a group of old PR but I can't really pinpoint one :/
fails even under 1.26. And before that, i128 didn't even exist. So this has been a problem since 128 bit ints were introduced, as far as I can see.
Thank you for the analysis and the fix :)
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
} i += UNROLL * Block::LANES; } <del> while i + second_probe_offset + Block::LANES < haystack.len() && !result { </del> <ins> while i + last_byte_offset + Block::LANES < haystack.len() && !result { </ins> let mask = test_chunk(i); if mask != 0 { result |= check_mask(i, mask, result);

Discussion:
PR a x8664 SIMD-based implementation of to optimize searching into strings when the needle is at most 32 bytes long. Unfortunately, that implementation doesn't seem to be sound. When compiling the standard library with debug assertions on, running UI tests excluding results in compiletest itself panicking before executing any test due to a in libcore: To reproduce the issue, use the following configuration file: run: cc
Tentatively opened a revert PR in
Ugh. I ran it under miri with quite a combinatorial test that I thought should cover all the edge-cases. It's not immediately obvious what's wrong, so it's fine to land the revert for now.
Last I checked (and a lot has happened since then so I could be working on outdated info -- might be able to confirm), miri can't catch failure in many cases I believe, since it's "just" library UB.
the memory will be accessed after the get_unchecked so it should still be an invalid memory access when it's out of bounds. Unless I'm just doing some shortening slicing and then extending it again so that it's valid within the same allocation but not correct slicing.
What says is correct. The error here is in a situation like Miri (without Stacked Borrows) will not complain about that since the index is in-bounds of the allocation. But the debug assertion will complain since you are causing library UB by going out-of-bounds of the slice. I don't quite understand your last comment,
It seems like the test is just insufficient. Even with debug asserts and overflow checks enabled it doesn't catch it. I'll have to reproduce it first to figure out what's missing.
Ooh, I was getting absolutely unexplainable compiler errors when building stage 1 libstd with a stage 0 rustc which was built with however, could this be the cause for this? :sweat_smile:
Possible, but it would also do incorrect things on x86-64 baseline
has a proper fix
Change:
let mut err = tcx.sess.struct_span_err(span, msg); err.span_note(span_late, note); err.emit(); <del> return (true, None); </del> <ins> reported_late_bound_region_err = Some(true); </ins> } else { let mut multispan = MultiSpan::from_span(span); multispan.push_span_label(span_late, note.to_string()); tcx.lint_hir(lint::builtin::LATE_BOUND_LIFETIME_ARGUMENTS, args.args[0].id(), multispan, msg); <del> return (false, None); </del> <ins> reported_late_bound_region_err = Some(false); </ins> } } }

Discussion:
Compiler crashes with Also, I wonder what is the right way (or is there any way) to write a with expected behavior. Thanks.
Reduced:
Regression first occurred in 1.30 according to godbolt.
One can leave out the trait in your MCVE, still crashes. Bug was introduced somewhere between ... Sadly that's a very big range, but there are no nightlys available in between and also no bors artifacts because they are older than 167
triage: P-high
Smaller example from :
I was trying to remove as many type parameters as possible, and ended up with this: Removing after still cuases an ICE. Adding a after stops causing the ICE. Removing the also stops causing the ICE. Not sure if it's any more or less helpful, but just putting this here.
claim Looks like that didn't work, either way, I'm taking a look into this issue.
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please let know if you're having trouble with this bot.
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please let know if you're having trouble with this bot.
Change:
impl Foo { // @has async_fn/struct.Foo.html // @has - '//*[@class="method"]' 'pub async fn complicated_lifetimes( &self, context: &impl Bar ) -> impl Iterator<Item = &usize>' <del> pub async fn complicated_lifetimes(&self, context: &impl Bar) -> impl Iterator<Item = &usize> {} </del> <ins> pub async fn complicated_lifetimes(&self, context: &impl Bar) -> impl Iterator<Item = &usize> { [0].iter() } </ins> // taken from `tokio` as an example of a method that was particularly bad before // @has - '//*[@class="method"]' "pub async fn readable<T>(&self) -> Result<AsyncFdReadyGuard<'_, T>, ()>" <del> pub async fn readable<T>(&self) -> Result<AsyncFdReadyGuard<'_, T>, ()> {} </del> <ins> pub async fn readable<T>(&self) -> Result<AsyncFdReadyGuard<'_, T>, ()> { Err(()) } </ins> // @has - '//*[@class="method"]' "pub async fn mut_self(&mut self)" pub async fn mut_self(&mut self) {} }

Discussion:
<!-- 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. --I tried this code: I expected the documentation for the type alias to show the method and the implementation of . Instead, the type alias does not show the method . It does however show the implementation of . ! By publicly exposing through , the documentation of on the alias is documented as I expected, but then is publicly reachable, which in my case is unwanted due to being an internal implementation detail. This also works when making the statement , which gets the docs to look like I expected them to. ! <!-- 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. --: Thanks for helping me figure out why what I was expecting wasn't happening though it looked like it should.
I think it's ok to document an impl on a reexported if the reexported item is not doc hidden. I'll send a fix in the next weeks.
Change:
fn gather_init(&mut self, place: &Place<'tcx>, kind: InitKind) { debug!("gather_init({:?}, {:?})", self.loc, place); <ins> let place = match place { // Check if we are assigning into a field of a union, if so, lookup the place // of the union so it is marked as initialized again. Place::Projection(box Projection { base, elem: ProjectionElem::Field(_, _), }) if match base.ty(self.builder.mir, self.builder.tcx).to_ty(self.builder.tcx).sty { ty::TyKind::Adt(def, _) if def.is_union() => true, _ => false, } => base, // Otherwise, lookup the place. _ => place, }; </ins> if let LookupResult::Exact(path) = self.builder.data.rev_lookup.find(place) { let init = self.builder.data.inits.push(Init { location: InitLocation::Statement(self.loc),

Discussion:
review comments:
triage: P-medium. (We should look into this, but even if its wrong, I'm not going to push to a backport its hypothetical bug fix.)

review comments: For the record, here's the relevant part of the test in question ():
This should be NLL-complete, not NLL-sound, right?
Yeah, it should. My bad.
triage: P-high, not not Release milestone. This issue is bad enough for fix quickly, but there's no reason to beta-backport (as I explained on the PR itself here )
Change:
"fast" => Self::Fast, "balanced" => Self::Balanced, "best" => Self::Best, <ins> "no-op" => Self::NoOp, </ins> other => anyhow::bail!("invalid compression profile: {other}"), }) }

Discussion:
Right now when doing a local , we first compress the artifacts with max compression ratio, just to immediately unpack them again when installing them to disk. Making the compression level less aggressive or skipping it altogether can probably save 5-10 minutes on an x.py install. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc You probably want to use the gzip'd artifacts which are less intensely compressed.
tbh it seems strange that we're compressing these at all - why not put them into an uncompressed .tar archive when using ?
or even better, copy them directly from the build directory to the install directory without going through a .tar archive first.
claim
Skipping the compressions and archiving in favor of directly copying the artifacts seems like a reasonable solution for . But it requires significant changes to how we currently handle . I'm planning to do a comprehensive review on bootstrapping from all angles(including T-bootstrap issues) and make a roadmap for future development. To avoid conflicts(e.g, if we have improvement ideas on dist/install modules, implementing this might increase the technical debt which will require more effort from the team), I will postpone this task for now and re-prioritize it once we have organized the plans.
Change:
} Err(()) => { // error types are considered "builtin" <del> if !lhs_ty.references_error() { </del> <ins> if !lhs_ty.references_error() && !rhs_ty.references_error() { </ins> let source_map = self.tcx.sess.source_map(); match is_assign { IsAssign::Yes => {

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
Possibly related to , though the panic happens at a different place.
Report from cargo-bisect-rustc: searched nightlies: from nightly-2020-03-01 to nightly-2020-05-02 regressed nightly: nightly-2020-03-28 searched commits: from to regressed commit:
It is caused by a different underlying cause to .
The underlying issue is a bad interaction in the following code with the call to (called by ) which expects there not to be any unresolved lifetimes. This happens because the code is actually parsed and evaluated as ( and ).
Change:
// Allows the use of rustc_* attributes; RFC 572 ("rustc_attrs", "1.0.0", Active), <del> // Allows the use of `static_assert` ("static_assert", "1.0.0", Active), </del> // Allows the use of #[allow_internal_unstable]. This is an // attribute on macro_rules! and can't use the attribute handling // below (it has to be checked before expansion possibly makes

Discussion:
In I add a basic form of static assertions (as suggested by graydon in ), but it's not nice to use. The biggest problem with it is you need a static variable with a name, that goes through trans and ends up in the object file. suggested , which I think is a nice API but would need some invasive changed to the compiler (I think, uncertain).
Eh. I'm actually kinda ok with the way it turned out. If it's non-pub it shouldn't wind up in the object file as a public symbol (if it does, we're doing-stuff-wrong in codegen) and we can potentially just mark it as a throw-me-away sort of value harder if LLVM requires further convincing. Considering that static asserts in C are typically done by composing a negative-sized array and allowing the compiler to yell about that, I consider this implementation already pretty luxurious :)
How about having a thats just a wrapper around a automatically generated private static item with the #[staticassert] attribute?
if i understand you correctly, that's what i've suggested in but it seems not straightfoward to implement
Hm, but the current attribute-static item system works, no? Wouldn't a just be trivial sugar for that? Or is the 'generate a name'-part the hard one?
I don't know how to implement a macro to do this, so feel free to take a shot at it :smiley_cat:
Visiting for triage. Doesn't seem like a release blocker.
With hygiene, it should be much easier.
Triage: hygiene doesn't particularly help in this case, it's currently only for names created/bound with . A sketch: Uncommenting the gives a duplicate module error (as one might expect). If there was a macro (for creating a completely new ident) this might help, but is currently not valid as macros aren't allowed in place of s.
Macros can now expand to items with attributes:
triage bump. Nothing to add
It always needs to be crippled enough that it can't cause a compilation failure during expansion of generics. I think we should just remove the current attribute. It doesn't appear to have any real world use cases.
triage: nothing to add. We don't currently use anywhere in the codebase, which leads me to wonder if isn't right here.

An implementation in standard Rust based on the array size trick: In short, an invocation expands to It is variadic because there will be a name collision between two invocations... Yes the usability is horrible.
I wish Rust would support more static features(I use them extensively in C++ in order to enforce correct API usage)... I need to assert the simplest case: making sure the user doesn't pass an empty array/slice - and I cannot do it with the language... It's awful that I have to "assert" at run-time for such a simple case...
Change:
}, ); } else { <ins> // #117284, when `pat_span` and `ident_span` have different contexts // we can't provide a good suggestion, instead we pointed out the spans from macro let from_macro = non_shorthands .iter() .find(|(_, pat_span, ident_span)| { pat_span.ctxt() != ident_span.ctxt() && pat_span.from_expansion() }) .map(|(_, pat_span, _)| *pat_span); </ins> let non_shorthands = non_shorthands .into_iter() .map(|(_, _, ident_span)| ident_span) .collect::<Vec<_>>(); let suggestions = self.string_interp_suggestions(&name, opt_body); <ins> let sugg = if let Some(span) = from_macro { errors::UnusedVariableSugg::NoSugg { span, name: name.clone() } } else { errors::UnusedVariableSugg::TryPrefixSugg { spans: non_shorthands, name: name.clone(), } }; </ins> self.ir.tcx.emit_spanned_lint( lint::builtin::UNUSED_VARIABLES, first_hir_id,

Discussion:
Consider the following file in a cargo package: Cargo will warn that is not used. Upon running , cargo will change the second parameter from to , making the compilation fail. Even worse, if contained a field then would change the variable without producing any warning. a new cargo binary project with the above snippet in (presumably with ) No response No response
just applies any  suggestion produced by . In this case, the suggestion from is to replace with . I went ahead and ran to see if it could help me understand what is going on better: ` (I cleaned up the expanded code slightly, but it is the same) Looking at the expanded code, it makes me think that is seeing in as the source of the problem since it expands to and is unused in this case. The normal suggestion is to add an underscore to so it would not be "unused". So suggests to change the being passed to the macro call as it does not understand that the warning is really coming from within the macro, not the call itself. It also could be suggesting this as is not valid rust (macro?) syntax. If you change your example slightly, correctly suggests the problem comes from within the macro call. To me, this seems like a problem with , but I do not know enough about the compiler internals to be 100% certain.
Transferred to rust-lang/rust, since the suggestions are generated by the compiler.
Yes, this issue comes from rustc. The lint is emitted from here Maybe we only point out that there is an unused variable coming from , but without the suggestion? I'm not sure what is a proper lint for this test case. any thoughts on it?
The quick and straightforward way to fix this would be to only emit the suggestion in this lint if the span has the root context, but then a subset of valid suggestions wouldn't be emitted. I had an older PR that I'm having trouble finding that would automatically do that for every diagnostic, but IIRC it had some negative perf impact when not implementing it very simplistic. In this we can probably instead check that all of the spans involved have the same . If they don't, don't suggest changes.
Change:
<ins> // Regression test for issue 101585. // run-pass fn main() { fn min_array_ok() -> [i128; 1] { [i128::MIN] } assert_eq!(min_array_ok(), [-170141183460469231731687303715884105728i128]); fn min_array_nok() -> [i128; 1] { [i128::MIN; 1] } assert_eq!(min_array_nok(), [-170141183460469231731687303715884105728i128]); } </ins>

Discussion:
Array created using repeat expression and returned from a function actually returns . Interestingly the problem does not happen when using the list syntax to create the array. I tried this code: I expected to see this happen: the second should pass Instead, this happened: the second fails screaming that Problem exists on stable, beta and nightly : <details<summaryBacktrace</summary<p</p</details
I wonder if is at fault here. It does look to be inappropriately turning the repeat into a memset (when looking at the llvm IR)
Compiling this: with Yields: Which does not seem right. We shouldn't be emitting a memset to 0 there.
This program hits an LLVM assertion if compiled with an LLVM that has assertions enabled:
This appeared in . Until the sample would code emit a compile error (), maybe that would shadow the error? A bisection between those two stable releases points to a group of old PR but I can't really pinpoint one :/
fails even under 1.26. And before that, i128 didn't even exist. So this has been a problem since 128 bit ints were introduced, as far as I can see.
Thank you for the analysis and the fix :)
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
hir::ExprKind::Call(ref callee, ref args) => { // callee(args) <del> self.walk_callee(expr, callee); </del> <ins> self.consume_expr(callee); </ins> self.consume_exprs(args); }

Discussion:
Problematic code: Minimal reproduction: This ICE happens on both nightly and stable. rustc 1.42.0-nightly ( 2020-01-06) binary: rustc commit-hash: commit-date: 2020-01-06 host: x86_64-unknown-linux-gnu release: 1.42.0-nightly LLVM version: 9.0 Backtrace:
I'm not sure how to reproduce the ICE given the two snippets at the top. Can you clarify the minimal reproduction: how do I reproduce it in the playground?
Simplified:
The failure occurs here: I guess we can add to first arm (), is it safe?
triage: P-high. Removing I-nominated label.
Change:
<ins> error[E0308]: mismatched types --> $DIR/check-args-on-fn-err-2.rs:2:19 | LL |     a((), 1i32 == 2u32); |           ----    ^^^^ expected `i32`, found `u32` |           | |           expected because this is `i32` | help: change the type of the numeric literal from `u32` to `i32` | LL |     a((), 1i32 == 2i32); |                    ~~~ error[E0425]: cannot find function `a` in this scope --> $DIR/check-args-on-fn-err-2.rs:2:5 | LL |     a((), 1i32 == 2u32); |     ^ not found in this scope error: aborting due to 2 previous errors Some errors have detailed explanations: E0308, E0425. For more information about an error, try `rustc --explain E0308`. </ins>

Discussion:
<!-- 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
Regression in /
Perhaps ? :thinking: cc
list of files that reproduce the crash ( is eough) `
I think we should change to a

Found with a From : From : Deep recursion involving ? Regression in nightly-2022-10-07, apparently in rollup . I suspect (