jiebi/CodeConvo huggingface dataset:
Change:
<!-- 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. --
Removing seems to fix it.
Reduced, with no nightly features (): Output on stable and beta: label regression-from-stable-to-nightly
bisection cc: searched nightlies: from nightly-2022-01-01 to nightly-2022-06-20 regressed nightly: nightly-2022-06-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Another snippet from

Discussion:
match b.kind() { ty::ConstKind::Infer(InferConst::Var(_)) if D::forbid_inference_vars() => { // Forbid inference variables in the RHS. <del> bug!("unexpected inference var {:?}", b) </del> <ins> self.infcx.tcx.sess.delay_span_bug( self.delegate.span(), format!("unexpected inference var {:?}", b,), ); Ok(a) </ins> } // FIXME(invariance): see the related FIXME above. _ => self.infcx.super_combine_consts(self, a, b),

<ins> use std::convert::TryFrom; pub fn test_usage(p: ()) { SmallCString::try_from(p).map(|cstr| cstr); //~^ ERROR: type annotations needed } pub struct SmallCString<const N: usize> {} impl<const N: usize> TryFrom<()> for SmallCString<N> { type Error = (); fn try_from(path: ()) -> Result<Self, Self::Error> { unimplemented!(); } } fn main() {} </ins>

<ins> error[E0282]: type annotations needed --> $DIR/issue-98299.rs:4:5 | LL |     SmallCString::try_from(p).map(|cstr| cstr); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type for enum `Result<SmallCString<{_: usize}>, ()>` error: aborting due to previous error For more information about this error, try `rustc --explain E0282`. </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!

Discussion:
<del> Subproject commit c4dd3f4ef98f8527aa652e8154ff044ca3e88455 </del> <ins> Subproject commit 655eed35b7ca7cae08f21ead6151b9dfb69794ff </ins>
Change:
<!-- 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: I expected to see this happen: Instead, this happened: Apparently, taking a shared reference of will suppress the lint. This seems like a false negative. While false negatives can't be avoided entirely, this case seems to be avoidable as taking a shared reference shouldn't change the type of (which is ) or modify any data in this example. Note that will trigger the lint properly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
See also .
claim
Note this is a problem because which is supposed to fail to compile but this bug makes it fail at runtime instead
In case no one has dug into it yet, the error is suppressed in but not in and before:
label +regression-from-stable-to-stable
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This is caused by . It only ever worked because the lint ran after optimizations. I made a fix . It specializes the length of arrays as constant, even if the array isn't. I'm going to open a PR when I have time, probably tomorrow. In the long term, I'd like to implement some more extensive tracking of "what parts of a value are constant". For example, the compiler currently assumes that anything that had its reference taken can change, but actually, this can only happen inside (as I understand it).
Labels from the closed duplicate , label A-diagnostics, A-lint, A-mir-opt, T-compiler.
Fixed on stable label E-needs-test
I claim the add test part
This lint only appears on full builds (not check), but this will be fixed once lands.
Reopening because I feel this is not yet solved, see on . As per the , should nail down this issue?
MRE: Also, duplicate of
Another variant of this same issue:

Discussion:
<ins> // build-fail fn main() { let xs: [i32; 5] = [1, 2, 3, 4, 5]; let _ = &xs; let _ = xs[7]; //~ ERROR: this operation will panic at runtime [unconditional_panic] } </ins>

<ins> error: this operation will panic at runtime --> $DIR/unconditional_panic_98444.rs:6:13 | LL |     let _ = xs[7]; |             ^^^^^ index out of bounds: the length is 5 but the index is 7 | = note: `#[deny(unconditional_panic)]` on by default error: aborting due to previous error </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Probably a missing join (these tests are a bit random, now that we have preemption).

Discussion:
[[package]] name = "measureme" <del> version = "9.1.2" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "78f7a41bc6f856a2cf0e95094ad5121f82500e2d9a0f3c0171d98f6566d8117d" dependencies = [ "log", "memmap2", "parking_lot 0.11.2", "perf-event-open-sys", "rustc-hash", "smallvec", ] [[package]] name = "measureme" </del> version = "10.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "bd460fad6e55ca82fa0cd9dab0d315294188fd9ec6efbf4105e5635d4872ef9c"

"lazy_static", "libc", "log", <del> "measureme 9.1.2", </del> <ins> "measureme", </ins> "rand 0.8.5", "regex", "rustc-workspace-hack",

"cstr", "libc", "libloading", <del> "measureme 10.0.0", </del> <ins> "measureme", </ins> "rustc-demangle", "rustc_ast", "rustc_attr",

"indexmap", "jobserver", "libc", <del> "measureme 10.0.0", </del> <ins> "measureme", </ins> "memmap2", "parking_lot 0.11.2", "rustc-hash",

name = "rustc_query_impl" version = "0.0.0" dependencies = [ <del> "measureme 10.0.0", </del> <ins> "measureme", </ins> "rustc-rayon-core", "rustc_ast", "rustc_data_structures",

<del> Subproject commit 655eed35b7ca7cae08f21ead6151b9dfb69794ff </del> <ins> Subproject commit 9e2dac4787e5470ecd9e245420e8da9528620edd </ins>
Change:
See: This code: produces on latest stable (1.61.0).
Maybe we could form a heuristic around tokens that we know should eventually be followed by -- , , , etc. If we see one of those, (then some random other tokens), then we see , then that would be a suspicious rbrace which we could point out later.. e.g. if we see that triggers the heuristic, but not
The problem is that the error happens in the lexer, not the parser. Ideally we'd rework the lexer to have a token stream mode of operation instead of a token tree mode of operation, only for code that is being passed to the parser (i.e., not coming from a macro).
This is particularly confusing when the points to a macro: gives on 1.65.0-nightly (2022-08-31 )
the output now changed to: Do you think the should be removed?
This is changed to: it seems more helpful now.
Let's close this ticket after adding these two cases to the test suite then. I'm sure there are outstanding issues in this area, but we can hope that we'll get tickets for those more specific cases, while the tests keep us from regressing silently (hopefully, lets make sure the tests are fully annotated so its harder to do that by accident).

Discussion:
<ins> fn foo() { match 0 { _ => {} } if foo } } //~ ERROR unexpected closing delimiter: `}` fn main() {} </ins>

<ins> error: unexpected closing delimiter: `}` --> $DIR/issue-98601-delimiter-error-1.rs:7:1 | LL | fn foo() { |          - this delimiter might not be properly closed... LL |     match 0 { LL |       _ => {} |            -- block is empty, you might have not meant to close it ... LL |     } |     - ...as it matches this but it has different indentation LL | } | ^ unexpected closing delimiter error: aborting due to previous error </ins>

<ins> fn main() { todo!(); } fn other(_: i32)) {} //~ ERROR unexpected closing delimiter: `)` </ins>

<ins> error: unexpected closing delimiter: `)` --> $DIR/issue-98601-delimiter-error-unexpected-close.rs:5:17 | LL | fn main() { |           - this opening brace... LL |     todo!(); LL | } | - ...matches this closing brace LL | LL | fn other(_: i32)) {} |                 ^ unexpected closing delimiter error: aborting due to previous error </ins>
Change:
Run with this in : and inspect . There is an item for the of the blanket impl  and it's default value is . There is an item but the default value is missing. It looks like this: When using instead of the information about the default value is present. It looks like this: This change, which in practice is a regression, is caused by But we can't revert it of course because that will result in ICEs which is even worse. So we need some kind of follow-up fix. labels +A-rustdoc-json +T-rustdoc +C-bug +requires-nightly
It seems like you already suggested a fix. Want to open a PR for it?
Yep I will do that as soon as I get time. Probably today.
It's not in a hurry. Don't hesitate to ask if you need help.

Discussion:
AssocTypeItem(t, b) => ItemEnum::AssocType { generics: t.generics.into_tcx(tcx), bounds: b.into_iter().map(|x| x.into_tcx(tcx)).collect(), <del> default: t.item_type.map(|ty| ty.into_tcx(tcx)), </del> <ins> default: Some(t.item_type.unwrap_or(t.type_).into_tcx(tcx)), </ins> }, // `convert_item` early returns `None` for striped items and keywords. StrippedItem(_) | KeywordItem(_) => unreachable!(),

<ins> // Regression test for <https://github.com/rust-lang/rust/issues/98658> #![no_std] // @has blanket_impls.json // @has - "$.index[*][?(@.name=='Error')].kind" "assoc_type" // @has - "$.index[*][?(@.name=='Error')].inner.default.kind" "resolved_path" // @has - "$.index[*][?(@.name=='Error')].inner.default.inner.name" "Infallible" pub struct ForBlanketTryFromImpl; </ins>
Change:
The correct behavior is for both crates' docs to render as: <img src="https://user-" height="100"However, recent versions of nightly rustdoc render as the above, while rendering incorrectly as: <img src="https://user-" height="100"I believe this is a bug because that is not valid syntax in Rust.
bisects to in nightly-2022-06-23 ( &mdash;
Example affecting the standard library docs: not affected. <img src="https://user-" height="100"- broken. <img src="https://user-" height="100"

Discussion:
.collect_referenced_late_bound_regions(&poly_trait_ref) .into_iter() .filter_map(|br| match br { <del> ty::BrNamed(_, name) => Some(GenericParamDef { </del> <ins> ty::BrNamed(_, name) if name != kw::UnderscoreLifetime => Some(GenericParamDef { </ins> name, kind: GenericParamDefKind::Lifetime { outlives: vec![] }, }),

<ins> /// When reexporting this function, make sure the anonymous lifetimes are not rendered. /// /// https://github.com/rust-lang/rust/issues/98697 pub fn repro<F>() where F: Fn(&str), { unimplemented!() } </ins>

<ins> // aux-build:issue-98697-reexport-with-anonymous-lifetime.rs // ignore-cross-compile // When reexporting a function with a HRTB with anonymous lifetimes, // make sure the anonymous lifetimes are not rendered. // // https://github.com/rust-lang/rust/issues/98697 extern crate issue_98697_reexport_with_anonymous_lifetime; // @has issue_98697/fn.repro.html '//pre[@class="rust fn"]/code' 'fn repro<F>() where F: Fn(&str)' // @!has issue_98697/fn.repro.html '//pre[@class="rust fn"]/code' 'for<' pub use issue_98697_reexport_with_anonymous_lifetime::repro; </ins>
Change:
This is unfortunate because: gives the impression that documentation fixes should not be submitted here, or are not welcome. prevents you from gathering commonly requested information (link to docs, rust version number, suggested fixes) in an automatic fashion. prevents automatic labelling for documentation-relevant issues. To fix this, . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label A-meta
claim

Discussion:
<ins> --- name: Documentation problem about: Create a report for a documentation problem. labels: A-docs --- <!-- Thank you for finding a documentation problem! 📚 Documentation problems might be grammatical issues, typos, or unclear wording, please provide details regarding the documentation including where it is present. --> ### Location ### Summary </ins>
Change:
While building Rust 1.62.0 on Solaris SPARC it fails with:
Looks like this was caused by (cc It looks like that also caused issues with openbsd (), I'm wondering if it would make sense to audit which platforms were affected to make sure they are all addressed? Passing seems like a somewhat blunt solution. I would expect it to not pass if the target does not support it and the user did not specify it. That is roughly what , though I suspect that might be not as easy to do in bootstrap.
I'm not sure there's a great way of solving this properly in bootstrap. It should be solved for good by but if you want to submit a PR in the meantime that adds a condition for Solaris then I can r+ it.
WG-prioritization assigning priority (). label -I-prioritize +P-high

Discussion:
if !target.contains("windows") { let needs_unstable_opts = target.contains("linux") <ins> || target.contains("solaris") </ins> || target.contains("windows") || target.contains("bsd") || target.contains("dragonfly")
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Yes, I think I'll have time to fix this today.
I think there are other changes that need to happen first. I tried to compile with tonight's nightly and got lots of errors from rustfmt: do you know what could be going wrong? do I need to update rustfmt or something like that?
I pushed the latest update at is the failure above from the build here or in the RLS repo? Rustfmt should be vendored here and should work as expected IIUC.
that's in the RLS repo.

Discussion:
<del> Subproject commit ece09b88c0365947af79c0ffdeea02bc6c1eec25 </del> <ins> Subproject commit fcf1f94c9ab2acc18cfd4368a4aeb38e77da9649 </ins>
Change:
<!-- 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</detailsPlayground uses 7-13 nightly still, and the code compiles there:
Hmmm... I can't seem to reproduce this. Windows only, perhaps? Or incremental comp issue? I have the input in a and am running .
followed by reproduces this for me. Might be Windows only, haven't tested elsewhere. edit: my code originally failed in Github Actions using an ubuntu builder so I guess not Windows only.
Yup, fails in WSL, too: <details<summaryBacktrace</summary<p</p</details
It fails on latest nightly for me. Failing version: Working version:
Ahh! I was testing 2022-07-14, which passes. I got confused by the date being 1 day off. Yeah, I can reproduce it now :) Running a bisect.
searched nightlies: from nightly-2022-07-13 to nightly-2022-07-15 regressed nightly: nightly-2022-07-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
is yet another rollup; we really need a try build for each rolled up PR... Out of: (Always create elided lifetime parameters for functions) (Stabilize and rexport in ) (Implement lifetime binder for closures) (remove allow(rustc::potentialqueryinstability) in rustcspan) (Give a better error when fails for an optional tool) This looks like cc
This is a variant of the following bug which already happens on stable:

Discussion:
let a_poly_sig = a.fn_sig(tcx); let b_poly_sig = b.fn_sig(tcx); <del> // As we don't compare regions, skip_binder is fine. let a_sig = a_poly_sig.skip_binder(); let b_sig = b_poly_sig.skip_binder(); </del> <ins> // We don't compare regions, but leaving bound regions around ICEs, so // we erase them. let a_sig = tcx.erase_late_bound_regions(a_poly_sig); let b_sig = tcx.erase_late_bound_regions(b_poly_sig); </ins> (a_sig.abi, a_sig.unsafety, a_sig.c_variadic) == (b_sig.abi, b_sig.unsafety, b_sig.c_variadic)

<ins> // Check that we do not ICE when structurally comparing types with lifetimes present. // check-pass pub struct Record<'a> { pub args: &'a [(usize, &'a str)], } mod a { extern "Rust" { fn foo<'a, 'b>(record: &'a super::Record<'b>); fn bar<'a, 'b>(record: &'a super::Record<'b>); } } mod b { extern "Rust" { fn foo<'a, 'b>(record: &'a super::Record<'b>); fn bar<'a, 'b>(record: &'a super::Record<'b>); } } fn main() {} </ins>
Change:
and are both listed as const in 1.56 according to the "since" info on the right, but only the version lists in the actual signature. core: std:
I took this screenshot in : ! So it's fixed. Closing then.
I don't think this has been fixed yet. (note that this issue is about , not ) <img width="1009" alt="core" src="https://user-"
Oh you're right. Re-opening.

Discussion:
} let header = match *self.kind { ItemKind::ForeignFunctionItem(_) => { <del> let abi = tcx.fn_sig(self.item_id.as_def_id().unwrap()).abi(); </del> <ins> let def_id = self.item_id.as_def_id().unwrap(); let abi = tcx.fn_sig(def_id).abi(); </ins> hir::FnHeader { unsafety: if abi == Abi::RustIntrinsic { intrinsic_operation_unsafety(tcx, self.item_id.as_def_id().unwrap())

hir::Unsafety::Unsafe }, abi, <del> constness: hir::Constness::NotConst, </del> <ins> constness: if abi == Abi::RustIntrinsic && tcx.is_const_fn(def_id) && is_unstable_const_fn(tcx, def_id).is_none() { hir::Constness::Const } else { hir::Constness::NotConst }, </ins> asyncness: hir::IsAsync::NotAsync, } }

<ins> #![feature(intrinsics)] #![feature(staged_api)] #![crate_name = "foo"] #![stable(since="1.0.0", feature="rust1")] extern "rust-intrinsic" { // @has 'foo/fn.transmute.html' // @has - '//pre[@class="rust fn"]' 'pub const unsafe extern "rust-intrinsic" fn transmute<T, U>(_: T) -> U' #[stable(since="1.0.0", feature="rust1")] #[rustc_const_stable(feature = "const_transmute", since = "1.56.0")] pub fn transmute<T, U>(_: T) -> U; // @has 'foo/fn.unreachable.html' // @has - '//pre[@class="rust fn"]' 'pub unsafe extern "rust-intrinsic" fn unreachable() -> !' #[stable(since="1.0.0", feature="rust1")] pub fn unreachable() -> !; } extern "C" { // @has 'foo/fn.needs_drop.html' // @has - '//pre[@class="rust fn"]' 'pub unsafe extern "C" fn needs_drop() -> !' #[stable(since="1.0.0", feature="rust1")] pub fn needs_drop() -> !; } </ins>
Change:
Steps to reproduce: It's possible that this was accidentally stabilized, then feature gated later.
This seems to be caused by . I was thinking might address this, but I tried that PR and it doesn't seem to work. Maybe can confirm. cc
Looks like another case of , is stable but the module it lives in is not: Just need to add and it should work.
I'll work on this.
Using your suggested fix, I have a simple PR to address this, if you'd like to review: . I've confirmed locally that a toolchain built with this patch fixes the regression.

Discussion:
use crate::sys_common::{AsInner, IntoInner}; /// Raw file descriptors. <ins> #[cfg_attr(not(bootstrap), rustc_allowed_through_unstable_modules)] </ins> #[stable(feature = "rust1", since = "1.0.0")] pub type RawFd = raw::c_int;

/// This is only available on unix and WASI platforms and must be imported in /// order to call the method. Windows platforms have a corresponding /// `AsRawHandle` and `AsRawSocket` set of traits. <ins> #[cfg_attr(not(bootstrap), rustc_allowed_through_unstable_modules)] </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait AsRawFd { /// Extracts the raw file descriptor.

/// A trait to express the ability to construct an object from a raw file /// descriptor. <ins> #[cfg_attr(not(bootstrap), rustc_allowed_through_unstable_modules)] </ins> #[stable(feature = "from_raw_os", since = "1.1.0")] pub trait FromRawFd { /// Constructs a new instance of `Self` from the given raw file

/// A trait to express the ability to consume an object and acquire ownership of /// its raw file descriptor. <ins> #[cfg_attr(not(bootstrap), rustc_allowed_through_unstable_modules)] </ins> #[stable(feature = "into_raw_os", since = "1.4.0")] pub trait IntoRawFd { /// Consumes this object, returning the raw underlying file descriptor.

#![unstable(feature = "wasi_ext", issue = "71213")] <ins> // NOTE: despite the fact that this module is unstable, // stable Rust had the capability to access the stable // re-exported items from os::fd::raw through this // unstable module. // In PR #95956 the stability checker was changed to check // all path segments of an item rather than just the last, // which caused the aforementioned stable usage to regress // (see issue #99502). // As a result, the items in os::fd::raw were given the // rustc_allowed_through_unstable_modules attribute. // No regression tests were added to ensure this property, // as CI is not configured to test wasm32-wasi. // If this module is stabilized, // you may want to remove those attributes // (assuming no other unstable modules need them). </ins> pub use crate::os::fd::raw::*;
Change:
This should instead use the interface which does not block the thread. Additionally, this should remove the functions in the file along with related definitions. This is a pretty good first project for anyone wanting to sink their teeth into some library work! It's a bit of refactoring and should result in a nice large negative diffstat!
What about calls to in ?
It seems that there is no 1-to-1 mapping of to . Particularly, the latter is missing fields, such as , and OS-specific attributes, such as on MacOS and FreeBSD. I suppose that will have to have those fields to it.
The function should not exist in that current form, and it's fine to drop fields for now. A rust should work the same on all platforms, not create different structs with different fields (very easy to miscompile on other platforms).
When I changed the implementation of in to call and then , I hit a compiler error: I do have an , but nothing extra seems to be printed. Should I file a separate issue for this?
The calls to will raise on the condition when they encounter an error. In this case it looks like the error was that a file was not found. The return value of will be , but you'll need to explicitly catch the error as well for now (and ignore it or continue to propagate it).
If it is fine to drop fields for now, I suppose we should remove tests that reference such fields. E.g. in we have for two tests: and
Both the fields in question exist in , I suppose I will just add them to then in that case.
Feel free to modify as much as you need, especially if there's information inside of on all platforms, then feel free to add it in!

Discussion:
} pub struct uv_stat_t { <del> priv st_dev: libc::uint64_t, </del> <ins> st_dev: libc::uint64_t, </ins> st_mode: libc::uint64_t, priv st_nlink: libc::uint64_t, priv st_uid: libc::uint64_t, priv st_gid: libc::uint64_t, priv st_rdev: libc::uint64_t, <del> priv st_ino: libc::uint64_t, </del> <ins> st_ino: libc::uint64_t, </ins> st_size: libc::uint64_t, priv st_blksize: libc::uint64_t, priv st_blocks: libc::uint64_t,