jiebi/CodeConvo huggingface dataset:
Change:
self.tcx.sess.parse_sess.expr_parentheses_needed(err, *sp, None); } } <ins> fn is_loop(&self, id: hir::HirId) -> bool { let node = self.tcx.hir().get(id); matches!(node, Node::Expr(Expr { kind: ExprKind::Loop(..), .. })) } fn is_local_statement(&self, id: hir::HirId) -> bool { let node = self.tcx.hir().get(id); matches!(node, Node::Stmt(Stmt { kind: StmtKind::Local(..), .. })) } </ins> }

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --It may not be immediately clear to a user why implicit-return/break style works for expressions, but not for . Adding a hint to explicitly break with would be helpful. <!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-suggestion-diagnostics
claim
Change:
fn mplace_to_const<'tcx>( ecx: &CompileTimeEvalContext<'_, '_, 'tcx>, mplace: MPlaceTy<'tcx>, <del> ) -> EvalResult<'tcx, ty::Const<'tcx>> { </del> <ins> ) -> ty::Const<'tcx> { </ins> let MemPlace { ptr, align, meta } = *mplace; // extract alloc-offset pair assert!(meta.is_none()); <del> let ptr = ptr.to_ptr()?; let alloc = ecx.memory.get(ptr.alloc_id)?; </del> <ins> let ptr = ptr.to_ptr().unwrap(); let alloc = ecx.memory.get(ptr.alloc_id).unwrap(); </ins> assert!(alloc.align >= align); assert!(alloc.bytes.len() as u64 - ptr.offset.bytes() >= mplace.layout.size.bytes()); let mut alloc = alloc.clone();

Discussion:
It looks like this was broken in the release of 1.32.0 (and is still broken, even on nightly) (checked on ). The following example program: Fails to compile: Interestingly, making the fixes it. My Rust version: I know , but I don't think this qualifies as a field access. And yes, I'm aware of . cc
Interesting. Looks like a validation issue? Cc
Change:
} /// Compare `a` and `b` for nonequality (Using partial equality, `Eq`) <del> pub fn ne<A: Eq, T: Iterator<A>>(mut a: T, mut b: T) -> bool { </del> <ins> pub fn ne<A: Eq, T: Iterator<A>, S: Iterator<A>>(mut a: T, mut b: S) -> bool { </ins> loop { match (a.next(), b.next()) { (None, None) => return false,

Discussion:
They're currently very restricted as they only work with a single iterator type for both arguments, so, e.g. doesn't work. It should be easy to just add another parameter for the second argument.
Change:
w.write_str("</div></div>"); toggle_close(w); } <del> render_stability_since(w, variant, it, cx.tcx()); </del> } } let def_id = it.def_id.expect_real();

Discussion:
Go to: It was but the rustdoc generates like: ! The problem is that the previous variant's version is placed at the same height. I think it's ideal to place the version of the item itself at the same height, like functions.
I am new here but it looks like something I could do. Can you point me in the right direction?
Sorry but I'm not familiar with rustdoc, could you help them?
I don't have time, sorry. may have suggestions.
I can help if needed. But first: how would you want it to look like?
As mentioned first, the version at the same height should be the variant's IMO.
Ah ok sorry, so it's a layout bug. I thought you wanted to improve the display (which would be welcome too!). The problematic line is . It should be set before the docblock (in the variant header if possible).
I will gladly take a look at it, so I can familiarize with the codebase.
Sure, go ahead! Do test locally: Like that you can then go to the page and check if the bug is fixed. ;)
Change:
<ins> error[E0308]: mismatched types --> $DIR/expr-as-stmt-2.rs:3:26 | LL |     if let Some(x) = a { true } else { false } |     ---------------------^^^^------------------ help: consider using a semicolon here |     |                    | |     |                    expected `()`, found `bool` |     expected this to be `()` error[E0308]: mismatched types --> $DIR/expr-as-stmt-2.rs:3:40 | LL |     if let Some(x) = a { true } else { false } |     -----------------------------------^^^^^--- help: consider using a semicolon here |     |                                  | |     |                                  expected `()`, found `bool` |     expected this to be `()` error[E0308]: mismatched types --> $DIR/expr-as-stmt-2.rs:6:5 | LL |   fn foo(a: Option<u32>, b: Option<u32>) -> bool { |                                             ---- expected `bool` because of return type LL |       if let Some(x) = a { true } else { false } |       ------------------------------------------ help: parentheses are required to parse this as an expression: `(if let Some(x) = a { true } else { false })` ... LL | /     && LL | |     if let Some(y) = a { true } else { false } | |______________________________________________^ expected `bool`, found `&&bool` error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .
Change:
<ins> error[E0658]: attributes on expressions are experimental --> $DIR/issue-87378.rs:14:13 | LL |     let c = #[rustc_capture_analysis] |             ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #15701 <https://github.com/rust-lang/rust/issues/15701> for more information = help: add `#![feature(stmt_expr_attributes)]` to the crate attributes to enable error: First Pass analysis includes: --> $DIR/issue-87378.rs:17:5 | LL | /     || { LL | | LL | | LL | |        unsafe { u.value } LL | | LL | | LL | |     }; | |_____^ | note: Capturing u[(0, 0)] -> ImmBorrow --> $DIR/issue-87378.rs:20:17 | LL |        unsafe { u.value } |                 ^^^^^^^ error: Min Capture analysis includes: --> $DIR/issue-87378.rs:17:5 | LL | /     || { LL | | LL | | LL | |        unsafe { u.value } LL | | LL | | LL | |     }; | |_____^ | note: Min Capture u[] -> ImmBorrow --> $DIR/issue-87378.rs:20:17 | LL |        unsafe { u.value } |                 ^^^^^^^ error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0658`. </ins>

Discussion:
<!-- 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. --I tried this code: I expected to see this happen: no error Instead, this happened: rustc 1.55.0-nightly 2018 edition rustc 1.55.0-nightly 2021 edition <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Change:
} } } else { <del> result </del> <ins> false </ins> } }

Discussion:
While trying to upgrade rustc to the latest nightly, I stumbled across a Rust compiler panic. Here's a repo that contains a minimum-reproducible test case (well, reasonably compact): From my brief investigation, it appears that adding the combinator causes recent rustc nightly's to panic. I've bisected the recent nightly versions; is the first that starts panicking. Running with builds successfully. To reproduce the bug, just run . Running doesn't panic, though, since it seems to be codegen related. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
searched nightlies: from nightly-2023-02-01 to nightly-2023-03-04 regressed nightly: nightly-2023-02-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed in , cc
I have (a couple of) fixes for this PR, but I really need this minimized :/
WG-prioritization assigning priority (). label -I-prioritize +P-critical +E-needs-mcve
I'll work on minimizing it in the meantime
I've started some work I but it's extremely miserable because of hypers internal highly entangled generic mess
I tried some more and I'm convinced that this ICE here cannot be minimized in a reasonable amount of time. The ICE is very brittle and disappears with seemingly random changes and the codebase is huge and highly generic with many bounds. I'll leave the label here, but I don't recommend anyone working on this (unless you hate fun and want to waste your time).
We don't have a test, but given that we won't get a test from this report, keeping it open doesn't seem useful.
Change:
[patch."https://github.com/rust-lang/cargo"] cargo = { path = "src/tools/cargo" } <del> [patch.crates-io] </del> <ins> [patch."https://github.com/rust-lang/rustfmt"] </ins> # Similar to Cargo above we want the RLS to use a vendored version of `rustfmt` # that we're shipping as well (to ensure that the rustfmt in RLS and the # `rustfmt` executable are the same exact version). rustfmt-nightly = { path = "src/tools/rustfmt" } <ins> [patch.crates-io] </ins> # See comments in `src/tools/rustc-workspace-hack/README.md` for what's going on # here rustc-workspace-hack = { path = 'src/tools/rustc-workspace-hack' }

Discussion:
recently started saying something like this several times on almost every invocation:
Probably caused by Cc
is there any way for us to make that warning an error? Ideally this wouldn't pass CI...
It was done to fix CI in RLS repo and has no effect on Rust. Why should it be a hard error?
It's worth noting that functionally it doesn't change anything - the section in the RLS manifest should always point to the version checked in the submodule. I'll update the RLS. I understood that this use case might be useful to support in some way - my intent was to patch the dependency from the crate PoV to emphasize that pulling Rustfmt from git is a temporary measure and a regular dependency should be used eventually there, rather than trying to globally patch the rustfmt (which is already done by the final Rust virtual manifest).
It should be a hard error or silenceable -- we shouldn't have warnings on master.
AFAIK it's hardcoded. I've suggested introduction of lints in , to build upon . The largest implementation complexity I see with the cargo feature is in fact non-cargo lints because rustc prints the source of the lint level, and if cargo sets arguments, rustc would only see those and thus complain about arguments to the users. Maybe initially the feature could only allow lints, with rustc lints coming once it's figured out how to get rustc print the source of the lint level. It would be great to have this feature for as well so that one doesn't need to support in random compilation units.
Yeah it's hardcoded to warn:
any news on updating RLS? I can take care of removing the patch and bumping the submodule to a separate branch on rust-lang/rls if you'd like (the patch shouldn't be needed for rust-lang/rust, but I guess is needed upstream).
You don't need a separate branch. You only have to create a different file and then change ci to do sth like .
I guess that would work too, but personally that seems somewhat more complicated and more likely to lead to problems of only updating one of them.
Change:
let origin = Point { x: 0, y: 0 }; match origin { <del> Point { x: x, y: y } => println!("({},{})", x, y), </del> <ins> Point { x, y } => println!("({},{})", x, y), </ins> } ``` [struct]: structs.html <ins> We can use `:` to give a value a different name. ```rust struct Point { x: i32, y: i32, } let origin = Point { x: 0, y: 0 }; match origin { Point { x: x1, y: y1 } => println!("({},{})", x1, y1), } ``` </ins> If we only care about some of the values, we don’t have to give them all names: ```rust

Discussion:
The page doesn't explain that it's possible to match compound data in this way: Currently only this form is covered: The latter form results in compiler warnings (). I'm not sure whether it should be avoided for that reason.
fixed this
Change:
impl IntoBytes for Vec<Ascii> { fn into_bytes(self) -> Vec<u8> { <del> unsafe { mem::transmute(self) } </del> <ins> unsafe { let v = Vec::from_raw_parts(self.len(), self.capacity(), mem::transmute(self.as_ptr())); // We forget `self` to avoid freeing it at the end of the scope // Otherwise, the returned `Vec` would point to freed memory mem::forget(self); v } </ins> } }

Discussion:
There are 3 cases of this undefined behaviour in : There is no guarantee that and have the same layout under the new rules. This needs to manually copy over the fields one by one which would compile to the same code as long as a feature like struct randomization wasn't enabled. Since vectors expose , it could be switched to make use of that. However, this is a pervasive issue with in the standard libraries.
I would like to fix this one. However, I don't understand why you would need to use . If we need to copy everything, why don't we do it directly to a ?
the fields of Vec are private, so you can't just use
Change:
let largest_niche = Niche::from_scalar(dl, offset, niche_scalar.clone()); <del> return Ok(tcx.intern_layout(Layout { </del> <ins> niche_filling_layout = Some(Layout { </ins> variants: Variants::Multiple { tag: niche_scalar, tag_encoding: TagEncoding::Niche {

Discussion:
This prints the values in comments: Note that contains strictly more opportunities for optimization, but it's optimized worse. That's because it uses a "niche-filling" layout (using in the field of for ), but the "tag" layout wouldn't be any larger, because it has enough space in bytes to fit the (byte-sized) tag, and . uses the tagged layout since it has no other choice, and ends up with free values in the byte-sized tag, but "jumps the gun" on using a pre-existing niche.
Change:
} pub struct CStore { <del> metas: RefCell<FxHashMap<CrateNum, Rc<CrateMetadata>>>, </del> <ins> metas: RefCell<IndexVec<CrateNum, Option<Rc<CrateMetadata>>>>, </ins> /// Map from NodeId's of local extern crate statements to crate numbers extern_mod_crate_map: RefCell<NodeMap<CrateNum>>, pub metadata_loader: Box<MetadataLoader>,

Discussion:
While investigating the root cause(s) of and discussing (in the IRC chat room) the use of a hashmap mapping crate-numbers to crate-metadata, "why is that not an ?" One word: Legacy. Big time: the field has been a hashmap ever since was introduced, 6.5 years ago in () It should be a useful (and hopefully simple?) exercise to replace the hashmap that is with an .
So is it just replacing the type with? If sow what is the equivalent for insert?
Should be as simple as that
The only way I am seeing to add to an IndexVec is to push to the end at index == len But the hashmap uses the ability to insert at an arbitrary index: So I don't quite see how to make the conversion.
from my quick skimming, is only called from one place: , here: The in that context is always the steadily incremented . So I would suggest removing entirely, and replacing it with a some method that indeed pushes to the end at index == len, as you state, since it seems that will have the same end effect.
BTW if one really did need to support overwriting for arbitrary s, that is easy too, as long as they already exist in the , since supports the method that underlying : ; but I don't think we will need that in this case.
Maybe you want an ?
That's not 100% correct. Crate numbers are assigned in preorder - if a crate (say ) has a dependency (say ), then will get the earlier crate number, then will be loaded, and only then will the metadata for be assigned. But it's ok to use an to handle this.
You are right. I overlooked the fact that we 1. first increment the crate num (reserving the number, like for in your example), then 2. call (which may recursively re-enter ), before finally 3. calling at the end.
Ok, what is the best incantation to test this locally? In the meantime I will open a pr.
Change:
let lines = origtext.lines().filter_map(|l| map_line(l).for_html()); let text = lines.collect::<Vec<Cow<'_, str>>>().join("n"); <ins> let parse_result = match kind { CodeBlockKind::Fenced(ref lang) => { let parse_result = LangString::parse_without_check(&lang, self.check_error_codes, false); if !parse_result.rust { return Some(Event::Html( format!( "<div class="example-wrap"> <pre{}>{}</pre> </div>", format!(" class="language-{}"", lang), Escape(&text), ) .into(), )); } parse_result } CodeBlockKind::Indented => Default::default(), }; compile_fail = parse_result.compile_fail; should_panic = parse_result.should_panic; ignore = parse_result.ignore; edition = parse_result.edition; let explicit_edition = edition.is_some(); let edition = edition.unwrap_or(self.edition); </ins> let playground_button = self.playground.as_ref().and_then(|playground| { let krate = &playground.crate_name; let url = &playground.url;

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. --Repro: text /// aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa /// rust /// bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb /// Rustdoc output: ! It seems that only code block with language are affected. cc
A quick test showed that the bug was introduced in (i.e.: works fine)
label +regression-from-stable-to-nightly
Thanks, I'll fix it in the next hours.
In case you want to take a look to the fix, it's .
Change:
TokenTree::Token(sp, token::Ident(kind))]; v[index].clone() } <ins> (&TokenTree::Token(_, token::Interpolated(Nonterminal::NtTT(ref tt))), _) => { tt.clone().unwrap() } </ins> (&TokenTree::Sequence(_, ref seq), _) => seq.tts[index].clone(), _ => panic!("Cannot expand a token tree"), }

Discussion:
See discussion on .
The ability to convert token-trees AST is also needed to
Do we need that ability here? It's only about interpolated matches.
Fixed in .
Change:
TokenTree::Token(sp, token::Ident(kind))]; v[index].clone() } <ins> (&TokenTree::Token(_, token::Interpolated(Nonterminal::NtTT(ref tt))), _) => { tt.clone().unwrap() } </ins> (&TokenTree::Sequence(_, ref seq), _) => seq.tts[index].clone(), _ => panic!("Cannot expand a token tree"), }

Discussion:
I haven't finished investigating this, so I'm making an issue just so I don't forget it:
Actually, I'm really not sure this should work. I'm nominating this for well-defined.
Actually... this definitely shouldn't work in our current system. The basic issue is that a lonely sigil is not a complete "thing". The "tt" macro option is only intended for macros that expand into macro invocations. There are a number of ways around this; at the most basic level, you can insist that the user provide the sigil and the thing it's attached to. This works, but it may be unsatisfying if you want the sigil to be attached to names that are introduced by the macro. In this case, you have a couple of choices. use an unhygienic macro (and tell everyone what name you want to attach to the sigil, ugh) explicitly have three different versions of the macro, one for each sigil (bleah) clean up the second option by nesting one macro definition inside another one make sigils expand into macro invocations. Anyhow, I would say that as of right now, at least, this is not a bug. I'm going to leave this as nominated mostly because this came up in Vancouver as something that Graydon and I both expected to work.
Visiting for triage: still doesn't work, nothing more to add.
accepted for well-defined milestone
You can work around this by using a dummy macro so that you can pass the directly to it, e.g. for the example in the issue:
reading this workaround makes me feel like our macro system is really broken :(.
/cc
The modernized example gives me which looks like .
notes that another hacky work-around is a nested macro invocation, which avoids needing to define/export dummy macros (although one will want to be careful about giving that internal macro a fairly unique name to avoid trampling on any other macros in scope, unfortunately :disappointed: ).
Updated example: error:
Triage: This is an ancient P-low bug but per it actually comes up in the wild a lot - macro writers have to know how to do this workaround. Can this be escalated? Is there a solution somebody could mentor?
Discussed at lang meeting, we believe this should remain p-low since we don't know a very easy fix.

It should be fixed by converting macro_rules to expand to pure tokens then parsing, rather than mixing the two steps (which we hop would be back-compat). cc
Fixed in .
Change:
let necessary = struct_lit_needs_parens && parser::contains_exterior_struct_lit(&inner); if !necessary { <del> let pattern = pprust::expr_to_string(value); Self::remove_outer_parens(cx, value.span, &pattern, msg); </del> <ins> let expr_text = if let Ok(snippet) = cx.sess().source_map() .span_to_snippet(value.span) { snippet } else { pprust::expr_to_string(value) }; Self::remove_outer_parens(cx, value.span, &expr_text, msg); </ins> } } }

Discussion:
This code snippet () results in the following lint output: The should contain the literal string , not the expanded macro that it repreesnts.
Ah, I think this is because we should be using (to get the code the user actually wrote) (to render the AST); I could PR this tonight.