jiebi/CodeConvo huggingface dataset:
Change:
/// own, or if it does not enable any significant optimizations. /// /// This intrinsic does not have a stable counterpart. <del> #[rustc_const_unstable(feature = "const_assume", issue = "76972")] </del> <ins> #[rustc_const_stable(feature = "const_assume", since = "CURRENT_RUSTC_VERSION")] </ins> #[rustc_nounwind] pub fn assume(b: bool);

Discussion:
The feature gate for the issue is . It makes usable in const contexts. Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implemented in [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --<!-- Include a list of all the PRs that were involved in implementing the feature. --
Do you want to stabilize the feature? I was asked to use in const context here:
WG-const-eval has confirmed that this is fine: Feel free to send in a PR flipping the stability attribute. It's an unstable intrinsic so we aren't really committing to anything.
Change:
<ins> // build-pass #![feature(const_generics)] #![allow(incomplete_features)] pub fn works() { let array/*: [_; _]*/ = default_array(); let _: [_; 4] = array; Foo::foo(&array); } pub fn didnt_work() { let array/*: [_; _]*/ = default_array(); Foo::foo(&array); let _: [_; 4] = array; } trait Foo { fn foo(&self) {} } impl Foo for [i32; 4] {} impl Foo for [i64; 8] {} // Only needed because `[_; _]` is not valid type syntax. fn default_array<T, const N: usize>() -> [T; N] where [T; N]: Default, { Default::default() } fn main() { works(); didnt_work(); } </ins>

Discussion:
I've come up with this example (): My understanding is that the error is caused by the obligation being on just (which means it's not retried when is unified with ), whereas it should be stalled on both and so that it's retried when either changes. Right now is limited to type inference variables, so its representation will need to change, and will need to expose constants too. I believe ran into this as well, but for WF obligations, not trait ones. I'm self-assigning this because I'm working on the fix (as part of a larger effort). cc
Note to self: the PR fixing this should also test this example (): The reason for this is that this second example has the type and const inference variables in different generic args of , meaning fixing it also requires changing this to :
I've definitely noticed problems with inference involving consts before, but wasn't able to pin down where the issue was stemming from. It would be great if this could be addressed once and for all.
Change:
Ok(eval_result) => eval_result.may_apply(), Err(traits::OverflowError) => true, // overflow doesn't mean yes *or* no }; <ins> debug!("get_blanket_impls: found applicable impl: {} for trait_ref={:?}, ty={:?}", may_apply, trait_ref, ty); </ins> if !may_apply { return }

Discussion:
When using the nightly with the bugfix for the problems with , this error happens when trying to document the crate: note: rustc 1.31.0-nightly ( 2018-10-01) running on x86_64-apple-darwin
cc: FYI
it seemed to document fine for me on the most recent nightly build
This is fixed as of
Closing then! Thanks! :D
Will this need backporting at all?
Change:
<ins> error[E0308]: mismatched types --> $DIR/diagnostic-method-lookup-returns-sig-with-fewer-args.rs:4:16 | LL |     target.get(10.0); // (used to crash here) |            --- ^^^^ expected `i32`, found floating-point number |            | |            arguments to this method are incorrect | note: method defined here --> $DIR/diagnostic-method-lookup-returns-sig-with-fewer-args.rs:22:12 | LL |     pub fn get(&self, data: i32) { |            ^^^        --------- error: aborting due to 1 previous error For more information about this 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. --Hello, I am sorry, but I wasn't able to reproduce the bug outside my company's project (proprietary and which I don't have the permission to share), so I can't really help here. Code like this resides in proc-macro transformed function ( from leptos) and inside recursivelly calling macro. Here is how approximately it looks: <!-- 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. --Fails on both nightly and stable, backtrace if from nightly. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsHope this helps and thank for your work.
Relabeling issues which don't have a runnable reproduction (as opposed to not having a minimized one) to the new label S-needs-repro. label +S-needs-repro -E-needs-mcve
I think I encountered the same bug. A minimal example is below. I think the problem is a lookup, which includes the unimplemented trait without checking the length of the argument list before accessing. : Also fails on nightly. <details<summary<strongnightly ructc-</strong</summary<p</p</details
Maybe inside rollup ? cc
I ran into this ICE and minimized my case to the following reproducer. Its slightly different way to get to the same case as 's code above. Still happens from stable 1.77.2 to nightly 2024-04-19. When doing a bisection I get nightly-2023-05-16.
Change:
// type parameters, opaques, and unnormalized projections have pointer // metadata if they're known (e.g. by the param_env) to be sized ty::Param(_) | ty::Projection(..) | ty::Opaque(..) <del> if tail.is_sized(selcx.tcx().at(obligation.cause.span), obligation.param_env) => </del> <ins> if selcx.infcx().predicate_must_hold_modulo_regions( &obligation.with( ty::Binder::dummy(ty::TraitRef::new( selcx.tcx().require_lang_item(LangItem::Sized, None), selcx.tcx().mk_substs_trait(self_ty, &[]), )) .without_const() .to_predicate(selcx.tcx()), ), ) => </ins> { true }

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. --I recently updated my nightly toolchain and our project (still not open-sourced) ICE'd. I managed to reduce the problem to a minimal working example: <!-- 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</detailsI ran a quick : searched nightlies: from nightly-2022-03-01 to nightly-2022-03-24 regressed nightly: nightly-2022-03-16 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsThe offending line is the , so we should probably tag this with the appropriate feature tag. (Sorry if I messed anything up, I'm completely new to Rust ICE bug reports!) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
probably due to my PR claim
I get the same error on code that I got minimized to:
Same error with this example:
Same error I got with this example Defining it in a trait is fine though But adding a function body results in a crash
Change:
for &impl_node in cx.tcx.hir().trait_impls(trait_did) { let impl_did = cx.tcx.hir().local_def_id(impl_node); cx.tcx.sess.time("build_local_trait_impl", || { <del> inline::build_impl(cx, None, impl_did.to_def_id(), None, &mut new_items); </del> <ins> let mut extra_attrs = Vec::new(); let mut parent = cx.tcx.parent(impl_did.to_def_id()); while let Some(did) = parent { extra_attrs.extend( cx.tcx .get_attrs(did) .iter() .filter(|attr| attr.has_name(sym::doc)) .filter(|attr| { if let Some([attr]) = attr.meta_item_list().as_deref() { attr.has_name(sym::cfg) } else { false } }) .cloned(), ); parent = cx.tcx.parent(did); } inline::build_impl( cx, None, impl_did.to_def_id(), Some(&extra_attrs), &mut new_items, ); </ins> }); } }

Discussion:
I tried this code: I expected to see this happen: both impls being highlighted as needing the feature. Instead, this happened: only the impl got the message: ! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: +T-rustdoc
claim
Change:
fn foo() { let (x, y) = (0, 0); <del> x <- y; //~ ERROR expected one of </del> <ins> x <- y; //~ ERROR unexpected token: `<-` </ins> } fn main() {

Discussion:
produces: It would be nice if it produced a suggestion to split it up: (This , but was broken in a previous change.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi I'd like to try this one. Just found the removed suggestion.
claim
assign Hmm, triagebot is not well...
It doesn't look like you're still working on this. Is it ok if I take over?
Sure. Thanks for your help.
Change:
/// about e.g. the semicolon in `macro_rules! kapow { () => { /// panic!(); } }` doesn't get picked up by .parse_expr(), but it's /// allowed to be there. <del> fn ensure_complete_parse(&self, allow_semi: bool) { </del> <ins> fn ensure_complete_parse(&self, allow_semi: bool, context: &str) { </ins> let mut parser = self.parser.borrow_mut(); if allow_semi && parser.token == token::Semi { panictry!(parser.bump())

Discussion:
This compiles: I expected this to be rejected, simply because doesn't parse as a type.

afaik, it's because the context where you're using the macro (expr, item, etc.) stopped parsing before that token. We should mention that context.
Is this fixed? I think this was fixed the referenced pull request.
I'd prefer a message like
Change:
let backtrace = std::env::var_os("RUST_BACKTRACE").map_or(true, |x| &x != "0"); for bug in bugs { if let Some(file) = self.ice_file.as_ref() <del> && let Ok(mut out) = std::fs::File::options().append(true).open(file) </del> <ins> && let Ok(mut out) = std::fs::File::options().create(true).append(true).open(file) </ins> { let _ = write!( &mut out, <del> "nndelayed span bug: {}n{}", </del> <ins> "delayed span bug: {}n{}n", </ins> bug.inner.styled_message().iter().filter_map(|(msg, _)| msg.as_str()).collect::<String>(), &bug.note );

Discussion:
Sometimes when rustc dumps an ICE backtrace to disk, the file only contains I have yet to find what actual file/ice causes this, its a bit tricky since there is no mapping from ice file to the actual .rs that was used to cause the ICE. cc
Is this from a test case in the suite that's ICEing? I would like to try and reproduce this.
It looks like this is related to panics that happen during panics: With that file and the listed flags, you will get 3 stacktraces in stderr, but only one in the file:
The original finding was from one of the files in :sweat_smile:
That actually makes sense to me, I'll have to dig into it, but it sounds like it might be straightforward to fix. Edit: wait, re your last comment, did this new machinery regressed a previously fixed ICE, or is it an expected ICE that the new machinery didn't handle gracefully?
nono, not that I know, the directory is just full of files where plain does not crash anymore, but icemaker can use spicy -Z flags or different executables like rustdoc, rustfmt, clippy, miri, kani, cranelift that cause ices even in the directory :)
This happens exclusively for because they have their own machinery to print their own (more useful) backtrace. Looking into it.
Hm, I also just noticed, when for example clippy panics (you can force that with a delayspanbug attr), we also generate an empty file :/ ` repro
I believe that fixes the situation for all cases detected, both delayed span bugs and panic during panic.
Change:
}; fn_abi_adjust_for_abi(cx, &mut fn_abi, sig.abi, fn_def_id)?; debug!("fn_abi_new_uncached = {:?}", fn_abi); <del> fn_abi_sanity_check(cx, &fn_abi); </del> <ins> fn_abi_sanity_check(cx, &fn_abi, sig.abi); </ins> Ok(cx.tcx.arena.alloc(fn_abi)) }

Discussion:
Crate bytecount compilation fails with latest nightly on NanoPC-T6 (RK3588 ARM / aarch64). It worked yesterday. I tried this code: Updating index Adding bytecount v0.6.7 to dependencies. Features: generic-simd htmlreport packedsimd runtime-dispatch-simd Updating index Compiling bytecount v0.6.7 Intrinsic has incorrect return type! ptr in function ZN4core9corearch10armshared4neon9generated11vld1qu8x417hd6e0965b4ff7ff22E LLVM ERROR: Broken function found, compilation aborted! error: could not compile (lib) Compiling bytecount v0.6.7 Compiling bytecounttest v0.1.0 (/home/pi/bytecounttest) Finished dev [unoptimized + debuginfo] target(s) in 0.90s Linux NanoPC-T6 5.10.160 SMP Thu Jul 20 15:53:55 CST 2023 aarch64 aarch64 aarch64 GNU/Linux PRETTYNAME="Ubuntu 22.04.3 LTS" NAME="Ubuntu" VERSIONID="22.04" VERSION="22.04.3 LTS (Jammy Jellyfish)" VERSIONCODENAME=jammy ID=ubuntu IDLIKE=debian HOMEURL="" SUPPORTURL="" BUGREPORTURL="" PRIVACYPOLICYURL="" UBUNTUCODENAME=jammy I expected to see this happen: Finished dev [unoptimized + debuginfo] target(s) in 1.32s Instead, this happened: LLVM ERROR: Broken function found, compilation aborted!
searched nightlies: from nightly-2023-11-19 to nightly-2023-11-20 regressed nightly: nightly-2023-11-20 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: aarch64-unknown-linux-gnu Reproduce with: </detailslooks like something in that PR changed ABI behavior and now LLVM and rustc disagree. Don't know who's wrong.
Hm, I don't know how that "unadjusted" ABI stuff works...
should fix this. I am not sure how to add a test.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
<ins> fn main() { unknown(1, |glyf| { //~^ ERROR: cannot find function `unknown` in this scope let actual = glyf; }); } </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 (
Change:
* The _backslash escape_ is the character `U+005C` (``) which must be escaped in order to denote *itself*. <ins> ##### Raw string literals </ins> Raw string literals do not process any escapes. They start with the character `U+0072` (`r`), followed by zero or more of the character `U+0023` (`#`) and a `U+0022` (double-quote) character. The _raw string body_ is not defined in the

Discussion:
The doesn't document what escape sequences are valid if any. For example, documentation doesn't state whether this will match a newline as would be expected: It also doesn't specify what format these strings are supposed to be written in. Much of the documentation including many escape sequences are documented in the but it is difficult (slow) to parse as it is. I think it would be good to have it in or at least to make the reference more clear. More escape documentation is in (though it's not exactly related). For what it's worth, doesn't seem to document it either (at least, I couldn't find it). Below is my first shot at what it could look like. followed by any number (including zero) of 's followed by and closed in the reverse: A single ASCII character: A sequence of ASCII characters: Note: I'm not really familiar with all the string formats. I'm just to collect them together so they're more obvious. Does it make sense to collect them onto the  page? If so, I can probably submit a PR making something like this but I'm not sure where it should go.
Python , but in the language reference rather than the standard library documentation. Perhaps Rust’s escape sequences should be documented in the reference, where most other language-documenting features go.
Horizontal Tab, AKA t, ASCII/Unicode 9. See .
Oh, I completely misread this as 6 escapes (but it's 3 with their definitions). The .
I'm quite surprised to find that Rust doesn't have (i.e: 'backspace') built in to the language. Is there a particular reason for this?
asking on is a better place than on a three and a half year old issue.
Change:
terr: &TypeError<'tcx>) -> DiagnosticBuilder<'tcx> { <del> // FIXME: do we want to use a different error code for each origin? let mut diag = struct_span_err!( self.tcx.sess, trace.origin.span(), E0308, "{}", trace.origin.as_failure_str() ); </del> <ins> let span = trace.origin.span(); let failure_str = trace.origin.as_failure_str(); let mut diag = match trace.origin { TypeOrigin::IfExpressionWithNoElse(_) => { struct_span_err!(self.tcx.sess, span, E0317, "{}", failure_str) }, _ => { struct_span_err!(self.tcx.sess, span, E0308, "{}", failure_str) }, }; </ins> self.note_type_err(&mut diag, trace.origin, None, Some(trace.values), terr); diag }

Discussion:
Here's my code (2.rs): On running , I get And gives Am I missing something? Shouldn't the explanation talk about ?
The error explanation was in . The code reporting contains the following note: And, from :
Change:
(_, (TokenTree::Token(_, token::Token::Comma), _)) => continue, ((TokenTree::Token(sp, token_left), NonJoint), (TokenTree::Token(_, token_right), _)) <del> if (token_left.is_ident() || token_left.is_lit()) && (token_right.is_ident() || token_right.is_lit()) => *sp, </del> <ins> if ((token_left.is_ident() && !token_left.is_reserved_ident()) || token_left.is_lit()) && ((token_right.is_ident() && !token_right.is_reserved_ident()) || token_right.is_lit()) => *sp, </ins> ((TokenTree::Delimited(sp, ..), NonJoint), _) => sp.entire(), _ => continue, };

Discussion:
I don't know what to make of this error. () Errors: On stable (1.34) the output is
I'm pretty sure this is fallout from the "missing comma here" suggestion for macros, that evaluates the macro again with the current arguments but adding a comma token in between the argument tokens in different combinations to see if it would be correct. My guess is that that is causing a parse error that doesn't happen for normal things than only have one token in them. We can disable the suggestion when fully qualified paths are involved.
Change:
<ins> // edition:2015 #![crate_name = "foo"] use external::Public as Private; pub mod external { pub struct Public; // @has 'foo/external/fn.make.html' // @has - '//*[@class="rust item-decl"]/code' 'pub fn make() -> Public' pub fn make() -> ::Private { super::Private } } </ins>

Discussion:
rustdoc renders renamed imports () using the new, private name (e.g., in ). This is confusing behavior since the new name is an implementation detail. I think it should be using the original item's name instead. As an example, returns a , but the module it's defined in renames to . I would expect rustdoc to still show the item's definition name, but instead it shows the private name.
I don't think this should be changed until is fixed. Otherwise you could have two items shown with the same name and namespace in the same scope.
Code to reproduce: I don't think we need to wait for to be fixed as the fix for this doesn't impact it: if the re-export is not publicly reexported, we simply show the item underneath. When we will it will handle it the same.
Change:
// `$val` expression could be a block (`{ .. }`), in which case the `eprintln!` // will be malformed. () => { <del> $crate::eprintln!("[{}:{}]", $crate::file!(), $crate::line!()) </del> <ins> $crate::eprintln!("[{}:{}:{}]", $crate::file!(), $crate::line!(), $crate::column!()) </ins> }; ($val:expr $(,)?) => { // Use of `match` here is intentional because it affects the lifetimes // of temporaries - https://stackoverflow.com/a/48732525/1063961 match $val { tmp => { <del> $crate::eprintln!("[{}:{}] {} = {:#?}", $crate::file!(), $crate::line!(), $crate::stringify!($val), &tmp); </del> <ins> $crate::eprintln!("[{}:{}:{}] {} = {:#?}", $crate::file!(), $crate::line!(), $crate::column!(), $crate::stringify!($val), &tmp); </ins> tmp } }

Discussion:
I just found myself writing only to discover that the macro in fact only prints the source line and not the column of the macro start or something like that :sweatsmile: Is it possible to add the column as well? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
This section from the RFC is quite relevant, : The only exception to this is if the same expression is used multiple times and crucically has side effects altering the value between calls. This scenario is probably uncommon. Furthermore, even in this case, one can visually distinguish between the calls since one is first and the second comes next. we only want to keep the essential parts that help debugging most.
while I agree with the fact that often there is only one debug statement a line, i think that there is one major benefit that the rfc overlooked: users can directly jump to the pertinent debug statement through one unified method regardless of what are used in the statement itself and if multiple share a single line. searching visually is always slower than a hard, concrete jump. additionally, the rfc failed to acknowledge the case above as being an ambiguous situation when using solely line numbers. all this combined with the fact that means that it seems like a pretty sensible addition to the macro.