jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0308]: mismatched types --> $DIR/bad-type-in-vec-contains.rs:5:21 | LL |     primes.contains(3); |            -------- ^ |            |        | |            |        expected `&_`, found integer |            |        help: consider borrowing here: `&3` |            arguments to this method are incorrect |            here the type of `primes` is inferred to be `[_]` | = note: expected reference `&_` found type `{integer}` note: method defined here --> $SRC_DIR/core/src/slice/mod.rs:LL:COL error: aborting due to 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. --<!-- 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 --
mcve Crashes on nightly and , stable 167:
claim
searched nightlies: from nightly-2023-01-01 to nightly-2023-03-02 regressed nightly: nightly-2023-01-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details cc
Change:
) -> ConstPropagator<'mir, 'tcx> { let def_id = source.def_id(); let substs = &InternalSubsts::identity_for_item(tcx, def_id); <del> let mut param_env = tcx.param_env(def_id); // If we're evaluating inside a monomorphic function, then use `Reveal::All` because // we want to see the same instances that codegen will see. This allows us to `resolve()` // specializations. if !substs.needs_subst() { param_env = param_env.with_reveal_all(); } </del> <ins> let param_env = tcx.param_env(def_id).with_reveal_all(); </ins> let span = tcx.def_span(def_id); let mut ecx = InterpCx::new(tcx.at(span), param_env, ConstPropMachine, ());

Discussion:
The assembly generated in debug builds (-C opt-level=0) worsened for this code that uses an associated constant from a trait.This seems to be caused by the fact that the function is generic,even though the associated constant doesn't depend on the generic parameters of the function. The code: The entirety of the generated assembly for stable 1.41.0 in a debug build: The assembly generated for the same functions by rustc 1.42.0-beta.2 (2020-02-04 ) in a debug build:
out of curiosity, what prompted you to investigate this specific code sequence? (I'm trying to evaluate the severity of this code-quality regression, and it might help for me to get some idea of how wide-spread the problem might be. There are obviously a couple different features interacting in the example you have provided...)
triage: leaving unprioritized. Nominating for discussion at today's T-compiler triage meeting.
I was experimenting to figure out the best design for a feature I want to add to eventually,being efficient in debug builds is a plus(but not a hard requirement for me). The reason I reported this is that if it optimizes fine in non-generic functions,it should also do the same optimization in generic functions(so long as the constant doesn't depend on generic parameters).
How does LLVM even generate such a code sequence? Well...: Okay so I guess LLVM doesn't even simplify the CFG when optimizations are off? <hr/Anyway, the MIR differs. This is a constant folding regression. cc
I'm guessing this is caused by We're in a generic context and resolve has to be conservative so it doesn't accidentally try to inline a default value if it could get a different value in an impl. In this situation that can't happen, but I don't know how to coax resolve to know this.
The fix was already implemented though! already returns in the problematic cases. Users of don't need to special-case anything anymore. Nor do we ever need to use just because something might be polymorphic, because the fix is in already, as it has been in for associated types. I left comments here:
T-compiler triage: P-medium. Leaving nomination tag on until we actually assign this to someone.
Change:
<ins> // revisions: stock gce #![feature(associated_const_equality)] #![cfg_attr(gce, feature(generic_const_exprs))] //[gce]~^ WARN the feature `generic_const_exprs` is incomplete trait TraitWAssocConst { const A: usize; } fn foo<T: TraitWAssocConst<A = 1>>() {} fn bar<T: TraitWAssocConst<A = 0>>() { foo::<T>(); //~^ ERROR type mismatch resolving `<T as TraitWAssocConst>::A == 1` } fn main() {} </ins>

Discussion:
thread panicked at 'called on a value', <details<summaryBacktrace</summary</detailsRegression in nightly-2022-12-04, in rollup , likely from (
Change:
match path { QPath::Resolved(_, ref path) => { <del> let mut arg_index = 0; let mut found_const = false; for seg in &path.segments { if let Some(generic_args) = &seg.args { let args = &generic_args.args; for arg in args { if let GenericArg::Const(ct) = arg { if ct.value.hir_id == hir_id { found_const = true; break; } arg_index += 1; } } } } // Sanity check to make sure everything is as expected. if !found_const { if !fail { return None; } bug!("no arg matching AnonConst in path") } match path.res { // We've encountered an `AnonConst` in some path, so we need to // figure out which generic parameter it corresponds to and return // the relevant type. Res::Def(DefKind::Struct, def_id) | Res::Def(DefKind::Union, def_id) | Res::Def(DefKind::Enum, def_id) | Res::Def(DefKind::Fn, def_id) => { let generics = tcx.generics_of(def_id); let mut param_index = 0; for param in &generics.params { if let ty::GenericParamDefKind::Const = param.kind { if param_index == arg_index { return Some(tcx.type_of(param.def_id)); } param_index += 1; } } // This is no generic parameter associated with the arg. This is // probably from an extra arg where one is not needed. return Some(tcx.types.err); } Res::Err => tcx.types.err, x => { </del> <ins> let arg_index = path.segments.iter() .filter_map(|seg| seg.args.as_ref()) .map(|generic_args| generic_args.args.as_ref()) .find_map(|args| { args.iter() .filter(|arg| arg.is_const()) .enumerate() .filter(|(_, arg)| arg.id() == hir_id) .map(|(index, _)| index) .next() }) .or_else(|| { </ins> if !fail { <del> return None; </del> <ins> None } else { bug!("no arg matching AnonConst in path") </ins> } <ins> })?; // We've encountered an `AnonConst` in some path, so we need to // figure out which generic parameter it corresponds to and return // the relevant type. let generics = match path.res { Res::Def(DefKind::Ctor(..), def_id) => tcx.generics_of(tcx.parent(def_id).unwrap()), Res::Def(_, def_id) => tcx.generics_of(def_id), Res::Err => return Some(tcx.types.err), _ if !fail => return None, x => { </ins> tcx.sess.delay_span_bug( DUMMY_SP, &format!( "unexpected const parent path def {:?}", x ), ); <del> tcx.types.err </del> <ins> return Some(tcx.types.err); </ins> } <del> } </del> <ins> }; generics.params.iter() .filter(|param| { if let ty::GenericParamDefKind::Const = param.kind { true } else { false } }) .nth(arg_index) .map(|param| tcx.type_of(param.def_id)) // This is no generic parameter associated with the arg. This is // probably from an extra arg where one is not needed. .unwrap_or(tcx.types.err) </ins> } x => { if !fail {

Discussion:
This very simple example (): results in: . Changing it to use curly braces around does not help.
This does work:
I was actually just experimenting locally to see if I could fix this and I think I have, I could put a PR up in a few minutes.
Change:
&**expr } else { ccx.sess().span_bug(ref_expr.span, <del> &format!("get_const_val given non-constant item {}", </del> <ins> &format!("get_const_expr given non-constant item {}", </ins> item.repr(ccx.tcx()))); } }

Discussion:
Rust version: OS: Gentoo Linux AMD64
cc
The same thing happens with openssl-sys 0.4.1:
For anyone running into this, you can disable debug info to work around the issue until it's fixed:
Same problem here. Rust version: rustc 1.0.0-nightly ( 2015-02-17) (built 2015-02-18) Operating System: OS X Yosemite 10.10.2
It looks like I have the same problem: Compiling mio v0.2.1 () Running 1:1 error: internal compiler error: debuginfo: Could not find scope info for node NodeExpr(Expr { id: 5326, node: ExprStruct(Path { span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() }, global: false, segments: [PathSegment { identifier: StaticMutex, parameters: AngleBracketedParameters(AngleBracketedParameterData { lifetimes: [], types: [], bindings: [] }) }] }, [Field { ident: Spanned { node: lock, span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }, expr: Expr { id: 5327, node: ExprPath(Path { span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() }, global: false, segments: [PathSegment { identifier: sys, parameters: AngleBracketedParameters(AngleBracketedParameterData { lifetimes: [], types: [], bindings: [] }) }, PathSegment { identifier: MUTEXINIT, parameters: AngleBracketedParameters(AngleBracketedParameterData { lifetimes: [], types: [], bindings: [] }) }] }), span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }, span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }, Field { ident: Spanned { node: poison, span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }, expr: Expr { id: 5328, node: ExprPath(Path { span: Span { lo: BytePos(0),

hi: BytePos(0), expnid: ExpnId() }, global: false, segments: [PathSegment { identifier: poison, parameters: AngleBracketedParameters(AngleBracketedParameterData { lifetimes: [], types: [], bindings: [] }) }, PathSegment { identifier: FLAGINIT, parameters: AngleBracketedParameters(AngleBracketedParameterData { lifetimes: [], types: [], bindings: [] }) }] }), span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }, span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }], None), span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }) #![allow(noncamelcasetypes, nonuppercaseglobals, nonsnakecase)] ^ Rust version: rustc 1.0.0-nightly ( 2015-02-17) (built 2015-02-18) OS: 3.13.0-24-generic -Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x8664 x8664 x86_64 GNU/Linux
A minimized version:
Minimized a bit further actually, perhaps you could publish a version which uses instead of on the vector of ?
Er, nevermind, I have against rust-openssl to temporarily fix this.
I encountered a similar problem with constants in match patterns. This very probably has the same root cause, which is that the AST of constants gets substituted for the constant-reference during trans, but then we suddenly have a bunch of unrelated AST node ids in there. I'll try to fix this this week.
My minimal case:
Change:
if def.variants.len() > 1 { needs_to_be_read = true; } <ins> } else { // If it is not ty::Adt, then it should be read needs_to_be_read = true; </ins> } } PatKind::Lit(_) | PatKind::Range(..) => {

Discussion:
The following ICE was found migrating 0.26.0 and  0.4.38. cc which was an error on the same line, though I think the cause is slightly different. Note that I think this is also triggering an incorrect lint for the parameter (the actual code uses the parameter). <!-- 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</detailscc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // MIR for `_f` after built fn _f(_1: !, _2: !) -> () { debug a => _1; debug b => _2; let mut _0: (); let mut _3: !; let _4: bool; let mut _5: &(); let mut _6: !; let mut _7: &(); let _8: (); let mut _9: !; bb0: { StorageLive(_4); StorageLive(_5); StorageLive(_6); _6 = _1; unreachable; } bb1: { StorageDead(_6); StorageLive(_7); StorageLive(_8); StorageLive(_9); _9 = _2; unreachable; } bb2: { _7 = &_8; StorageDead(_9); _4 = <() as PartialEq>::eq(move _5, move _7) -> [return: bb3, unwind: bb5]; } bb3: { StorageDead(_7); StorageDead(_5); StorageDead(_8); StorageDead(_4); unreachable; } bb4: { return; } bb5 (cleanup): { resume; } } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: broken MIR in DefId(0:20 ~ o[fbbd]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move 23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !): NoSolution', 'error: internal compiler error: broken MIR in DefId(0:20 ~ o[fbbd]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move 23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !): NoSolution' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: error: internal compiler error: broken MIR in DefId(0:20 ~ mvce[954a]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move _23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !

): NoSolution --
Regression in nightly-2023-05-23 commit[0] 2023-05-21: Auto merge of - MU001999:fix/issue-, r=cjgillot commit[1] 2023-05-21: Auto merge of - Zoxc:query-structs-trim, r=cjgillot commit[2] 2023-05-22: Auto merge of - lukas-code:strike, r=notriddle commit[3] 2023-05-22: Auto merge of - the8472:filter-map-chunk, r=thomcc commit[4] 2023-05-22: Auto merge of - matthiaskrgr:rollup-qd4b2vu, r=matthiaskrgr commit[5] 2023-05-22: Auto merge of - Jules-Bertholet:document-pin-layout, r=thomcc commit[6] 2023-05-22: Auto merge of - compiler-errors:triple-check, r=Nilstrieb commit[7] 2023-05-22: Auto merge of - marc0246:arc-new-uninit-bloat, r=thomcc commit[8] 2023-05-22: Auto merge of - lcnr:recursion-depth, r=matthewjasper commit[9] 2023-05-22: Auto merge of - Dylan-DPC:rollup-7jqydzg, r=Dylan-DPC ERROR: no CI builds available between and within last 167 days cc
Minimized:
Minimized even more: (I independently found the same bug while running crater with the fallback being )
Change:
} } <ins> fn contains_null(s: &str) -> bool { s.bytes().any(|b| b == 0) } </ins> pub fn get_item_val(ccx: &CrateContext, id: ast::NodeId) -> ValueRef { debug!("get_item_val(id=`{:?}`)", id);

Discussion:
Both the exportname and linksection attributes will produce an ICE if '0' is contained within the string. Input Output and Bakctrace Version
Fascinating find! I'm curious about what lead you to it. Is there a need to put null in these values?
I had typed rather than . It was an accidental discovery, I'm not aware of any need for a null character here.
I marked this as easy since fixing this is probably just a matter of going to that exact code and emitting a proper error. Good starter bug.
This is actually caused by CStrings failing the task if they have an interior null. . Adding an error would fix this particular issue, but it wouldn't fix the underlying issue, so maybe a different course of action would be better. On a side note, what is the proper way to add an error to the compiler? ? ? I couldn't find any documentation on it.
What is the underlying issue? That we should always throw an error if a has an interior null character? Or that we should allow 's to have null characters?
The underlying issue was that the checked versions of tocstring and withcstr crash on interior nulls. Doing an extra interior null check before calling them in this case doesn't help with this problem in other cases, and failing the task seems unnecessary, especially for the checked version. Perhaps the checked version could return an Option, and the unchecked would keep its current behavior. Edit: Alternately, a tocstropt function could be and used where necessary.
Is anyone working on this? I'll take a crack at it this week if not.
I am. I a withcstr_opt function (that had to wait on ), and am putting the finishing touches on the error messages.
Change:
pub fn retain<F>(&mut self, mut f: F) where F: FnMut(&T) -> bool { <del> self.drain_filter(|x| !f(x)); </del> <ins> let len = self.len(); let mut del = 0; { let v = &mut **self; for i in 0..len { if !f(&v[i]) { del += 1; } else if del > 0 { v.swap(i - del, i); } } } if del > 0 { self.truncate(len - del); } </ins> } /// Removes all but the first of consecutive elements in the vector that resolve to the same

Discussion:
I posted on stackoverflow. What happens is that when using retain over a vector, it seems to be a lot slower in version 1.38.0. host is: x86_64-unknown-linux-gpu (according to rustc--version --verbose) and LLVM version is 8.0. I'm using ubuntu 19.04. As I wrote on SO, I tried: And changed between versions with and , having updated rust before with . p.s.: From my complete program I also noticed that version 1.38.0 was still a little bit slower without using retain(). But the difference was minimal (~5%) and hard to come up with another culprit.
Performance of this code in 1.37 is similar to that in 1.36, so this would appear to be a regression in 1.38. Rust 1.37.0: 2.8 seconds Rust 1.38.0: 5.7 seconds
Minimal example:
Could you check against nightly compiler?
In the nightly version it takes about the same time as in stable.
stable is Rust 1.38.0?
yes, stable is 1.38.0.
Will this ever be fixed or looked at? I understand that the devs may have too much work and too little help, I wish I had the knowledge to help, just sincerely asking.
I bet it's fallout from upgrade to LLVM 9 but bisecting it would greatly help (either manually or with ).
Change:
Y(Uninhabited), } <ins> enum MultipleUninhabited { X(u8, Uninhabited), Y(Uninhabited, u16), } </ins> fn main() { assert_transmutable::<Uninhabited>(); assert_transmutable::<SingleInhabited>(); assert_transmutable::<SingleUninhabited>(); <ins> assert_transmutable::<MultipleUninhabited>(); </ins> }

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [evaluateobligation] evaluating trait selection obligation [typeck] type-checking -- label +F-transmutability <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Ah, it's an uninhabited non-ZST!
claim
I guess that answers my ;)
Change:
[[package]] name = "directories" <del> version = "1.0.2" </del> <ins> version = "2.0.1" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ <del> "libc 0.2.54 (registry+https://github.com/rust-lang/crates.io-index)", "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "cfg-if 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)", "dirs-sys 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)", </ins> ] [[package]]

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
Miri is fixed upstream, but will be broken again by so I'd like to land that before updating.
Change:
hasClass(next.nextElementSibling, 'docblock'))) { insertAfter(toggle.cloneNode(true), e.childNodes[e.childNodes.length - 1]); } <ins> if (hasClass(e, 'impl')) { insertAfter(toggle.cloneNode(true), e.childNodes[e.childNodes.length - 1]); } </ins> } onEach(document.getElementsByClassName('method'), func); <ins> onEach(document.getElementsByClassName('impl'), func); </ins> onEach(document.getElementsByClassName('impl-items'), function(e) { onEach(e.getElementsByClassName('associatedconstant'), func); });

Discussion:
When pressing the hotkey on type's documentation such as on the , the methods of the are still shown. This is however mostly useless information that gets in the way of scrolling to see what traits a type implements. It would be more ergonomic if would hide every method of every trait but still show all associated items (types and consts) for each (since they carry useful information). In addition, a / link should be on all the s (including non-trait impls) either besides or to the left of the (as done with s this expands and collapses the impls but keeps associated items shown.
I can rewrite this as an RFC if required, but I was unsure about the protocol wrt. rustdoc.
Similar request:
Closing as resolved.

For example, looking at the docs for , some important trait implementations are hard to find in between all the implementations for each size of fixed-size arrays: Hopefully these impls will eventually become generic, but in the meantime we should consider some way of hiding or collapsing them in the docs.
cc
Dupe of
Change:
Duration { secs: secs, nanos: nanos } } <ins> /// Creates a new `Duration` from the specified number of microseconds. /// /// # Examples /// /// ``` /// #![feature(duration_from_micros)] /// use std::time::Duration; /// /// let duration = Duration::from_micros(1_000_002); /// /// assert_eq!(1, duration.as_secs()); /// assert_eq!(2000, duration.subsec_nanos()); /// ``` #[unstable(feature = "duration_from_micros", issue = "44400")] #[inline] pub fn from_micros(micros: u64) -> Duration { let secs = micros / MICROS_PER_SEC; let nanos = ((micros % MICROS_PER_SEC) as u32) * NANOS_PER_MICRO; Duration { secs: secs, nanos: nanos } } </ins> /// Returns the number of _whole_ seconds contained by this `Duration`. /// /// The returned value does not include the fractional (nanosecond) part of the

Discussion:
During the write of an embedded library I needed to make a pause of 10 microseconds. Looking over the I understood that I had to use the following construction: The sad part is that this is less clear to me than . Currently the and functions are implemented but not which could help write cleaner code IMO. The fix seems pretty easy, maybe if you judge this useful I can try to write my first pull request to the Rust project!
In general, this is how works; small additions can just be a PR, larger additions need an RFC. So, I'd suggest that you send in a PR implementing this.
Adding sounds okay to me.
Yeah, I'd be on board with a PR.
This is now a tracking issue for the function in the previously referenced PR.
Looks good to me to stabilize. fcp merge
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 a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
Change:
<del> Subproject commit 2bd5d42c9956369132228da6409f0e68da56c51a </del> <ins> Subproject commit 2cd1b5593d26dc6a03c20f8619187ad4b2485552 </ins>

Discussion:
Compile the above (faulty) code with gives me this:
Probably related to .
Thanks for the information! Close this one.