jiebi/CodeConvo huggingface dataset:
Change:
return s } <del> fn blank<'a>(s: Option<&'a str>) -> &'a str { match s { Some(s) => s, None => "" } } </del> fn shorter<'a>(s: Option<&'a str>) -> &'a str { match s { Some(s) => match s.find_str("nn") {

Discussion:
Here's what I think is wrong: keywords , and appear next to the name of the constant, when clearly they are redundant. the constants page through search brings the user to an empty page. value assigned to the constant appears along side its name. When reading the documentation of constants, the most important information is the name of the constant and its description. Having the declaration appear inline makes scanning for the name of harder. Better output would replace the declaration with the name of the constant followed by its type. Also it would move the declaration of the constant to the empty page mentioned in point 2 and have the identifier of the constant link to this page. All these points are relevant for statics as well. Example of ugly output: ! This page should show the definition and a description of the constant: !
Change:
#[inline] #[$stable_access] pub fn into_inner(self) -> $int_type { <del> unsafe { self.v.into_inner() } </del> <ins> self.v.into_inner() </ins> } /// Loads a value from the atomic integer.

Discussion:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.
Change:
Use(Operand<'tcx>), // [x; 32] <del> Repeat(Operand<'tcx>, Constant<'tcx>), </del> <ins> Repeat(Operand<'tcx>, TypedConstVal<'tcx>), </ins> // &x or &mut x Ref(Region, BorrowKind, Lvalue<'tcx>),

Discussion:
See and relevant FIXME in
As a side-note, would solve this problem quite neatly, if we were to adopt and implement it. :)
Change:
let v = f; //~ ERROR `f` is ambiguous match v { f => {} //~ ERROR `f` is ambiguous <ins> mut f => {} // OK, unambiguously a fresh binding due to `mut` </ins> } }

Discussion:
For example: https://crater- https://crater- cc
This is a regression from produced an ambiguity error even if the binding is syntactically unambiguous (e.g. like in the example above) for some future-compatibility reasons (), but it can be easily tweaked to not produce it because backward-compatibility is more important.
Fixed in
Change:
/// ``` #[stable(feature = "slice_sort_by_key", since = "1.7.0")] #[inline] <del> pub fn sort_by_key<B, F>(&mut self, mut f: F) where F: FnMut(&T) -> B, B: Ord </del> <ins> pub fn sort_by_key<K, F>(&mut self, mut f: F) where F: FnMut(&T) -> K, K: Ord </ins> { merge_sort(self, |a, b| f(a).lt(&f(b))); } <ins> /// Sorts the slice with a key extraction function. /// /// During sorting, the key function is called only once per element. /// /// This sort is stable (i.e. does not reorder equal elements) and `O(m n + n log n)` /// worst-case, where the key function is `O(m)`. /// /// For simple key functions (e.g. functions that are property accesses or /// basic operations), [`sort_by_key`](#method.sort_by_key) is likely to be /// faster. /// /// # Current implementation /// /// The current algorithm is based on [pattern-defeating quicksort][pdqsort] by Orson Peters, /// which combines the fast average case of randomized quicksort with the fast worst case of /// heapsort, while achieving linear time on slices with certain patterns. It uses some /// randomization to avoid degenerate cases, but with a fixed seed to always provide /// deterministic behavior. /// /// In the worst case, the algorithm allocates temporary storage in a `Vec<(K, usize)>` the /// length of the slice. /// /// # Examples /// /// ``` /// let mut v = [-5i32, 4, 32, -3, 2]; /// /// v.sort_by_cached_key(|k| k.to_string()); /// assert!(v == [-3, -5, 2, 32, 4]); /// ``` /// /// [pdqsort]: https://github.com/orlp/pdqsort #[unstable(feature = "slice_sort_by_cached_key", issue = "34447")] #[inline] pub fn sort_by_cached_key<K, F>(&mut self, f: F) where F: FnMut(&T) -> K, K: Ord { // Helper macro for indexing our vector by the smallest possible type, to reduce allocation. macro_rules! sort_by_key { ($t:ty, $slice:ident, $f:ident) => ({ let mut indices: Vec<_> = $slice.iter().map($f).enumerate().map(|(i, k)| (k, i as $t)).collect(); // The elements of `indices` are unique, as they are indexed, so any sort will be // stable with respect to the original slice. We use `sort_unstable` here because it // requires less memory allocation. indices.sort_unstable(); for i in 0..$slice.len() { let mut index = indices[i].1; while (index as usize) < i { index = indices[index as usize].1; } indices[i].1 = index; $slice.swap(i, index as usize); } }) } let len = self.len(); if len <= ( u8::MAX as usize) { return sort_by_key!( u8, self, f) } if len <= (u16::MAX as usize) { return sort_by_key!(u16, self, f) } if len <= (u32::MAX as usize) { return sort_by_key!(u32, self, f) } sort_by_key!(usize, self, f) } </ins> /// Sorts the slice, but may not preserve the order of equal elements. /// /// This sort is unstable (i.e. may reorder equal elements), in-place (i.e. does not allocate),

Discussion:
Where we would normally put "^^^ did you mean Up" under mistyped names, I noticed that we don't do that for enum variants. Here's an example I just saw: !
Taking a look.
Change:
"/src/tools/tidy" =                                      ["bootstrap"] "/src/tools/x" =                                         ["bootstrap"] "/src/tools/rustdoc-gui-test" =                          ["bootstrap", "@onur-ozkan"] <ins> "/src/tools/libcxx-version" =                            ["@onur-ozkan"] </ins> # Enable tracking of PR review assignment # Documentation at: https://forge.rust-lang.org/triagebot/pr-assignment-tracking.html

Discussion:
Spawned off of I'm not 100% sure what would be involved in such a check here, but it seems like a good thing to investigate, because the nature of the resulting bootstrap failures is super frustrating. (I'll admit, I don't know if the right thing would be to hard error out of all uses of download-ci-llvm for potentially-incompatible libstdc++, or only to hard error out for defaulting uses... but a warning seems warranted in any such cases.
I guess the problem here is that we're compiling the locally and linking that against the downloaded toolchain. A check like suggested here makes sense to me in the meantime, but I suppose long-term the "right" fix here is to get rid of any C++ code we need to separately compile by upstreaming C bindings into LLVM proper, and then we can just call those on the Rust side without any ABI issues. (FWIW, I was initially confused since we explicitly statically link in the stdcpp in the distributed I guess maybe we could also fix this by skipping linking to a local stdcpp while compiling the Rust wrapper code? Not sure if that works out.)
This is the particular line which leads to failure with download-ci-llvm when there is an ABI mismatch. In my experiment removing it resulted in linking errors on rustcdriver. I agree, this solves the problem completely without applying hacks (in my opinion, there is no simple or clean way of comparing ABI or libstd versions) on bootstrap. Maybe, for now, we should just print a warning when downloading ci llvm?
You mean always print a warning? I don't think that's a good idea, it's noisy and we generally expect that people are happy using download CI LLVM. I don't think a warning is helpful here if we can't scope it down to where it matters (in which case it can probably be an error).
Not always, only once while downloading it.
I think that falls in the same "not particularly helpful" case. Most users will miss the message, and even if they don't it's not clear how they should respond. I at least don't know how to check whether my machine has everything setup right. If we could check then we could limit the warning, in which case I'm broadly in favor of making it perhaps even a hard error.
Change:
let unaligned_offset = bx.cx().const_usize(offset.bytes()); // Get the alignment of the field <del> let (_, unsized_align) = glue::size_and_align_of_dst(bx, field.ty, meta); </del> <ins> let (_, mut unsized_align) = glue::size_and_align_of_dst(bx, field.ty, meta); // For packed types, we need to cap alignment. if let ty::Adt(def, _) = self.layout.ty.kind() && let Some(packed) = def.repr().pack { let packed = bx.const_usize(packed.bytes()); let cmp = bx.icmp(IntPredicate::IntULT, unsized_align, packed); unsized_align = bx.select(cmp, unsized_align, packed) } </ins> // Bump the unaligned offset up to the appropriate alignment let offset = round_up_const_value_to_alignment(bx, unaligned_offset, unsized_align);

Discussion:
This code panics, but it should not: The panic disappears when the is inlined (because then we hit a different code path in ). What happens here is a bug in the logic that computes the offset of : since it is an unsized field, the offset is computed dynamically, by taking the statically known offset and then rounding it up to the dynamic alignment of the field. However, since the struct is packed, we need to cap the dynamic alignment of the field to the packing of the surrounding struct -- which we currently do not do. This is just yet another case where the non-compositional nature of is causing issues...
A slight variant of this code ICEs: It hits which, it seems, was never updated when support for was implemented.
WG-prioritization assigning priority (). label -I-prioritize +P-medium EDIT: lowered priority after discussion on Zulip
Change:
<ins> #![feature(generic_associated_types)] #![feature(type_alias_impl_trait)] fn main() {} trait A<'a> { type B<'b>: Clone // FIXME(generic_associated_types): Remove one of the below bounds // https://github.com/rust-lang/rust/pull/90678#discussion_r744976085 where 'a: 'b, Self: 'a, Self: 'b; fn a(&'a self) -> Self::B<'a>; } struct C; impl<'a> A<'a> for C { type B<'b> = impl Clone; //~^ ERROR: lifetime bound not satisfied //~| ERROR: could not find defining uses fn a(&'a self) -> Self::B<'a> {} //~ ERROR: non-defining opaque type use in defining scope } </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. --: <details<summary<strongBacktrace</strong</summary<p(F# highlighting looks reasonably nice) </p</details
modify labels +requires-nightly +F-genericassociatedtypes +F-typealiasimpl_trait
GATs issue triage: not blocking. Works on latest nightly; needs test.
label: +E-needs-test
Change:
// the meta-var. let ident = MacroRulesNormalizedIdent::new(orignal_ident); if let Some(cur_matched) = lookup_cur_matched(ident, interp, &repeats) { <del> if let MatchedNonterminal(ref nt) = cur_matched { // FIXME #2887: why do we apply a mark when matching a token tree meta-var // (e.g. `$x:tt`), but not when we are matching any other type of token // tree? if let NtTT(ref tt) = **nt { result.push(tt.clone().into()); </del> <ins> if let MatchedNonterminal(nt) = cur_matched { let token = if let NtTT(tt) = &**nt { // `tt`s are emitted into the output stream directly as "raw tokens", // without wrapping them into groups. tt.clone() </ins> } else { <ins> // Other variables are emitted into the output stream as groups with // `Delimiter::None` to maintain parsing priorities. // `Interpolated` is currenty used for such groups in rustc parser. </ins> marker.visit_span(&mut sp); <del> let token = TokenTree::token(token::Interpolated(nt.clone()), sp); result.push(token.into()); } </del> <ins> TokenTree::token(token::Interpolated(nt.clone()), sp) }; result.push(token.into()); </ins> } else { // We were unable to descend far enough. This is an error. return Err(cx.struct_span_err(

Discussion:
Several FIXMEs (formerly TODOs) there that mention using the correct spans for different errors.
Not critical for 0.6; de-milestoning
FIXMEs are still there. I'm not sure if this should be nominated for a maturity milestone, but if it's something that will trip people up, production ready is probably appropriate.
Nominating for Milestone 5: Production Ready.
accepted for production-ready milestone
visiting for triage, email from 2013 sep 16
Accepting for P-low
Triage: no change
Is this still an issue?
yes
Did address this? The description of that PR mentions that it partially addressed this, but I don't know to what extent.
cc but I don't think this issue is entirely fixed, we still use some bad spans, that PR just fixed one case of them.
You've done a lot of work on this file recently, perhaps you could comment if there's still more to be done with the spans? is the file for reference.
I'm not familiar with the details off the top of my head, but IIRC there are comments about spans that could use improvements in the file.
That memory was correct; there are many FIXME comments in the file.
There are now four FIXMEs in that file. No idea if that's few enough for this ticket or not.
If is correct and gets merged, we would be down to just one FIXME and it is about hygiene. Specifically, when transcribing a MBE, when we replace a meta-variable with a matched nonterminal, currently: If the meta-variable was a , we don't do anything to the syntax context of token trees (). If the meta-variable is any other type of nonterminal, we apply the mark of the current expansion to the span of the nonterminal. Why the distinction? cc
Why the distinction? has an answer for this question.
Change:
return; } _ => { <del> struct_span_err!(self.tcx.sess, item.span, E0118, </del> <ins> struct_span_err!(self.tcx.sess, ty.span, E0118, </ins> "no base type found for inherent implementation") <del> .span_help(item.span, "either implement a trait on it or create a newtype to wrap it  instead") </del> <ins> .span_label(ty.span, &format!("impl requires a base type")) .note(&format!("either implement a trait on it or create a newtype  to wrap it instead")) </ins> .emit(); return; }

Discussion:
From: src/test/compile- Error E0118 needs a spanlabel and a spannote to be a simple note, updating from: To: Bonus: It'd be good if we could underline the type it's complaining about.
In case no one is working with this yet, I can give this a go.

From: src/test/compile- Error E0117 needs a span_label, updated error text, and a note, updating it from: to:
In case no one is working with this yet, I can give this a go.
Change:
endif CFG_LIB_NAME_aarch64-apple-ios = lib$(1).a CFG_LIB_GLOB_aarch64-apple-ios = lib$(1)-*.a <del> CFG_LIB_SKIP_INSTALL_aarch64-apple-ios = 1 #lib$(1)-*.a </del> <ins> CFG_INSTALL_ONLY_RLIB_aarch64-apple-ios = 1 </ins> CFG_STATIC_LIB_NAME_aarch64-apple-ios=lib$(1).a CFG_LIB_DSYM_GLOB_aarch64-apple-ios = lib$(1)-*.a.dSYM CFG_CFLAGS_aarch64-apple-ios := $(CFG_IOS_SDK_FLAGS_aarch64-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:
} function startSearch() { <ins> $(".search-input").on("keyup",function() { if ($(this).val().length === 0) { window.history.replaceState("", "std - Rust", "?search="); $('#main.content').removeClass('hidden'); $('#search.content').addClass('hidden'); } }); </ins> var keyUpTimeout; $('.do-search').on('click', search); $('.search-input').on('keyup', function() {

Discussion:
When you search for something on the online docs (which I assume are generated using cargo doc) a list of results comes up. When you clear the search bar/press the X button it probably should clear the results to allow you to view the original page. Anyone know how to fix this?
I don't believe that we have anything set up for that. Is there an "X" button? I don't see it anywhere. Regardless, clearing the box or pressing escape or something should probably clear it, for sure.
! And then after clicking the "X": !
Search field is and therefore it might have various user agent specific functionality. Simpler way to reproduce in a cross-UA way would be to follow these steps: a search query; the whole query at once by highlighting it and clicking backspace, delete or any other relevant button; Result list not changing. We could go back to the page that was open before the search field was used to fix this. Note that we do know what page it was, because we simply append to the URI of the page we start the search at.
I took a shot at it and in the half an hour I dedicated to it, all I found that search code is a complete mess and this might be harder to fix correctly than it might appear at a first glance.
Change:
pub fn read(&self, buf: &mut [u8]) -> io::Result<usize> { // On unix when a socket is shut down all further reads return 0, so we // do the same on windows to map a shut down socket to returning EOF. <ins> let len = cmp::min(buf.len(), i32::max_value() as usize) as i32; </ins> unsafe { <del> match c::recv(self.0, buf.as_mut_ptr() as *mut c_void, buf.len() as i32, 0) { </del> <ins> match c::recv(self.0, buf.as_mut_ptr() as *mut c_void, len, 0) { </ins> -1 if c::WSAGetLastError() == c::WSAESHUTDOWN => Ok(0), -1 => Err(last_error()), n => Ok(n as usize)

Discussion:
In a few places in there are casts from to or for Windows APIs which causes breakage on 64-bit. Some examples I have found so far: () () (rust-lang-nursery/rand, ) There may be more.
Well I didn't find any more so I'll close this.
Change:
match (cast_ty_from, cast_ty_to) { (Some(CastTy::Ptr(src)), Some(CastTy::Ptr(dst))) => { let mut normalize = |t| self.normalize(t, location); <ins> // N.B. `struct_tail_with_normalize` only "structurally resolves" // the type. It is not fully normalized, so we have to normalize it // afterwards. </ins> let src_tail = tcx.struct_tail_with_normalize(src.ty, &mut normalize, || ()); <ins> let src_tail = normalize(src_tail); </ins> let dst_tail = tcx.struct_tail_with_normalize(dst.ty, &mut normalize, || ()); <ins> let dst_tail = normalize(dst_tail); </ins> // This checks (lifetime part of) vtable validity for pointer casts, // which is irrelevant when there are aren't principal traits on both sides (aka only auto traits).

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'called on an value: NoSolution'', 'thread 'rustc' panicked at 'called on an value: NoSolution'' 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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate -- label +F-ptrmetadata
bisects to :thinking: cc
Minimized: This compiles on stable. ICEs on beta. <details<summaryError output on beta</summary</details label +regression-from-stable-to-beta Of note, the opposite pointer cast fails to compile on stable, beta, and nightly. This seems wrong to me. <details<summaryThe opposite cast</summaryError: </details
Just for context (unsure if relevant here) I see in that PR a question for T-lang about a breaking change at this and in the following FCP that was
So while the breaking change was approved, I believe this code should compile (and definitely not ICE). The issue seems to be that borrowck can't prove a bound (after typeck did). Seeing for you need a projection to trigger the issue () I think there is normalization missing somewhere.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
<ins> // check-pass #![allow(incomplete_features)] #![feature(adt_const_params)] struct FooConst<const ARRAY: &'static [&'static str]> {} const FOO_ARR: &[&'static str; 2] = &["Hello", "Friend"]; fn main() { let _ = FooConst::<FOO_ARR> {}; } </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. --Looks a bit like <!-- 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 --
Used as feature and got this: Regressed somewhere between ... <details<summaryBefore</summary</details<details<summaryAfter</summary</details
claim
Change:
pub(crate) struct LtoDylib; #[derive(Diagnostic)] <ins> #[diag(codegen_llvm_lto_proc_macro)] pub(crate) struct LtoProcMacro; #[derive(Diagnostic)] </ins> #[diag(codegen_llvm_lto_bitcode_from_rlib)] pub(crate) struct LtoBitcodeFromRlib { pub llvm_err: String,

Discussion:
I'm trying to cross-compile the rust compiler to x86_64 on an M1 macOS machine with LTO enabled and ran into a compile error while building the stage2 compiler artifact: I also tried cross-compiling aarch64 on an Intel Mac and ran into the same issue. Here is the I used: It seems that is enabling LTO for proc-macro crates, but only when cross-compiling?
sorry for pinging, are there any updates on this issue? This bug is easily reproducible, and is preventing cross compiling the toolchain with LTO enabled.
I haven't had time to look into this, no. You can always disable LTO as a workaround.
This problem also appears when just the vendor of the target tripple changes (i.e. ).
Thank you for the additional feedback, will look into this issue in couple weeks.