jiebi/CodeConvo huggingface dataset:
Change:
const BAR: bool = unsafe { foo(false) }; fn main() { <del> assert_eq!(BAR, true); </del> <ins> assert_eq!(BAR, true); </ins> }

Discussion:
Currently one cannot call in constant functions, so one cannot add hints of the form: These types of hints can heavily influence code generation, which can substantially change the performance of when they are invoked at run-time. It would be a shame to have to write and call and because the code generated for is sub-par. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
One cannot do any sort of conditional control flow, so would currently be less than useless. Any test you can write would be undefined behaviour
the RFC for / in const was merged and is pending an implementation right? When that's implemented, will still be useless?
No it makes sense after we have conditional control flow.
As I understand / in const functions is now implemented. Can be made into a now?
yes. Basically you just need to add the attribute to the intrinsic and wrapper function. This is documented at https://rustc-dev- Let me know if anything is unclear (in which case we should update the guide)
Hi, It looks like previous PR is not being worked on currently. I'm working on this and will create a PR soon. claim
As mentioned in , this issue should be reopened (to track stablization)
cc ^
After a short discussion on Zulip, it was decided that it's best to wait for to stabilize to avoid a potential footgun wherein users use this instead of , leading to UB at runtime. I'm subscribed to the issue and intend to file a PR to stabilize this once the aforementioned happens.
Change:
(regions, types) } <ins> /// Returns the appropriate lifetime to use for any output lifetimes /// (if one exists) and a vector of the (pattern, number of lifetimes) /// corresponding to each input type/pattern. fn find_implied_output_region(input_tys: &[Ty], input_pats: Vec<String>) -> (Option<ty::Region>, Vec<(String, uint)>) { let mut lifetimes_for_params: Vec<(String, uint)> = Vec::new(); let mut possible_implied_output_region = None; for (input_type, input_pat) in input_tys.iter().zip(input_pats.into_iter()) { let mut accumulator = Vec::new(); ty::accumulate_lifetimes_in_type(&mut accumulator, *input_type); if accumulator.len() == 1 { // there's a chance that the unique lifetime of this // iteration will be the appropriate lifetime for output // parameters, so lets store it. possible_implied_output_region = Some(accumulator[0]) } lifetimes_for_params.push((input_pat, accumulator.len())); } let implied_output_region = if lifetimes_for_params.iter().map(|&(_, n)| n).sum() == 1 { assert!(possible_implied_output_region.is_some()); possible_implied_output_region } else { None }; (implied_output_region, lifetimes_for_params) } fn convert_ty_with_lifetime_elision<'tcx,AC>(this: &AC, implied_output_region: Option<ty::Region>, param_lifetimes: Vec<(String, uint)>, ty: &ast::Ty) -> Ty<'tcx> where AC: AstConv<'tcx> { match implied_output_region { Some(implied_output_region) => { let rb = SpecificRscope::new(implied_output_region); ast_ty_to_ty(this, &rb, ty) } None => { // All regions must be explicitly specified in the output // if the lifetime elision rules do not apply. This saves // the user from potentially-confusing errors. let rb = UnelidableRscope::new(param_lifetimes); ast_ty_to_ty(this, &rb, ty) } } } </ins> fn convert_parenthesized_parameters<'tcx,AC>(this: &AC, data: &ast::ParenthesizedParameterData) -> Vec<Ty<'tcx>> where AC: AstConv<'tcx> { let binding_rscope = BindingRscope::new(); let inputs = data.inputs.iter() .map(|a_t| ast_ty_to_ty(this, &binding_rscope, &**a_t)) <del> .collect(); </del> <ins> .collect::<Vec<Ty<'tcx>>>(); let input_params = Vec::from_elem(inputs.len(), String::new()); let (implied_output_region, params_lifetimes) = find_implied_output_region(&*inputs, input_params); </ins> let input_ty = ty::mk_tup(this.tcx(), inputs); let output = match data.output { <del> Some(ref output_ty) => ast_ty_to_ty(this, &binding_rscope, &**output_ty), </del> <ins> Some(ref output_ty) => convert_ty_with_lifetime_elision(this, implied_output_region, params_lifetimes, &**output_ty), </ins> None => ty::mk_nil(this.tcx()), };

Discussion:
HRTB doesn't correctly implement lifetime elision for notation. See the test .
Nominating.
notes that this can be fixed backwards compatibly, and agrees. P-high, not 1.0.
Well, sort of -- I mean lifetime elision broke code, but almost only bad code. The problem is that people can use to satisfy the signature and then clients get to assume any lifetime they want.
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![allow(dead_code)] trait Foo {} impl Foo for int {} fn foo(_: [&Foo, ..2]) {} fn foos(_: &[&Foo]) {} fn foog<T>(_: &[T], _: &[T]) {} fn bar(_: [Box<Foo>, ..2]) {} fn bars(_: &[Box<Foo>]) {} fn main() { let x: [&Foo, ..2] = [&1i, &2i]; foo(x); foo([&1i, &2i]); let r = &1i; let x: [&Foo, ..2] = [r, ..2]; foo(x); foo([&1i, ..2]); let x: &[&Foo] = &[&1i, &2i]; foos(x); foos(&[&1i, &2i]); let x: &[&Foo] = &[&1i, &2i]; let r = &1i; foog(x, &[r]); let x: [Box<Foo>, ..2] = [box 1i, box 2i]; bar(x); bar([box 1i, box 2i]); let x: &[Box<Foo>] = &[box 1i, box 2i]; bars(x); bars(&[box 1i, box 2i]); let x: &[Box<Foo>] = &[box 1i, box 2i]; foog(x, &[box 1i]); struct T<'a> { t: [&'a Foo, ..2] } let _n = T { t: [&1i, &2i] }; let r = &1i; let _n = T { t: [r, ..2] }; let x: [&Foo, ..2] = [&1i, &2i]; let _n = T { t: x }; struct F<'b> { t: &'b [&'b Foo] } let _n = F { t: &[&1i, &2i] }; let r = &1i; let r: [&Foo, ..2] = [r, ..2]; let _n = F { t: r }; let x: [&Foo, ..2] = [&1i, &2i]; let _n = F { t: x }; struct M<'a> { t: &'a [Box<Foo>] } let _n = M { t: &[box 1i, box 2i] }; let x: [Box<Foo>, ..2] = [box 1i, box 2i]; let _n = M { t: x }; } </ins>

Discussion:
fails to compile: cc
What does the l-wrong label mean here?
It means that the current behavior of the compiler is incorrect.
Change:
use rustc_hir::def_id::{LocalDefId, CRATE_DEF_ID}; use rustc_hir::PredicateOrigin; use rustc_index::{Idx, IndexSlice, IndexVec}; <ins> use rustc_middle::span_bug; </ins> use rustc_middle::ty::{ResolverAstLowering, TyCtxt}; use rustc_span::edit_distance::find_best_match_for_name; use rustc_span::symbol::{kw, sym, Ident};

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: no host param id for call in const yet no errors reported', 'error: internal compiler error: no host param id for call in const yet no errors reported' File: --auto-reduced (treereduce-rust): original: 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: --
Regression in nightly-2023-08-09
Change:
debug!("out pointer, foreign={}", ccx.tn().val_to_string(llforeign_outptr)); let llrust_retptr = <del> builder.bitcast(llforeign_outptr, llrust_retptr_ty); </del> <ins> builder.bitcast(llforeign_outptr, llrust_ret_ty.ptr_to()); </ins> debug!("out pointer, foreign={} (casted)", ccx.tn().val_to_string(llrust_retptr)); llrust_args.push(llrust_retptr);

Discussion:
Repro: ICE:
tracks a number of cases that throw the same error.
A couple of hints - it looks like it happens when structure size is actually smaller or equal to register of architecture. I had the similar report for failing on iOS with the following sample: It fails on and if + <= 64 bits, i.e. they are u16 or u32. When switching to armv7 it fails if + <= 32 bits
after 6 hours bisecting the verdict is - , part of
sigh I actually saw that when I was working on but didn't come up with a test case that would trigger a problem here and then forgot about it. Will look into this.
will fix hit the upcoming beta?
Sorry, fixing a few regressions in LLVM that affected rust had higher priority for me than this issue (because LLVM is very close to its 3.6 release), so I couldn't devote much time to this issue yet. But given that the beta is still ~3 weeks away, I'm positive that I'll get around to have it fixed by then.
Hmm, beta is on week of Feb 16 (i.e. next week), isn't it?
Yes. Although, as someone hitting that bug, I'd be okay if that were flagged as a known bug and would prefer if semantic issues were cared about first.
I have nothing against fixing regressions, still be extremely happy to see it fixed as I will be stuck on beta1 following 6 weeks till beta2 or rc1.
:tada: thanks a lot!
Change:
<ins> #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] // library portion of testing that `impl Trait<{ expr }>` doesnt // ice because of a `DefKind::TyParam` parent pub fn foo<const N: usize>(foo: impl Into<[(); N + 1]>) { foo.into(); } </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. --I tried simplifying my code, but the code is quite complex and I wasn't able to recreate the ICE. Here is the repo which you can try building to see it for yourself: The main source of the issue is my Tensor structs which look similar to the below code. I have had issues with this . The ICE started happening after I convolution with fft. I to simplify writing the types. Maybe it's related? Sorry for the code mess; I didn't plan to show this code to other people. <!-- 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
Please add A-const-generics, F-constevaluatablechecked, and F-const_generics labels
Maybe related to , but I had this ICE already all the way back in 04/06/2021. Back then the error was
Smaller repro of ICE:
confirming potentially predates 1.56 nightly
Change:
type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(core::([a-z_]+::)+)RefMut<.+>$" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(core::([a-z_]+::)+)RefCell<.+>$" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(core::([a-z_]+::)+)NonZero<.+>$" --category Rust <ins> type summary add -F lldb_lookup.summary_lookup  -e -x -h "^core::num::([a-z_]+::)*NonZero.+$" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(std::([a-z_]+::)+)PathBuf$" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^&(mut )?(std::([a-z_]+::)+)Path$" --category Rust </ins> type category enable Rust

Discussion:
I tried this code (as package ): Run the following, which will break at , step the next 4 lines () to define the variables, then print twice -- the first time will succeed, the second time will fail: I expected to see this happen: would work the same no matter how many times I called it, instead everything seems to be undefined after the first call. Below I show that seems to work (including multiple times), works (including multiple times), but after a single call to , neither of these works anymore: Oddly, if I break on filename / line number instead of function name, it seems to work as expected: I'm using from a git checkout from yesterday:
Realized was not a but an ; have changed to . Don't think it changes the rest, behavior still the same with .
Works just fine in gdb for me: Rust-lldb doesn't want to load for me at all, but plain lldb works fine too. For reference I'm using lldb version 14.0.6.
If only gdb worked on aarch64-darwin! But thanks for prompting me to try other OS -- I can confirm that I do not see the bug using rust-lldb on x86_64-linux, so this may be isolated to one of darwin / aarch64 / aarch64-darwin. (Still repros for me on aarch64-darwin with lldb 16.0.6.)

If is a PathBuf, printing it from lldb does not give a string representation as I would expect. If I explicitly refer to it shows "None" for the inner OsString: If I use I finally get a vec representation.
I've details in .
Visited during wg-debugging triage. We were not able to conclusively repro but we're confident this is probably still an issue. Triaging as P-medium for now.
Change:
fn fold_region(&mut self, r: ty::Region<'tcx>) -> ty::Region<'tcx> { #[cold] #[inline(never)] <del> fn region_param_out_of_range(data: ty::EarlyBoundRegion) -> ! { </del> <ins> fn region_param_out_of_range(data: ty::EarlyBoundRegion, substs: &[GenericArg<'_>]) -> ! { </ins> bug!( <del> "Region parameter out of range when substituting in region {} (index={})", </del> <ins> "Region parameter out of range when substituting in region {} (index={}, substs = {:?})", data.name, data.index, substs, ) } #[cold] #[inline(never)] fn region_param_invalid(data: ty::EarlyBoundRegion, other: GenericArgKind<'_>) -> ! { bug!( "Unexpected parameter {:?} when substituting in region {} (index={})", other, </ins> data.name, data.index )

Discussion:
While working on an experimental runtime and using a couple of experimental features I found that the compiler while in resolving the async call on a trait crash badly. This is a minimal reproducible example and this is the stacktrace generated N.B: I guess this happens with any runtime? BTW also if happens only with rio the compiler should not crash, but I do not think this is related to a specific runtime, but I guess instead, the runtime triggers the resolution of the futures <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-async-await +T-compiler
In the meanwhile, I will try to swim inside the codebase to catch the problem! claim
this is fixed by .
Minimized so it doesn't depend on rio:
Cool great work :)

gives happens with either rustc 1.66.0-dev () 66.0-nightly (2022-09-25 )
label +F-asyncfnin_traits
label +T-compiler +C-bug +I-ICE +requires-nightly Please use the ICE issue template for subsequent ICE issues. Thanks.
This is fixed by

I tried this code: I expected this to compile without error, since it is implementing the trait correctly. Instead, the following error was shown: It suggests replacing the code with the code I already have, which doesn't make much sense, as well as complaining that two things which appear identical are not. . : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +T-compiler +requires-nightly +F-returnpositionimpltraitin_trait +D-invalid-suggestion
claim
Change:
t!(fs::create_dir_all(&dir)); cargo.env("RUSTFMT_TEST_DIR", dir); <del> builder.add_rustc_lib_path(compiler, &mut cargo); </del> <ins> cargo.add_rustc_lib_path(builder, compiler); </ins> if try_run(builder, &mut cargo.into()) { builder.save_toolstate("rustfmt", ToolState::TestPass);

Discussion:
I tried to build rust right after got merged and caught error:
cc
What command did you run?
Change:
pub fn clear(&mut self) { self.vec.clear() } <ins> /// Create a draining iterator that removes the specified range in the string /// and yields the removed chars from start to end. The element range is /// removed even if the iterator is not consumed until the end. /// /// # Panics /// /// Panics if the starting point or end point are not on character boundaries, /// or if they are out of bounds. /// /// # Examples /// /// ``` /// # #![feature(collections_drain)] /// /// let mut s = String::from("α is alpha, β is beta"); /// let beta_offset = s.find('β').unwrap_or(s.len()); /// /// // Remove the range up until the β from the string /// let t: String = s.drain(..beta_offset).collect(); /// assert_eq!(t, "α is alpha, "); /// assert_eq!(s, "β is beta"); /// /// // A full range clears the string /// s.drain(..); /// assert_eq!(s, ""); /// ``` #[unstable(feature = "collections_drain", reason = "recently added, matches RFC")] pub fn drain<R>(&mut self, range: R) -> Drain where R: RangeArgument<usize> { // Memory safety // // The String version of Drain does not have the memory safety issues // of the vector version. The data is just plain bytes. // Because the range removal happens in Drop, if the Drain iterator is leaked, // the removal will not happen. let len = self.len(); let start = *range.start().unwrap_or(&0); let end = *range.end().unwrap_or(&len); // Take out two simultaneous borrows. The &mut String won't be accessed // until iteration is over, in Drop. let self_ptr = self as *mut _; // slicing does the appropriate bounds checks let chars_iter = self[start..end].chars(); Drain { start: start, end: end, iter: chars_iter, string: self_ptr, } } </ins> } impl FromUtf8Error {

Discussion:
cc
The rfc says It also includes an example which depends on usize: However RangeArgument only implements the first four. Furthermore as things stand it does not appear possible to accept RangeArgument<usizeand usize simultaneously, because dispatch doesn't consider the trait bound and reports that conflicting implementations exist.
Yes, was explicit about these issues. I forsee a new RFC to finish off drain and maybe the RangeArgument trait.
I believe this has
Change:
/// Checks that generic parameters are in the correct order, /// which is lifetimes, then types and then consts. (`<'a, T, const N: usize>`) <del> fn validate_generic_param_order<'a>( </del> <ins> fn validate_generic_param_order( </ins> sess: &Session, handler: &rustc_errors::Handler, <del> generics: impl Iterator<Item = (ParamKindOrd, Option<&'a [GenericBound]>, Span, Option<String>)>, </del> <ins> generics: &[GenericParam], </ins> span: Span, ) { let mut max_param: Option<ParamKindOrd> = None; let mut out_of_order = FxHashMap::default(); let mut param_idents = vec![]; <del> for (kind, bounds, span, ident) in generics { </del> <ins> for param in generics { let ident = Some(param.ident.to_string()); let (kind, bounds, span) = (&param.kind, Some(&*param.bounds), param.ident.span); let (ord_kind, ident) = match &param.kind { GenericParamKind::Lifetime => (ParamKindOrd::Lifetime, ident), GenericParamKind::Type { default: _ } => (ParamKindOrd::Type, ident), GenericParamKind::Const { ref ty, kw_span: _ } => { let ty = pprust::ty_to_string(ty); let unordered = sess.features_untracked().const_generics; (ParamKindOrd::Const { unordered }, Some(format!("const {}: {}", param.ident, ty))) } }; </ins> if let Some(ident) = ident { <del> param_idents.push((kind, bounds, param_idents.len(), ident)); </del> <ins> param_idents.push((kind, ord_kind, bounds, param_idents.len(), ident)); </ins> } let max_param = &mut max_param; match max_param { <del> Some(max_param) if *max_param > kind => { let entry = out_of_order.entry(kind).or_insert((*max_param, vec![])); </del> <ins> Some(max_param) if *max_param > ord_kind => { let entry = out_of_order.entry(ord_kind).or_insert((*max_param, vec![])); </ins> entry.1.push(span); } <del> Some(_) | None => *max_param = Some(kind), </del> <ins> Some(_) | None => *max_param = Some(ord_kind), </ins> }; } let mut ordered_params = "<".to_string(); if !out_of_order.is_empty() { <del> param_idents.sort_by_key(|&(po, _, i, _)| (po, i)); </del> <ins> param_idents.sort_by_key(|&(_, po, _, i, _)| (po, i)); </ins> let mut first = true; <del> for (_, bounds, _, ident) in param_idents { </del> <ins> for (kind, _, bounds, _, ident) in param_idents { </ins> if !first { ordered_params += ", "; }

Discussion:
results in: when it should be: This should be easy to fix: just replace in the following line with an appropriate format string. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
For the record, it's not quite this simple, as doing so results in incorrect output when the parameter also has bounds. For example, it would render as because bounds are printed after the
Change:
let src_bindir = builder .llvm_out(target) .join("bin"); <del> let dst_bindir = image.join("bin"); </del> <ins> let dst_bindir = image.join("lib/rustlib") .join(&*target) .join("bin"); </ins> t!(fs::create_dir_all(&dst_bindir)); for tool in LLVM_TOOLS { let exe = src_bindir.join(exe(tool, &target));

Discussion:
Short description: I am building for a environment using , and the embedded as my linker of choice. The linker fails to load since it depends on a dynamic library that doesn't actually exist. Rolling back to works
Searching the source tree for turns up some humorous comments...
I have this issue too!
I believe this issue is caused by : "Link LLVM tools dynamically...". It only enables dynamic linking on Linux and Mac OS, and since no Windows users complained so far I can only assume it's the probable cause. <hr/Speaking of which, it might be a good idea to add testing the built LLVM tools / LLD to Rust's CI, to ensure issues like this are caught earlier on.
this may have been caused by . Also, I don't see this issue on Linux:
I keep my toolchain updated with rustup, yet it seems I don't have ...? output:
it seems that is provided by the component which I have installed. Try running and see if that fixes LLD. it sounds like should always by shipped with the compiler since rust-lld depends on it.
I installed them, but it didn't help. The LLVM tools do seem to work, and I now have the library in the directory. However, checking rust-lld's RPATH shows , i.e. it points to . Doing does (temporarily) fix the problem.
I'm working on a fix for this!
diagnosis is spot on and this should be fixed in To recap, interim fixes include: Downgrading to an older nightly temporarily
Thanks,
Doesn't work for me on macOS by the way.
Edit I was wrong. It's still nightly I get this with stable rust too (1.28.0):
only just had all of the features it relies on stabilize, so it is still nightly-only until those newly-stabilized features ride the release trains from nightly -beta -stable.
thanks for pointing out. I just noticed that it is using nightly version. I am new to rust, so I have no idea how to rollback to previous nightly version to use as a workaround.
For future reference, you can use rustup to install any nightly, for instructions see .
Still getting this issue on the latest nightly:
It seems to work fine for me (on arch linux)
I agree with It is still not working on macOS.

Seems like a number of people (including myself) are still having this issue, can we re-open?
Apparently did not fix this entirely on Mac OS X.
I'm working on a fix for this and should be able to post it soon
I'm getting this on Linux too: https://travis-
Thanks for your super-fast help,
For anyone wondering, the osx fix is not on the current nightly – – yet.
Why's this issue closed then?
Is it because the fix will be in tomorrow's nightly build?
Yes this fix missed last night's nightly but it should be in tonight's nightly!
I'm still getting this error with .
Looks like there's at least one more bug to fix --
Finally, I managed to compile on a mac with the latest nightly build of rust!