jiebi/CodeConvo huggingface dataset:
Change:
Err(m) => m, }; <del> builder.update_submodule(&Path::new("src").join("llvm-project")); </del> if builder.llvm_link_shared() && target.is_windows() { panic!("shared linking to LLVM is not currently supported on {}", target.triple); }

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. --I tried this code: in is not specified explicitly, the default value is used. I expected to see this happen: LLVM is downloaded from CI, when LLVM version is bumped the new LLVM is downloaded from CI as well. Instead, this happened: LLVM starts building from source code after an LLVM update, instead of being downloaded, unless I remove the build directory and do a fresh build, then it starts downloading from CI again. <!-- 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. --:
Or maybe it's a stage0 toolchain update that triggers this issue, not LLVM update (I observed this today). But I've seen this issue several times in the past as well. cc
The section in is completely empty, nothing is overridden.
Update: LLVM is built from source only on the first build attempt, after that it is correctly downloaded from CI.
This is still an issue that I observe regularly.
There were some issues with the change detection logic for LLVM and I think should fix it. Let's see if it still happens with the next LLVM update.
Change:
// Check that the bottom-most item on the sidebar menu can be scrolled fully into view. click: ".sidebar-menu-toggle" scroll-to: ".block.keyword li:nth-child(1)" <del> assert-position: (".block.keyword li:nth-child(1)", {"y": 542.96875}) </del> <ins> assert-position: (".block.keyword li:nth-child(1)", {"y": 542.234375}) </ins>

Discussion:
In rustdoc sidebars, most headings are clickable links. For instance, "Required Methods" and "Implementors" in the sidebar of However, the headings under "Other items in..." are not clickable. We should link those to the appropriate subheading on the module page. That allows the user to see a more verbose listing of items in the module, since each one has a description alongside it. <img width=150 src="https://user-"<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
So, for instance, sidebar heading should lead ?
claim
Yes, that's correct.
By the way be aware this will conflict with Resolving the conflict should be pretty easy though.
Thanks
any progress on this? I'd like to get it landed before the beta cut, so we have a consistent UI where headings in the sidebar are clickable.
sorry, i couldn't make time last ,i will unassign me, thanks.
Change:
); } <ins> if let hir::ExprKind::Path(hir::QPath::Resolved(None, path)) = callee_expr.kind && let Res::Local(_) = path.res && let [segment] = &path.segments[..] { for id in self.tcx.hir().items() { if let Some(node) = self.tcx.hir().get_if_local(id.owner_id.into()) && let hir::Node::Item(item) = node && let hir::ItemKind::Fn(..) = item.kind && item.ident.name == segment.ident.name { err.span_label( self.tcx.def_span(id.owner_id), "this function of the same name is available here, but it's shadowed by  the local binding", ); } } } </ins> let mut inner_callee_path = None; let def = match callee_expr.kind { hir::ExprKind::Path(ref qpath) => {

Discussion:
code: This causes a very confusing error message First, the message talks about "enum variant", does it mean ? Second, I don't get why it does not compile anyway. If I rename it builds, but why can't it figure out that that a var and function are different things even if they have the same name? Fun fact: this doesn't build either but this does: Shouldn't the 2 snippets behave identical?
They are not because on the second case the local binding doesn't exist yet, so the mod level function is not yet shadowed. In the other case, the function has been shadowed by the local binding, so it fails to compile. No, it's just confused thinking that is . The error message should mention the shadowing of the function.
Just ran into this again with a more simple case :( IMO this should compile because we know that is of type and not so querying the variable is the only thing that makes sense here..? The error message is not really helping imo I wonder if type ascription could solve this:
Change:
#[doc(hidden)] #[unstable(feature = "thread_local_internals", issue = "none")] pub mod local_impl { <del> pub use crate::sys::common::thread_local::{thread_local_inner, Key}; </del> <ins> pub use crate::sys::common::thread_local::{thread_local_inner, Key, abort_on_dtor_unwind}; </ins> } } }

Discussion:
Miri detects UB when running the following program: With and With
I see the bug. We have (which means fns in std automatically trap aborts) but that doesn't apply to functions which are present in the macro expansion (some of which can't really be moved outside the macro). Ill fix in like an hour or two. We just need to guard panics in a couple places. In practice I think this should not call problems and we'd just hit an abort guard in an defined in a few frames up, although perhaps that's not true in 100% of cases (I can update on this once I implement the fix).
The is that the fix to this may need to be backported thus I am tagging this with P-high.
the fix was merged and a backport was rejected:
Change:
borrow_region: RegionVid, outlived_region: RegionVid, ) -> (ConstraintCategory, bool, Span, Option<RegionName>) { <del> let (category, from_closure, span) = self.best_blame_constraint(mir, borrow_region, |r| r == outlived_region); </del> <ins> let (category, from_closure, span) = self.best_blame_constraint( mir, borrow_region, |r| self.provides_universal_region(r, borrow_region, outlived_region) ); </ins> let outlived_fr_name = self.give_region_a_name(infcx, mir, upvars, mir_def_id, outlived_region, &mut 1); (category, from_closure, span, outlived_fr_name)

Discussion:
While I was trying to make a general impl, I came across this ICE. Note that inlining makes this ICE go away.
thanks for putting the stack-trace, I forgot about that This also works
Small repro: I'll try to have a PR up for this next week.
Another repro from
Change:
#[unstable(feature = "step_trait", reason = "recently redesigned", issue = "42168")] impl Step for $u_narrower { step_identical_methods!(); <ins> step_unsigned_methods!(); </ins> #[inline] fn steps_between(start: &Self, end: &Self) -> Option<usize> {

Discussion:
I tried this code: I expected to see this happen: No UB. Instead, this happened: UB, confirmed by Miri. is called, which does , or . The implementation of is correct here, and should be safe to call. The implementation that does a wrapping cast from to before doing the unchecked math is the incorrect code here. Signed integers should switch to just using wrapping or unsigned math, whichever gets better codegen out of LLVM. We do have and methods now, but no . <!-- 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. --:
Note that this is reachable on stable since the default impl of uses and not all adapters forward both.
did you find this with Miri or just use Miri to confirm the bug? (I'm asking because I may want to add this to our "bugs found by Miri" list :)
Only confirmed/diagnosed with Miri, spotted manually when looking at the code.
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. #![feature(phase)] #[phase(plugin)] extern crate green; extern crate native; use native::NativeTaskBuilder; use std::io::{process, Command}; use std::os; use std::task::TaskBuilder; green_start!(main) fn main() { let len = os::args().len(); if len == 1 { test(); let (tx, rx) = channel(); TaskBuilder::new().native().spawn(proc() { tx.send(test()); }); rx.recv(); } else { assert_eq!(len, 3); } } fn test() { let status = Command::new(os::self_exe_name().unwrap()) .arg("foo").arg("") .stdout(process::InheritFd(1)) .stderr(process::InheritFd(2)) .status().unwrap(); assert!(status.success()); } </ins>

Discussion:
For example, this program prints on unix, and on windows:
The appears to be different on windows for both libgreen and libnative.
I believe this happens because the arguments end up being quoted for Windows. Simplest fix would be to drop empty arguments. Thoughts?
(Alternatively, we could quote empty arguments on Unix.)
I would expect the empty arguments to be passed through as significant argument position. I ran into this in cargo because passed on unix but on windows it would try to consume the next argument for the test args. It looks like to fix this we just need to alter to see if the argument is 0-length, and if so we quote it. Libuv already does . I'm investigating a fix for libgreen, it looks like it should be working...
Change:
use std::str; pub const MAX_BASE: u64 = 64; <ins> pub const ALPHANUMERIC_ONLY: u64 = 62; </ins> const BASE_64: &'static [u8; MAX_BASE as usize] = b"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@$";

Discussion:
So I tried to compile core and I get this errors from assembler: the code on line 9468 looks like this: I tried both (4.6.3) and (5.3.0) and both give the same errors. Then I've renamed symbol to in assembly and it compiled successfully. I think msp430 assembler just does not like character in symbol names. So I see 2 options: MSP430 target in LLVM so it will rename symbols with  to not emit on MSP430
Change:
<ins> // Regression test for #82612. use std::marker::PhantomData; pub trait SparseSetIndex { fn sparse_set_index(&self) -> usize; } pub struct SparseArray<I, V = I> { values: Vec<Option<V>>, marker: PhantomData<I>, } impl<I: SparseSetIndex, V> SparseArray<I, V> { pub fn get_or_insert_with(&mut self, index: I, func: impl FnOnce() -> V) -> &mut V { let index = index.sparse_set_index(); if index < self.values.len() { let value = unsafe { self.values.get_unchecked_mut(index) }; value.get_or_insert_with(func) //~ ERROR mismatched types } unsafe { self.values.get_unchecked_mut(index).as_mut().unwrap() } } } fn main() {} </ins>

Discussion:
While writing a SparseArray impl, I forgot a return on . This should_ be an error, but I got an ice instead. This fails with the expected on stable. playground: (Note that switching to stable resolves the ICE) <!-- 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. --:
label regression-from-stable-to-nightly
Bisection result searched nightlies: from nightly-2021-02-22 to nightly-2021-02-28 regressed nightly: nightly-2021-02-24 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Caused by :
Change:
<ins> error: expected one of `!` or `::`, found `foo` --> $DIR/fn-defined-using-func.rs:6:6 | LL | func foo() {} | ---- ^^^ expected one of `!` or `::` | | | help: write `fn` instead of `func` to declare a function error: aborting due to previous error </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: <!-- Please provide a link to --The current output is: Ideally the error message should suggest replacing or with . <!-- 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
New to rustc community and wants to contribute code. there any options to debug rustc which line of which file the error abort happens? can I dump the hierarchy tree for debugging use? C++ we usually use env for compiler debugging. How do rustc often use? Very newbie questions, thank you in advance.
label +E-easy +E-mentor Welcome to Rust! This might be some help -- This issue is very similar to , so take a peek at the diff there. IMO the following tokens are enough to check against function (Julia/JavaScript/etc) func (Go) fun (Kotlin) def (Python) Have fun! <3
Instructions -- Add a check if prevtoken is either ///etc Emit a message, something along the lines of "use instead of <prevtokento make a function" using , there are a few usages of this in the same file so those might be good examples. Add tests for this in -- Ideally each suggestion would have a test. Should be helpful to take as a reference
We can include if necessary.
Hi guys, another rust newbie looking for something easy to get started here. are you still on this or could go with my attempt here?

ypprog does seem to be active and it hasn't been that long, if you'd like you can pick another issue. =) Try going through the E-Easy and/or E-Mentor category for easy issues. However, to clarify, if an issue which is claimed doesn't seem to have any work done for a long period of time (A month or so is a good amount of time) -- Feel free to ping the assignee to confirm and handle it accordingly.
With these changes, I also think it is important to implement improved error messages for when a user puts the return type at the start of the function instead of the end. Given this code: The error output is:
I feel like adding might also be helpful for C++ developers :)
Is this still being worked on?
release-assignment
claim
Change:
if let Some(entry_idx) = vptr_entry_idx { let ptr_size = bx.data_layout().pointer_size; <del> let ptr_align = bx.data_layout().pointer_align.abi; </del> let vtable_byte_offset = u64::try_from(entry_idx).unwrap() * ptr_size.bytes(); <del> let gep = bx.inbounds_ptradd(old_info, bx.const_usize(vtable_byte_offset)); let new_vptr = bx.load(bx.type_ptr(), gep, ptr_align); bx.nonnull_metadata(new_vptr); // VTable loads are invariant. bx.set_invariant_load(new_vptr); new_vptr </del> <ins> load_vtable(bx, old_info, bx.type_ptr(), vtable_byte_offset, source, true) </ins> } else { old_info }

Discussion:
<!-- [31mICE[0m: Rustc ./subtyping-impacts-selection-2.rs '-Zvirtual-function-elimination=true -Clto=true -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'expected principal trait object'', 'thread 'rustc' panicked at 'expected principal trait object'' File: /tmp/im/subtyping-impacts-selection-2.rs --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: --
Seems to be a duplicate of
Regression in nightly-2022-06-16 commit[0] 2022-06-14: Auto merge of - b-naber:transition-to-valtrees-in-type-system, r=lcnr commit[1] 2022-06-14: Auto merge of - flip1995:pk-vfe, r=nagisa commit[2] 2022-06-15: Auto merge of - compiler-errors:if-cond-and-block, r=oli-obk commit[3] 2022-06-15: Auto merge of - JohnTitor:rollup-rfg1a4s, r=JohnTitor commit[4] 2022-06-15: Auto merge of - nnethercote:rm-thread-local-IGNORED_ATTRIBUTES, r=michaelwoerister commit[5] 2022-06-15: Auto merge of - JohnTitor:rollup-c17vjdy, r=JohnTitor commit[6] 2022-06-15: Auto merge of - AzureMarker:feature/horizon-std, r=nagisa commit[7] 2022-06-15: Auto merge of - c410-f3r:assert-compiler, r=oli-obk commit[8] 2022-06-15: Auto merge of - sunfishcode:ownedfd-and-dup, r=joshtriplett looks like this has been broken eversince

This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:
Change:
if let Some(idx) = param.idx.checked_sub(self.parent_count() as u32) { // non-Self type parameters are always offset by exactly // `self.regions.len()`. In the absence of a Self, this is obvious, <del> // but even in the absence of a `Self` we just have to "compensate" </del> <ins> // but even in the presence of a `Self` we just have to "compensate" </ins> // for the regions: // <del> // For example, for `trait Foo<'a, 'b, T1, T2>`, the </del> <ins> // Without a `Self` (or in a nested generics that doesn't have // a `Self` in itself, even through it parent does), for example // for `fn foo<'a, T1, T2>()`, the situation is: //     Substs: //         0  1  2 //         'a T1 T2 //     generics.types: //         0  1 //         T1 T2 // // And with a `Self`, for example for `trait Foo<'a, 'b, T1, T2>`, the </ins> // situation is: //     Substs: //         0   1  2  3  4

Discussion:
When using to build one of my projects, I got the error I tried to minimize my code and got to . : with the command I got the error : : backtrace :
I can reproduce this with:
Change:
use crate::cell::Cell; use crate::fmt; use crate::marker; <ins> use crate::panic::{RefUnwindSafe, UnwindSafe}; </ins> use crate::sync::atomic::{AtomicBool, AtomicUsize, Ordering}; use crate::thread::{self, Thread};

Discussion:
Currently, the following program because isn't . Is this the desired behavior, or should we consider making it or ? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It also won't compile because ?
Ah, right you are. :
does not require anymore (tested with rustc 1.55.0). The original issue is still valid. Since poisons itself on panic, it should be considered unwind safe.
We discussed this very briefly in the libs api meeting. It seems fine to add this impl.
claim Going to take a stab at this one.
Change:
endif CFG_LIB_NAME_armv7s-apple-ios = lib$(1).a CFG_LIB_GLOB_armv7s-apple-ios = lib$(1)-*.a <del> CFG_LIB_SKIP_INSTALL_armv7s-apple-ios = 1 #lib$(1)-*.a </del> <ins> CFG_INSTALL_ONLY_RLIB_armv7s-apple-ios = 1 </ins> CFG_STATIC_LIB_NAME_armv7s-apple-ios=lib$(1).a CFG_LIB_DSYM_GLOB_armv7s-apple-ios = lib$(1)-*.a.dSYM CFG_JEMALLOC_CFLAGS_armv7s-apple-ios := -arch armv7s -mfpu=vfp4 $(CFG_IOS_SDK_FLAGS_armv7s-apple-ios)

Discussion:
Full gist:
cc
cc since you've been contributing iOS patches. This same error still repros after with: Are you able to successfully build a cross-compiler?
there are 2 different things: building and installing. What fails is phase and I believe I have kind of dirty hack for it in my fork, but will try to find a correct solution and issue PR soon.
this one ?
yep
cool, would you mind submitting that PR?
since PR is going to be open for a while considering current bors queue, I have to mention that in general when you need up-to-date Rust for iOS you can either built it by yourself from or use a prebuilt version from It may lag a bit (usually <= 1 day) but it is guaranteed to build (as iOS is not on Rust official buildbots and master is broken sometimes).
Change:
<ins> // Copyright 2015 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. #[derive(Debug)] struct Matrix4<S>(S); trait POrd<S> {} fn translate<S: POrd<S>>(s: S) -> Matrix4<S> { Matrix4(s) } impl POrd<f32> for f32 {} impl POrd<f64> for f64 {} fn main() { let x = 1.0; let m : Matrix4<f32> = translate(x); println!("m: {:?}", m); } </ins>

Discussion:
I don't exactly know what terminology to use to describe this bug; feel free to update the title to reflect reality... This was something I encountered while using bjz's ; this test is derived from that library (but independent of it). Transcript of compilation attempt: we would actually manage to properly assign to the type of , since I do not see any reason for the generic float type to be constrained to . (Note that if you add a type annotation to the then compilation terminates successfully.) even if we cannot accomplish that goal for some hypothetical reason, we still need to a better job with the error message here. Note also that the is necessary to reproduce the poor-quality error message given here. If you remove it, you get this instead: (which also is not great, but at least then I have a hint that my problem originates with some use of a generic float literal somewhere in my code.
Inference is totally different now, does this issue still persist, ?
The following compiles successfully now:
Change:
let arg = self.param_env.and(arg); self.tcx.try_normalize_generic_arg_after_erasing_regions(arg).unwrap_or_else(|_| bug!( <del> "Failed to normalize {:?}, maybe try to call `try_normalize_erasing_regions` instead", arg.value )) </del> <ins> "Failed to normalize {:?}, maybe try to call `try_normalize_erasing_regions` instead", arg.value )) </ins> } }

Discussion:
https://crater-
searched nightlies: from nightly-2023-01-24 to nightly-2023-03-30 regressed nightly: nightly-2023-02-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: </detailsThis looks related to , but wasn't fixed by
Let's notify the people involved in that bisection, it's cc author and reviewer A minimization would be helpful.
probably just allowed another existing bug to show up, like the other projection issues. I've reduced the regression to this it still depends on , if anyone has the time to also remove that.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This seems to have disappeared in nightly. Bisect points to Maybe fixed by
Wasn't that PR already present in your previous bisection up to nightly-2023-03-30 ?
Ah, looks like the is fixed in , but not the .
label -E-needs-mcve +S-has-mcve
Change:
<ins> // revisions: with_gate no_gate #![cfg_attr(with_gate, feature(inherent_associated_types))] #![cfg_attr(with_gate, allow(incomplete_features))] struct Windows<T> {} impl<T> Windows { //~ ERROR: missing generics for struct `Windows` type Item = &[T]; //~ ERROR: `&` without an explicit lifetime name cannot be used here //[no_gate]~^ ERROR: inherent associated types are unstable fn next() -> Option<Self::Item> {} } impl<T> Windows<T> { fn T() -> Option<Self::Item> {} } fn main() {} </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
Minimized with : label +S-bug-has-mcve
searched toolchains through Regression in
Alternative: Would the error change if the compiler is built with ?
Triage: This is no longer ICE since today's nightly, I assume fixed it. Marking as E-needs-test just in case regression tests there didn't cover this case. labels: +E-needs-test