jiebi/CodeConvo huggingface dataset:
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/slice-const-param-mismatch.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default error[E0308]: mismatched types --> $DIR/slice-const-param-mismatch.rs:9:35 | LL |     let _: ConstString<"Hello"> = ConstString::<"World">; |                                   ^^^^^^^^^^^^^^^^^^^^^^ expected `"Hello"`, found `"World"` | = note: expected type `ConstString<>` found type `ConstString<>` error[E0308]: mismatched types --> $DIR/slice-const-param-mismatch.rs:11:33 | LL |     let _: ConstString<"ℇ㇈↦"> = ConstString::<"ℇ㇈↥">; |                                  ^^^^^^^^^^^^^^^^^^^^^ expected `"ℇ㇈↦"`, found `"ℇ㇈↥"` | = note: expected type `ConstString<>` found type `ConstString<>` error[E0308]: mismatched types --> $DIR/slice-const-param-mismatch.rs:13:33 | LL |     let _: ConstBytes<b"AAA"> = ConstBytes::<b"BBB">; |                                 ^^^^^^^^^^^^^^^^^^^^ expected `b"AAA"`, found `b"BBB"` | = note: expected type `ConstBytes<>` found type `ConstBytes<>` error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
Results in cc
modify labels: I-ICE C-Bug T-compiler A-const-generics
I'm looking into this currently.
Partially as a note to myself and partially as an update to anyone interested The root cause of this bug seems to be the fact that we currently don't explicitly handle slice const values in , and therefore we always say they cannot match. This error eventually bubbles up to to produce all three errors.
Change:
rx: &'a Receiver<T> } <ins> /// An iterator that attempts to yield all pending values for a receiver. /// `None` will be returned when there are no pending values remaining or /// if the corresponding channel has hung up. /// /// This Iterator will never block the caller in order to wait for data to /// become available. Instead, it will return `None`. #[unstable(feature = "receiver_try_iter", issue = "34931")] pub struct TryIter<'a, T: 'a> { rx: &'a Receiver<T> } </ins> /// An owning iterator over messages on a receiver, this iterator will block /// whenever `next` is called, waiting for a new message, and `None` will be /// returned when the corresponding channel has hung up.

Discussion:
Tracking issue for the new non-blocking iterator API introduced in . The API is currently gated behind the unstable feature. The API includes: - cc
Hey folks, just thought I'd ping this and ask if there's anything I can do to help guide this towards stable? Would love to start using it, but no worries if it's just low on the priority list :+1:
I'd like to know the same thing as mitchmindtree. Is this being guide towards stable?
fcp merge Seems like a nifty API to have!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, 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: psst I wasn't able to add the label, please do so.
The final comment period is now complete.
Change:
self.const_uint(self.type_i1(), val as u64) } <ins> fn const_i16(&self, i: i16) -> RValue<'gcc> { self.const_int(self.type_i16(), i as i64) } </ins> fn const_i32(&self, i: i32) -> RValue<'gcc> { self.const_int(self.type_i32(), i as i64) }

Discussion:
uses , and declares it to return i32, in reality it returns c_int, so this is a potential portability concern. Maybe memcmp can be made an intrinsic to resolve this.
It also takes a parameter, not a .
Neither of these are a practical issue (yet). crate libc does not support any other configuration than so far.
cc
The extern function is now in
What should we do next? Should we try to create a intrinsic?
Hi, I believe this issue is causing array comparisons on the AVR architecture to break (see the linked issue, ). Is there any consensus on a path forward here?
Change:
return None; } <del> // We stripped `()` and `!` when parsing the disambiguator. // Add them back to be displayed, but not prefix disambiguators. let link_text = disambiguator.map(|d| d.display_for(path_str)).unwrap_or_else(|| path_str.to_owned()); </del> // Strip generics from the path. let path_str = if path_str.contains(['<', '>'].as_slice()) { match strip_generics_from_path(&path_str) {

Discussion:
Consider this code: I'm not sure if this is a deliberate decision or not. If it is, what's the rationale for not accepting and ? cc
It isn't valid markdown syntax.
Well, might be. But [] definitely is not.
seems to work fine (it renders as and the link is correct). But maybe you're saying that we shouldn't accept because it wouldn't be valid markdown? Is it worth implementing?
hmm, it might be valid in that position, but it's not valid as a link reference: But I guess there's no reason for rustdoc to explicitly reject it. I would be ok with it, may have opinions.
I'm okay with it. I'm mostly wary about characters that are common in URLs, curly braces are not.
Oh, the reason why works is because the rules for inline links are more relaxed: vs So instead do you think rustdoc should parse ?

Consider this code: In the generated docs, the link on the page appears as , with the correct link, but without the parentheses.
Sorry, I stole this from you :smile:
That's okay! Thanks for fixing this :)
Change:
<ins> error[E0412]: cannot find type `T` in this scope --> $DIR/transmute-to-tail-with-err.rs:3:26 | LL | struct Bar(Box<dyn Trait<T>>); |                          ^ not found in this scope | help: you might be missing a type parameter | LL | struct Bar<T>(Box<dyn Trait<T>>); |           +++ error: aborting due to previous error For more information about this error, try `rustc --explain E0412`. </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. --This is a fuzzed test case, found with and minimized with , but found no similar issues. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2021-01-01 to nightly-2023-03-12 regressed nightly: nightly-2023-01-05 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: </detailsNote that this requires edition 2015/2018, as edition 2021 hard errors on the bare trait object before ever getting to layout code. cc
claim
Change:
err.note("try using `<*const T>::as_ref()` to get a reference to the  type behind the pointer: https://doc.rust-lang.org/std/ primitive.pointer.html#method.as_ref"); <ins> err.note("using `<*const T>::as_ref()` on a pointer  which is unaligned or points to invalid  or uninitialized memory is undefined behavior"); </ins> } err }

Discussion:
With we are now suggesting people to use when they have a raw pointer and need a reference. With gets some expanded documentation on UB avoidance. It might be a good idea to mention that also in the actual suggestion, so people don't have to open the docs to be aware of this. Cc
Can I take this on, since no one seems to have done it yet?
Sure, it's yours!
Change:
href.push_str(&fname.to_string_lossy()); let mut w = BufWriter::new(File::create(&cur)?); <del> let title = format!("{} -- source", cur.file_name().unwrap() </del> <ins> let title = format!("{} -- source", cur.file_name().expect("failed to get file name") </ins> .to_string_lossy()); let desc = format!("Source to the Rust file `{}`.", filename); let page = layout::Page {

Discussion:
After a simple , I tried to generate the crate documentation. I really don't know why I get this error. The problem seems to be here but what's wrong? ^^' The source is on glitch: !/nom- Feel free to ping me if you need to ask me more!
Is this a fluke or is your drive actually full? Is it a regular drive or a network share?
Oops! I didn't see the error message. My fork is stored on Glitch, it's a virtual drive I guess. I must have reached the storage limit authorized by Glitch. edit: ahah, that's it! !
That's not very nice as output... I'll write something a bit better.
As you requested here's the backtrace:
This ICE was changed into a proper error message by . This issue can be closed as a duplicate of .
Ok, thanks! I'll close it!
Change:
pub use self::ColorConfig::*; pub use self::types::*; pub use self::types::TestName::*; <del> pub use self::options::{Options, ShouldPanic}; </del> <ins> pub use self::options::{ColorConfig, Options, OutputFormat, RunIgnored, ShouldPanic}; </ins> pub use self::bench::{Bencher, black_box}; <ins> pub use self::console::run_tests_console; pub use cli::TestOpts; </ins> // Module to be used by rustc to compile tests in libtest pub mod test {

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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 compiler team prioritization.
Change:
use core::raw::TraitObject; use core::result::Result; use core::result::Result::{Ok, Err}; <ins> use core::ops::{Deref, DerefMut}; </ins> /// A value that represents the global exchange heap. This is the default /// place that the `box` keyword allocates into when no place is supplied.

Discussion:
As titled. Currently Box does not implement Deref: But Box should be able to implement Deref.
(Tagged E-easy in the hope that it's as simple as adding the impls gives in the issue. There is the chance that there is some compiler peculiarities that make this not-easy.)
has kindly volunteered to mentor; catch him here or as on IRC.
Can I have a go at this? Looks easy enough...
it's already been done/attempted in . :smile:
Oh well, never mind, I must've overlooked the cross-ref...
This issue seems resolved due to close and merge.
unfortunately it wasn't merged.
Change:
let extra_args = if sig.abi == RustCall { assert!(!sig.c_variadic && extra_args.is_empty()); <del> match sig.inputs().last().unwrap().kind { ty::Tuple(tupled_arguments) => { </del> <ins> if let Some(input) = sig.inputs().last() { if let ty::Tuple(tupled_arguments) = input.kind { </ins> inputs = &sig.inputs()[0..sig.inputs().len() - 1]; tupled_arguments.iter().map(|k| k.expect_ty()).collect() <del> } _ => { </del> <ins> } else { </ins> bug!( "argument to function with "rust-call" ABI  <del> is not a tuple" </del> <ins> is not a tuple" </ins> ); } <ins> } else { bug!( "argument to function with "rust-call" ABI  is not a tuple" ); </ins> } } else { assert!(sig.c_variadic || extra_args.is_empty());

Discussion:
Hi, I appear to have found this ICE that only occurs on nightly. Reproducing it is as simple as the below example:
Backtrace:
I'd like to give this a try. The failing code is this when ABI is RustCall it assumes two things: There will be at least one argument to the function The last argument will be a tuple For example if I change function type and add an argument, I get a different panic saying that the last argument should be a tuple: But if I turn that argument into a tuple it works: I don't know anything about RustCall ABI but assuming these restrictions are correct I guess there will be a check (maybe in the type checker?) that checks the function type and reject the program with a proper error message when the function is not valid according to RustCall ABI. That means a special case for . Does this make sense? Where is a good place to add this check? OP says this only happens in nightly, but is not supported on stable, so I'm not sure what they mean exactly. Did this ever work on older nightlies?
As of , it will still ICE, but deliberately (as the is incomplete).
Change:
let strict = tcx.sess.opts.unstable_opts.strict_init_checks; if strict { <del> let machine = CompileTimeInterpreter::new(Limit::new(0), false); </del> <ins> let machine = CompileTimeInterpreter::new( Limit::new(0), /*can_access_statics:*/ false, /*check_alignment:*/ true, ); </ins> let mut cx = InterpCx::new(tcx, rustc_span::DUMMY_SP, ParamEnv::reveal_all(), machine);

Discussion:
code from rustc this causes a new panic when executed via miri:
Ah, there was a reason why we disabled alignment checks in CTFE... This can probably be reproduced without Miri by passing -Zextra-const-ub-checks to rustc.
Yeah this just need "cargo miri run", no additional flags required. Edit: oops, misread :sweat_smile:
Right, this does also reproduce with . Do you want to move the issue?
Yeah let's move this to the rustc repo.
Change:
parser_remove_let = expected pattern, found `let` .suggestion = remove the unnecessary `let` keyword <ins> parser_use_eq_instead = unexpected `==` .suggestion = try using `=` instead </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: <!-- The following is not always necessary. --Ideally the output should suggest replacing the with where appropriate as the suggestion for incorrect usage of in place of already exist. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- 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 --
claim
Change:
<ins> fn main() { let page_size = page_size::get(); //~^ ERROR failed to resolve: use of undeclared crate or module `page_size` } </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. --This is new, introduced between (older) and (newer) src/tools/miri/tests/pass- <!-- 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
prioritize
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<del> // Copyright 2013 The Rust Project Developers. See the COPYRIGHT </del> <ins> // Copyright 2013-2014 The Rust Project Developers. See the COPYRIGHT </ins> // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. //

Discussion:
This code is wrong because ToStr does not define . But what's odd is that the compiler error does not happen in the block but in the : Error message: The expected error message would point to the block that needs to be split into two (one with ToStr and one without a trait).
Reproduced as of
Repro'd with -- but not critical for 0.6, de-milestoning
Appears to be fixed, as per this updated test case: fails with . Closing.
We've regressed: there's a test case (), but it's been xfailed since it was . With I see:
Aaaand, we've un-regressed! Removing all tags except for neesdtest.
Whoops, had the wrong code example, regression still here.
Change:
"Fruit1", "Fruit01", "Fruit2", "Fruit02", "Fruit20", <ins> "Fruit30x", </ins> "Fruit100", "Pear"]; let mut sorted = names.to_owned();

Discussion:
impl<'a, TIntoIterator for &'a mut [T; 12] impl<'a, TIntoIterator for &'a [T; 25] impl<'a, TIntoIterator for &'a mut [T; 21] impl<'a, TIntoIterator for &'a [T; 2] ... this ordering doesn't make any sense and makes the docs harder to navigate.
It has been fixed on nightly. The fix will come to stable eventually.
Change:
<del> fn a<const X: &'static [u32]>() {} //~^ ERROR `&'static [u32]` is forbidden as the type of a const generic parameter fn main() { a::<{&[]}>(); } </del>

Discussion:
<!-- 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
This works with because the type is forbidden. However, it continues to ICE with .
No longer ICEs since
Change:
ct_op: |ct| ct, ty_op: |ty| match *ty.kind() { ty::Alias(ty::Opaque, ty::AliasTy { def_id, .. }) <del> if replace_opaque_type(def_id) => </del> <ins> if replace_opaque_type(def_id) && !ty.has_escaping_bound_vars() => </ins> { let def_span = self.tcx.def_span(def_id); let span = if span.contains(def_span) { def_span } else { span };

Discussion:
Found this while minimizing :smile: So maybe related? didn't seem like duplicates. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +S-bug-has-mcve +F-typealiasimpl_trait
Regression in nightly-2022-07-01 reproduced based of a modifiction of which does not need any feature gates and crashes stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
popup.appendChild(container); insertAfter(popup, getSearchElement()); <ins> // So that it's only built once and then it'll do nothing when called! buildHelperPopup = function() {}; </ins> } onHashChange(null); window.onhashchange = onHashChange; <del> buildHelperPopup(); </del> }()); // This is required in firefox. Explanations: when going back in the history, firefox doesn't re-run

Discussion:
The rustdoc help says However, in Rust lingo, or isn't a "type". is a type. And , and certainly aren't "types". IMO this should at least be qualified to something like "item type", but I think "item kind" would be even better.
Cc
Change:
fn walk_pat(&mut self, cmt_discr: mc::cmt<'tcx>, pat: &hir::Pat, match_mode: MatchMode) { debug!("walk_pat cmt_discr={:?} pat={:?}", cmt_discr, pat); <del> let tcx = self.tcx(); </del> let ExprUseVisitor { ref mc, ref mut delegate, param_env } = *self; return_if_err!(mc.cat_pattern(cmt_discr.clone(), pat, |cmt_pat, pat| { if let PatKind::Binding(bmode, def_id, ..) = pat.node {

Discussion:
I got panic with this code (): Backtrace: My rust version:
This code seems to be minimal example type Value = String; fn main() { let f = ""; Some("".into()).map(f); }
Change:
), }; if mut_ident && matches!(ctxt, FnCtxt::Assoc(_)) { <del> self.lint_buffer.buffer_lint(PATTERNS_IN_FNS_WITHOUT_BODY, id, span, msg); </del> <ins> if let Some(ident) = ident { let diag = BuiltinLintDiagnostics::PatternsInFnsWithoutBody(span, ident); self.lint_buffer.buffer_lint_with_diagnostic( PATTERNS_IN_FNS_WITHOUT_BODY, id, span, msg, diag, ) } </ins> } else { self.err_handler() .struct_span_err(span, msg)

Discussion:
Taken from We should suggest to use an identifier. When possible take that identifier from the pattern, otherwise should work just as well. CC
I'll try it!
Change:
#[rustc_const_unstable(feature = "const_ascii_ctype_on_intrinsics", issue = "68983")] #[inline] pub const fn is_ascii_lowercase(&self) -> bool { <del> self.is_ascii() && (*self as u8).is_ascii_lowercase() </del> <ins> match *self { 'a'..='z' => true, _ => false, } </ins> } /// Checks if the value is an ASCII alphanumeric character:

Discussion:
I noticed this check: and wondered why it's there. Then someone told me it's there because of the . If you pass a non-ASCII char, the would corrupt that char. That's why the check is there before it. But then I wondered: why isn't this just cast to a bigger data type that includes all Unicode code points? This method (and others) are slower than they have to be. Also see this discussion in Discord with more valuable information:
(I can’t seem to find the relevant part in the middle of this discord stream…) I’m not sure what you mean by “corrupt”. is well defined: it takes the numerical value of the code point (same as ), then truncates to keep the lower 8 bits. equals 0x41, but so does . We want to reject the latter since U+1F041 is not an ASCII upper-case letter. If is implemented in terms of , the ASCII range check is necessary. (It could be a range check to, for example with .) But maybe doesn’t need to be implemented in terms of . Maybe it could duplicate the logic instead. Once upon a time was implemented with a lookup table of 256 entries. A flat lookup table for all of Unicode would be way too big. But these days it’s based on matching a range pattern. Doing the same with a range pattern could also work. That said, would it actually be faster? Maybe the optimizer already does its job well. If you want to work on this, consider adding some benchmark to show that code duplication is worth it.
Oh it seems the Discord link is a bit buggy. Try searching for in the search bar on the Discord server. Then you should get to my message with the discussion below it. One guy also posted this comparison of the instructions generated:
I think the minimal standard here should be a benchmark before we change the implementation. Can you provide that?
I'm not that experienced with Rust yet, sorry. I just wanted to point out this possible performance regression. Shouldn't the instruction amount difference as shown on Godbolt suffice to know that it's slower? vs.
Looking at the assembly, it seems that the problem is the check. These three functions produce : So, it seems that the check is unnecessary. I could make a PR for this.

Here are some benchmarks: So it seems that removing the check has a measurable performance difference.
is incorrect. The conversion should happen not for the ASCII check but for the , and the pattern use byte literals like . (Though I expect this won’t affect results much.)
Change:
self_ty, method_self_ty, self.span, pick ); let cause = self.cause( <del> self.span, </del> <ins> self.self_expr.span, </ins> ObligationCauseCode::UnifyReceiver(Box::new(UnifyReceiverContext { assoc_item: pick.item, param_env: self.param_env,

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
label +F-arbitraryselftypes