jiebi/CodeConvo huggingface dataset:
Change:
return 1; } <ins> let src = local_begin.fm.external_src.borrow(); </ins> // We need to extend the snippet to the end of the src rather than to end_index so when // searching forwards for boundaries we've got somewhere to search. let snippet = if let Some(ref src) = local_begin.fm.src { let len = src.len(); <del> (&src[start_index..len]).to_string() } else if let Some(src) = local_begin.fm.external_src.borrow().get_source() { </del> <ins> (&src[start_index..len]) } else if let Some(src) = src.get_source() { </ins> let len = src.len(); <del> (&src[start_index..len]).to_string() </del> <ins> (&src[start_index..len]) </ins> } else { return 1; };

Discussion:
I've noticed that the nightly compilers lately have taken quite a long time to compile . The crate is a large amount of code generated by . I've narrowed down the difference in build time to a nightly release. The results below are from debug builds, but I've seen similar numbers for release builds. rustc 1.25.0-nightly ( 2018-01-26): rustc 1.25.0-nightly ( 2018-01-27): I'm not really sure how to profile this further, so I'll take any suggestion you have.
Looks like the only PRs in that range are , , , and . None of which seem immediately relevant. I also can't reproduce locally... Are you sure these results are caused by some external process? What platform are you running on?
I've been able to reliably reproduce this behavior on my desktop. I tried re-running the test on my laptop and saw similar results. Both my laptop and desktop are using NixOS 17.09.2964. (Hummingbird) with . The test results with the full invocations are below. The borrow checking stands out though... vs. I'm going to go ahead and test this again inside of a fedora container to try to narrow down if this is specific to NixOS. <details
I think I've heard reports elsewhere of similar slowdowns, but I can't seem to find anything right now. I tested on a Ubuntu 17.10 machine, so it's possible nix is somehow at fault here...
Can you try testing with nightly-2018-01-28 (actually )? That's the version where I start to see the failure.
Yes, I can now reproduce. Based on a quick inspection with gdp, I suspect is at fault -- I'm seeing CPU time mostly spent in memmove... called from . I suspect the problem is the String allocations here:
cc
After testing in the Fedora container, I'm seeing similar performance so I think it's safe to rule out NixOS's packaging as a factor. Since the time to borrow check seems to be the issue, is the only change that seems relevant. <details
it seems to me like those could be instead...
Yep, I have a patch locally that seems to solve the problem by removing the allocation.
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. use std::ops::Add; fn foo<T>(x: T) -> <i32 as Add<T>>::Output where i32: Add<T> { 42i32 + x } fn main() { println!("{}", foo(0i32)); } </ins>

Discussion:
This fails to compile:
probably related, this: fails to compile with: error: binary operation cannot be applied to type this used to compile but not sure if it's a bug or the syntax has changed
This works: It should be the intended behavior.
thanks!
This now works after Niko's refactoring work. (Adding needstest, since I can't find a test that tests this exactly, although I wasn't looking very hard.)
Change:
<del> Subproject commit 311d56cd91609c1c1c0370cbd2ece8e3048653a5 </del> <ins> Subproject commit d6822f9c433bd70f786b157f17beaf64ee28d83a </ins>

Discussion:
(and by extension ) have as the mask type, but the lists as the mask type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hey I (I think we all) very much appreciate the work you are doing by looking at the docs and finding unsound things. What about opening a PR and fixing them immediatly (some of them could be done by using the github editor)? It's a very great opportunity to make Rust a better programming langauge. If you feel like it, please open a PR and reference this issue with one of the github provides.
I am well aware of how GitHub works :D unfortunately for us all, I only have so much programming time. I've been busy at work safe wrapping all these intrinsics for my own lib, which is why I'm filing bugs on them as they come up. However, in my experience, filing even a single PR to this repo is rather involved and so I've mostly given up on doing it. As to this particular issue, it's a change to a stable API, so at minimum a full crater run would have to be performed of course. The input mask value has to be a const, so you get a lot of literals of course and those can usually infer to the new type fine, but you also get a lot of const declarations too, which would break. I suspect that at least some people will get their code broken. Given that the intrinsic only uses the 8 lowest bits, it would be entirely reasonable for T-libs to say they don't care about the i32/u32 difference compared to code breaks and just document the (very minor) difference. or they could go for absolute exactness and declare the breaks to be the fair product of a bug fix. up to them
I believe this was changed recently because Intel's definition is wrong/inconsistent. See
ah lovely. of course the guide is wrong :P well, then consider this a minor documentation issue. the function should simply explain that it doesn't match the spec and why and such.
I could take this! claim
Triage: I'm going to release assignment due to inactivity.

If you're still interested in this, feel free to re-claim. release-assignment
claim
I have submitted in order to fix this. I believe we could resolve this issue once that PR is merged by updating the submodule.
Change:
<ins> error: expected at least one digit in exponent --> $DIR/issue-49746-unicode-confusable-in-float-literal-expt.rs:11:53 | LL | const UNIVERSAL_GRAVITATIONAL_CONSTANT: f64 = 6.674e−11; // m³⋅kg⁻¹⋅s⁻² |                                                     ^ help: Unicode character '−' (Minus Sign) looks like '-' (Minus/Hyphen), but it is not | LL | const UNIVERSAL_GRAVITATIONAL_CONSTANT: f64 = 6.674e-11; // m³⋅kg⁻¹⋅s⁻² |                                                     ^ error: aborting due to previous error </ins>

Discussion:
This code: () Looks pretty identical to this code: But the first one doesn't compile because I accidentally used a unicode minus sign (−) instead of a dash (-). This happened to me when I pasted a constant from Wikipedia. We already produce an error about things like this in other cases. For example with an en space: We produce the following: Maybe we could do the same for the minus sign since it is a pretty confusing error to receive?
The unicode minus sign is already on the list of similar characters: However it looks like it doesn't work in this context.
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. trait A<T: A<T>> {} fn main() {} </ins>

Discussion:
I tried pulling the old on rustc, and depending on the syntax used it either works as expected or plainly crashes. This works just fine: However this really upsets the compiler:
Is this a dup of ?
The code currently compiles, so I believe this issue can be closed.
I'll add a regression test
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. struct A<F: FnOnce()->T,T>(F::Output); struct B<F: FnOnce()->T,T>(A<F,T>); // Removing Option causes it to compile. fn foo<T,F: FnOnce()->T>(f: F) -> Option<B<F,T>> { Some(B(A(f()))) } fn main() { let v = (|| foo(||4))(); match v { Some(B(A(4))) => {}, _ => unreachable!() } } </ins>

Discussion:
Compiling the following code causes a panic: Compiler output: I compiled with rustc 1.5.0-nightly ( 2015-09-19) binary: rustc commit-hash: commit-date: 2015-09-19 host: x86_64-unknown-linux-gnu release: 1.5.0-nightly
Reduced test case:
This is a 1.3-1.4 regression. I accidentally caused it in .
triage: I-nominated
triage: P-medium
Change:
unsafe fn unsf_foo(&self) {} } <ins> trait Qux { #[target_feature(enable = "sse2")] //~^ ERROR cannot be applied to safe trait method fn foo(&self) {} } </ins> fn main() {}

Discussion:
The compiler currently allows safe default method implementations to be marked with : which I don't think is allowed in . For reference, is not allowed on trait implementations: From my limited testing, this doesn't seem to be unsound however, as the compiler seems to consider all implementations of as having . cc label T-lang T-compiler C-bug F-targetfeature11 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A good resolution to this would be to move it into a separate feature gate I guess?
claim
Change:
| ItemKind::ExternCrate(..) | ItemKind::ForeignMod(..) | ItemKind::TyAlias(..) => DefPathData::TypeNs(i.ident.name), <del> ItemKind::Fn(_, sig, generics, body) if sig.header.asyncness.is_async() => { return self.visit_async_fn( i.id, i.ident.name, i.span, &sig.header, generics, &sig.decl, body.as_deref(), ); } </del> ItemKind::Static(..) | ItemKind::Const(..) | ItemKind::Fn(..) => { DefPathData::ValueNs(i.ident.name) }

Discussion:
I was migrating my library (Mammut) to use reqwest and be async, and the compiler ICEd. I don't know how to reduce it further than this. I tried this code: I expected to see this happen: A successful build or another compile error Instead, this happened: I also tried this on the latest nightly and it emits the same error. : Backtrace:
Reproduced with lastest nighlty: ICE from macro resolving I believe. cc
cc
triage: P-high, removing nomination tag. (instead, going to proritize going through the P-high issues that have accumulated over last two weeks.)
Visiting from triage.. the next step is to reduce the reproducer.
Reduced ():
Further reduced:
Fixed in
Change:
<ins> // Regression test for <https://github.com/rust-lang/rust/issues/100529>. #![no_core] #![feature(no_core)] // @has enum_variant_hidden.json "$.index[*][?(@.name=='ParseError')]" // @has - "$.index[*][?(@.name=='UnexpectedEndTag')]" // @is - "$.index[*][?(@.name=='UnexpectedEndTag')].inner.variant_kind" '"tuple"' // @is - "$.index[*][?(@.name=='UnexpectedEndTag')].inner.variant_inner" [] pub enum ParseError { UnexpectedEndTag(#[doc(hidden)] u32), } </ins>

Discussion:
Found via and extract into the root dir and run with rustdoc JSON is built labels +A-rustdoc-json +T-rustdoc +I-ICE +requires-nightly
modify labels: +E-needs-mcve
Same ICE can also be reproduced with which crater also found
The tzdb ice is the same issue, it also used on enum fields: Could you rename the issue? modify labels: -E-needs-mcve
Thanks for the MCVE! I'm planning to work on it tomorrow if no one did until then.
Change:
export CFLAGS="-fPIC $CFLAGS" <del> # FIXME: remove the patch when updating to 1.1.20 MUSL=musl-1.1.19 </del> <ins> MUSL=musl-1.1.20 </ins> # may have been downloaded in a previous run if [ ! -d $MUSL ]; then curl https://www.musl-libc.org/releases/$MUSL.tar.gz | tar xzf - <del> # Patch to fix https://github.com/rust-lang/rust/issues/48967 cd $MUSL &&  curl "https://git.musl-libc.org/cgit/musl/patch/?id=610c5a8524c3d6cd3ac5a5f1231422e7648a3791" | patch -p1 &&  cd - </del> fi cd $MUSL

Discussion:
On target (and ) any binary compiled with lto will fail with on latest stable (1.29.0 as of this time). After some searching it seems the culprit is which was meant to fix until musl 1.1.20 was out. Unfortunately the patch for musl used in that pull request broke . This was later fixed in which also landed in musl 1.1.20.
Change:
} } <ins> #[stable] impl<I> ExactSizeIterator for Skip<I> where I: ExactSizeIterator {} </ins> /// An iterator that only iterates over the first `n` iterations of `iter`. #[derive(Clone)] #[must_use = "iterator adaptors are lazy and do nothing unless consumed"]

Discussion:
This should be in : This would require either implementing for (where ), or decoupling and (like in )
Change:
<del> // This used to compile the future down to ud2, due to uninhabited types being // handled incorrectly in generators. // compile-flags: -Copt-level=z -Cdebuginfo=2 --edition=2018 #![feature(async_await)] #![allow(unused)] use std::future::Future; use std::task::Poll; use std::task::Context; use std::pin::Pin; use std::rc::Rc; struct Never(); impl Future for Never { type Output = (); fn poll(self: Pin<&mut Self>, _cx: &mut Context<'_>) -> Poll<Self::Output> { Poll::Pending } } fn main() { let fut = async { let _rc = Rc::new(()); // Also crashes with Arc Never().await; }; let _bla = fut; // Moving the future is required. } </del>

Discussion:
E.g. in and cc
I'd like to work on this :smile:
You've got it :)
Change:
<ins> // Regression test for #98693. // // The closure encounters an obligation that `T` must outlive `!U1`, // a placeholder from universe U1. We were ignoring this placeholder // when promoting the constraint to the enclosing function, and // thus incorrectly judging the closure to be safe. fn assert_static<T>() where for<'a> T: 'a, { } fn test<T>() { || { //~^ ERROR the parameter type `T` may not live long enough assert_static::<T>(); }; } fn main() {} </ins>

Discussion:
This code compiles after although it shouldn't: () This is similar to in that we're not taking into account placeholder regions when "promoting" type-tests from the closure to its caller: label T-types regression-from-stable-to-beta C-bug A-NLL I-unsound <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I guess it would be an easy fix claim
The unsoundness exploitation in can easily be adapted for this issue, so it is in fact a soundness issue:
issue touched in today's T-compiler meeting, . Will also be discussed tomorrow during the T-types meeting.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
use rustc_hir::def_id::{DefId, CRATE_DEF_INDEX, LOCAL_CRATE}; use rustc_hir::PrimTy; use rustc_session::config::nightly_options; <ins> use rustc_session::parse::feature_err; </ins> use rustc_span::hygiene::MacroKind; use rustc_span::symbol::{kw, sym, Ident, Symbol}; use rustc_span::{BytePos, Span, DUMMY_SP};

Discussion:
Nightly on playground <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
we should forbid lifetimes in anonymous constants to avoid this issue.

results in
Could this be a duplicate of ?
:+1: This probably has the same fix. I do think that the issues are different enough to keep this one open though
Change:
// a test for it. (_, ty::Infer(ty::TyVar(_))) => {} (ty::Infer(ty::TyVar(_)), _) => {} <del> _ if (r_a, r_b).has_opaque_types() => { </del> <ins> _ if r_a != r_b && (r_a, r_b).has_opaque_types() => { </ins> span_bug!( cause.span(), "opaque types got hidden types registered from within subtype predicate: {r_a:?} vs {r_b:?}"

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. --Just the sample code from the leptos : <!-- 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<strongFull Backtrace</strong</summary<p </p</details
I'm also hitting this on 2024-04-16 but not on 2024-04-14
Glad I checked to see if this had been raised before I posted a duplicate Same issues with leptos start trunk Just grabbed ran through rustup toolchain install nightly --allow-downgrade rustup target add wasm32-unknown-unknown excitedly hit trunk serve --port 3000 --open and watched the compiler detonate around 6 times a second dumping stack traces into the project directory.
is this still not solved? because I also experienced this when running the command
I'm pretty sure that's from cc
Is there still an issue here? I still can't run
This is a compiler issue, it won't be fixed before the next nightly release, please stick with an older compiler until lands
what i have to do to change to older compiler version?
Unless this is leptos' doing, in the folder where you are seeing the problem
Change:
/// Precondition: `vid` must not have been previously instantiated. pub fn instantiate(&mut self, vid: ty::TyVid, ty: Ty<'tcx>) { let vid = self.root_var(vid); <ins> debug_assert!(!ty.is_ty_var(), "instantiating ty var with var: {vid:?} {ty:?}"); </ins> debug_assert!(self.probe(vid).is_unknown()); debug_assert!( self.eq_relations().probe_value(vid).is_unknown(), <del> "instantiating type variable `{:?}` twice: new-value = {:?}, old-value={:?}", vid, ty, </del> <ins> "instantiating type variable `{vid:?}` twice: new-value = {ty:?}, old-value={:?}", </ins> self.eq_relations().probe_value(vid) ); self.eq_relations().union_value(vid, TypeVariableValue::Known { value: ty });

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. -- <!-- --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
minimal repro of the error reported above <details<summaryBacktrace</summary</details
Same ICE with in  () cc searched nightlies: from nightly-2023-12-03 to nightly-2023-12-06 regressed nightly: nightly-2023-12-06 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Change:
} Some(name) } <del> ty::Adt(..) => { // If `Some` is returned then a named struct is created in LLVM. Name collisions are // avoided by LLVM (with increasing suffixes). If rustc doesn't generate names then that // can improve perf. Some(String::new()) } </del> _ => None, };

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Hello! I'm observing a compilation regression coming from 1.47 to 1.48. Just an with only a dependency segfaults when building it with: System logs: GDB backtrace: Versions and also have this issue. Without these RUSTFLAGS it builds fine, it also builds fine when I build in debug mode. No problems at all when building that project on version 1.47.0. My system info:
This looks like it might be a duplicate of but it's great to have a smaller testcase than rustc itself!
The backtrace looks really similar indeed!
Steps: Result: How to make it not segfault, do any of the below: replace step 4 with don't use use or (preview doesn't work for me in github: so if it looks bad I'll try to edit)
Looks like a side-effect of , which exposed an existing bug in loop vectorize
This
Can confirm that is gone after applying (but without the test case fix which doesn't yet exist in rust 1.48.0 on gentoo)

When bootstrapping rustc, I can observe a crash inside llvm when building . In I could see this: I did a bisect and found out that the crash happens since cc my cpu is a The timing of the crash makes me think that this might happen somewhere during LTOing of the rustcmiddle crate, rustc did not show a backtrace for the crash though, since it happens inside llvm. I already did purge my rustc build cache and the sccache before I saw the segfault happens inside llvm (it didn't help anyway). :sweat_smile: rustc @
cc
Was a coredump generated? If so, should be able to generate a backtrace by running , followed by the command.
does this help?
via
There is no segfault if I build without
Marking this as P-high based on the
What setup are you using to pass ?
I had in my initially. reproduces the segfault as well.
was hitting segfaults with LLD with target-cpu=native, but that was on MSVC:
Hmm, I think i also have my linker set to lld, but I'm on linux...
Still crashes after llvm update in
I got the same SIGSEGV with at stage 0 Can't reproduce it with bootstrap from 1.47 to 1.47
some users hit it in gentoo with 1.48.0 downstream bug removing or helps as described here.
This
I ran into the same problem: OS: Ubuntu20.04 rustc exited with signal: 9 error: could not compile Caused by:
Change:
); } <ins> fn check_foreign_item(&mut self, cx: &LateContext<'_>, foreign_item: &hir::ForeignItem<'_>) { let def_id = cx.tcx.hir().local_def_id(foreign_item.hir_id); let (article, desc) = cx.tcx.article_and_description(def_id.to_def_id()); self.check_missing_docs_attrs( cx, Some(foreign_item.hir_id), &foreign_item.attrs, foreign_item.span, article, desc, ); } </ins> fn check_struct_field(&mut self, cx: &LateContext<'_>, sf: &hir::StructField<'_>) { if !sf.is_positional() { self.check_missing_docs_attrs(

Discussion:
It seems like this lint should fire if you have an declaration without docs on it. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: A-lint T-compiler C-bug
I think I know what causes this and will write a more general fix here this week. claim
the fix wasn't more general but it's a fix none the less
Change:
if builder.config.verbose() { cmd.arg("--verbose"); } <ins> // If the lib directories are in an unusual location (changed in // config.toml), then this needs to explicitly update the dylib search // path. builder.add_rustc_lib_path(self.compiler, &mut cmd); </ins> builder.run(&mut cmd); // Run rustbook/mdbook to generate the HTML pages. builder.ensure(RustbookSrc {

Discussion:
I tried to build rust right after got merged and caught error:
cc
What command did you run?
Change:
/// assert_eq!(into_iter.next().unwrap(), 'z'); /// ``` #[stable(feature = "vec_into_iter_as_slice", since = "1.15.0")] <del> pub fn as_mut_slice(&self) -> &mut [T] { </del> <ins> pub fn as_mut_slice(&mut self) -> &mut [T] { </ins> unsafe { slice::from_raw_parts_mut(self.ptr as *mut T, self.len()) }

Discussion:
on reddit points out that can be called multiple times and result in getting multiple of the exact same data.
Awesome!
I suggest we change it to &mut and run it through crater to see the impact. We can change it or immediately deprecate it. We can make a point release or wait until 1.16.