jiebi/CodeConvo huggingface dataset:
Change:
/// This will detect if any submodules are out of date an run the necessary /// commands to sync them all with upstream. fn update_submodules(&self) { <ins> struct Submodule<'a> { path: &'a Path, state: State, } enum State { // The submodule may have staged/unstaged changes MaybeDirty, // Or could be initialized but never updated NotInitialized, // The submodule, itself, has extra commits but those changes haven't been commited to // the (outer) git repository OutOfSync, } </ins> if !self.config.submodules { return } if fs::metadata(self.src.join(".git")).is_err() { return } <ins> let git = || { let mut cmd = Command::new("git"); cmd.current_dir(&self.src); return cmd }; </ins> let git_submodule = || { let mut cmd = Command::new("git"); cmd.current_dir(&self.src).arg("submodule");

Discussion:
When building from git source, the build system makes a deep clone of git submodules, even those, like or , that had been disabled with configure options. ( and respectively) Not downloading a couple hundred megabytes of data spread over tens of thousands of small files is especially important on flash devices (and slow connections).
At the very least it should probably do a shallower clone of those repos. As best I can tell, you should be able to just pass to just fine.
Yep, that would be a great start. However the gist of this report is to completely forego downloading the source trees that are never going to be used.
I've just tested your patch, having done a shallow clone first and is not cloned at all but still is. Still, a huge improvement; thanks! I also paid attention to the amount of data downloaded by fully cloning other modules, like , , etc. and it seems bootstrapping from a source snapshot is still the fastest option, requiring a 50% smaller download.
Change:
<ins> // check-pass pub struct X { pub a: i32, pub b: i32, } fn main() { const DX: X = X { a: 0, b: 0 }; const _X1: X = X { a: 1, ..DX }; let _x2 = X { a: 1, b: 2, ..DX }; const _X3: X = X { a: 1, b: 2, ..DX }; } </ins>

Discussion:
[ ] It's weird that and are allowed, but not . [ ] Even if that's intentional, the error message seems off.
The provided code compiles fine both in 1.36 and the 2019-08-12 nightly. I did a quick search through the test suite and there's none for this particular case. Marking as such. modify labels: E-needstest
Change:
run_lints!(cx, check_item, late_passes, it); cx.visit_ids(|v| v.visit_item(it)); hir_visit::walk_item(cx, it); <ins> run_lints!(cx, check_item_post, late_passes, it); </ins> }) }

Discussion:
For clippy's lint, I made use of a so I could stop clippy from linting the same macro multiple times while being reasonably fast. However, this unfortunately means the lint ignores .. attributes below the crate level. To solve this and other related problems, I propose any of allow a lint to check anything from anywhere in the analysis by moving up the parent chain to check the level allow a lint to opt out of calls for the duration of a specific node including its child nodes add methods to the {Early, Late}LintPass trait, so lints can decide themselves The third option is probably the easiest to implement, yet the most flexible. This would bring the trait closer to other stream parser implementations like SAX.
Seeing that we already have a few, _post methods, I think adding some more will be an acceptable solution here. I'll have a PR shortly.
Change:
= help: instead of using a suffixed literal (`1u8`, `1.0f32`, etc.), use an unsuffixed version (`1`, `1.0`, etc.) error: malformed `rustc_legacy_const_generics` attribute input <del> --> $DIR/invalid-rustc_legacy_const_generics-arguments.rs:32:1 </del> <ins> --> $DIR/invalid-rustc_legacy_const_generics-arguments.rs:37:1 </ins> | LL | #[rustc_legacy_const_generics] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: must be of the form: `#[rustc_legacy_const_generics(N)]` error: malformed `rustc_legacy_const_generics` attribute input <del> --> $DIR/invalid-rustc_legacy_const_generics-arguments.rs:35:1 </del> <ins> --> $DIR/invalid-rustc_legacy_const_generics-arguments.rs:40:1 </ins> | LL | #[rustc_legacy_const_generics = 1] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: must be of the form: `#[rustc_legacy_const_generics(N)]`

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimized: I think it's just that this attr ICEs when attached to methods and not functions.
claim
Change:
// additional reference of either kind. if self.inner().strong.load(atomic::SeqCst) != 1 || self.inner().weak.load(atomic::SeqCst) != 1 { <del> *self = Arc::new(self.deref().clone()) </del> <ins> *self = Arc::new((**self).clone()) </ins> } // This unsafety is ok because we're guaranteed that the pointer // returned is the *only* pointer that will ever be returned to T. Our

Discussion:
As titled. Add the following trait implementations: This allows generic code that accepts smart pointer can take references too, e.g.
cc
yes I want this :+1:
This would also allow code to be polymorphic over &T and &mut T by accepting . A huge win imho.
The branch creates some .
Change:
} } <del> fn patterns_for_variant<'p, 'tcx>( </del> <ins> fn patterns_for_variant<'p, 'a: 'p, 'tcx>( cx: &mut MatchCheckCtxt<'a, 'tcx>, </ins> subpatterns: &'p [FieldPat<'tcx>], <del> wild_patterns: &[&'p Pat<'tcx>]) -> SmallVec<[&'p Pat<'tcx>; 2]> { </del> <ins> wild_patterns: &[&'p Pat<'tcx>], is_non_exhaustive: bool, ) -> SmallVec<[&'p Pat<'tcx>; 2]> { </ins> let mut result = SmallVec::from_slice(wild_patterns); for subpat in subpatterns { <del> result[subpat.field.index()] = &subpat.pattern; </del> <ins> if !is_non_exhaustive || !cx.is_uninhabited(subpat.pattern.ty) { result[subpat.field.index()] = &subpat.pattern; } </ins> } debug!("patterns_for_variant({:#?}, {:#?}) = {:#?}", subpatterns, wild_patterns, result);

Discussion:
Say I have the following enum in crate : And I match on it in crate : The second branch is not detected to be unreachable. This is on current nightly; .
The reason for this behaviour is straightforward: reports tuple variants with non-exhaustive fields as always useful. This line was introduced in commit . I'm not quite sure what the intended semantics are so I wouldn't know how to fix it.
Please wait for to be merged before fixing this; I'm dreading having to rebase on top of the fix
cc
Change:
#[cfg(all(target_arch = "x86_64", target_os = "windows"))] pub const unwinder_private_data_size: usize = 6; <del> #[cfg(all(target_arch = "arm", not(all(target_vendor = "apple", not(target_os = "watchos")))))] </del> <ins> #[cfg(all(target_arch = "arm", not(target_vendor = "apple")))] </ins> pub const unwinder_private_data_size: usize = 20; <del> #[cfg(all(target_arch = "arm", all(target_vendor = "apple", not(target_os = "watchos"))))] </del> <ins> #[cfg(all(target_arch = "arm", target_vendor = "apple"))] </ins> pub const unwinder_private_data_size: usize = 5; #[cfg(all(target_arch = "aarch64", target_pointer_width = "64", not(target_os = "windows")))]

Discussion:
Building project using should just work, but instead it fails to link to the and symbols. The exact error is: : This worked with , I'll try to bisect it myself. label O-watchos
Ugh, don't you just love it when the culprit is yourself? It's
Change:
//     Bar<Qux> //     Foo<Bar<Qux>> //         ------- this type argument is exactly the same as the other type <del> if self.cmp_type_arg(&mut values.1, &mut values.0, path2, sub2, path1, &t1) .is_some() </del> <ins> if self.cmp_type_arg( &mut values.1, &mut values.0, path2, sub_no_defaults_2, path1, &t1, ).is_some() </ins> { return values; }

Discussion:
In , adding an parameter to the type, that defaults to induces changes to UI tests that are indicative of something that seemed to need improvement in the compiler, namely that when you have a type , errors should present instead of when they can. It turns out, the compiler does. But not consistently. The following is derived from : () This yields the following errors: See how it prints instead of the (imho) desired , but , not .
This all stems from the fact that in some cases, types are just printed out by formatting the instances, while in other cases, there is manual machinery to highlight parts of the type that handle things, and that doesn't have the default-param elimination that has.
Change:
source "$ci_dir/shared.sh" RUST_CONFIGURE_ARGS="$RUST_CONFIGURE_ARGS --enable-sccache" <del> RUST_CONFIGURE_ARGS="$RUST_CONFIGURE_ARGS --enable-quiet-tests" </del> RUST_CONFIGURE_ARGS="$RUST_CONFIGURE_ARGS --disable-manage-submodules" RUST_CONFIGURE_ARGS="$RUST_CONFIGURE_ARGS --enable-locked-deps" RUST_CONFIGURE_ARGS="$RUST_CONFIGURE_ARGS --enable-cargo-openssl-static"

Discussion:
Often when debugging travis logs it's difficult to see how long everything is taking as we only time some steps, not all. Additionally there's not a lot of information to see how long it takes between steps. It'd be awesome if we had a tool where we basically wrapped the entire build () in a process that simply prepended all stdout/stderr messages with a relative timestamp. AppVeyor does this by default (has a timestamp for each log line message) but unfortunately Travis doesn't. Apparently which ends up looking like https://travis- which is basically exactly what we'd want.
You probably just want to use from moreutils for this. (This is what Julia does.)
Change:
"functions marked #[no_mangle] should be exported" } <ins> declare_lint! { PRIVATE_NO_MANGLE_STATICS, Warn, "statics marked #[no_mangle] should be exported" } declare_lint! { NO_MANGLE_CONST_ITEMS, Deny, "const items will not have their symbols exported" } </ins> #[derive(Copy)] <del> pub struct PrivateNoMangleFns; </del> <ins> pub struct InvalidNoMangleItems; </ins> <del> impl LintPass for PrivateNoMangleFns { </del> <ins> impl LintPass for InvalidNoMangleItems { </ins> fn get_lints(&self) -> LintArray { <del> lint_array!(PRIVATE_NO_MANGLE_FNS) </del> <ins> lint_array!(PRIVATE_NO_MANGLE_FNS, PRIVATE_NO_MANGLE_STATICS, NO_MANGLE_CONST_ITEMS) </ins> } fn check_item(&mut self, cx: &Context, it: &ast::Item) {

Discussion:
Will not actually be exported in the resulting object. There are two obvious fixes, the first being to expand on my pub-not-exported lint to warn you that this will not work, the second being to fix the compiler to export the symbol with the appropriate value (Without altering the existing inlining behaviour, although it may give a more reasonable option for cases like trying to take the address of a item). Happy to work on either, although I would need a mentor for the second part.
I'm not sure what you mean by it not being exported. It might not be visible as a symbol (if you're linking with some C code or something), but you can certainly reference that item from another Rust crate.
Sorry for not being clear. That's exactly what I meant, the symbol is not visible in the resulting object. This is pretty confusing (I've been doing a lot of C(++) <-Rust lately and I'm trying to make the compiler warn people about all the things that have tripped me up)
I think the right option is to expand the lint. The whole difference between and is that the former isn't guaranteed to have a location in memory. To a C programmer it's like a variable.
Sounds totally reasonable. I'll expand the lint.
Ah, I see now. I didn't know there was a lint for on items that don't export a symbol. That explains a lot!
Change:
Ok(value) => match value.as_ref() { "always" => true, "never" => false, <del> "auto" => stdout_isatty(), </del> <ins> "auto" => stderr_isatty(), </ins> _ => early_error( ErrorOutputType::default(), &format!(

Discussion:
When debugging a large Miri trace, I like to put the trace into a file that I can analyze and search through in an editor. Unfortunately, since the recent logging changes, that leads to a lot of garbage in the file: Looks like the color escape sequences are printed even when redirecting to a file. This makes working with the logfile much harder than it was before. Is there a way to fix that? Cc
This is the fault of I should be checking for whether the terminal supports colors before activating colors
A workaround until then is to use
How can I run miri from the rust repo? (i.e. built using )
You can run the test suite with , but that's not what you were asking... that's not supported yet unfortunately:
Until then, . Some of the commands might need adjusting though as changed.
Ah, thanks! I forgot about that part of the docs :)
Hmm, I'm getting this error: I'm using the latest master rustc and the latest miri. Is miri broken right now? EDIT: Oh, I think I need .
Yeah looks like you are using the wrong stage or so. The docs are from back when stage 2 was the default...
I'm afraid the problem was not solved by that PR. When I run Miri like this locally I still get all the ANSI codes in that logfile, which makes the file very hard to work with.
Looks like the code tests , but logging goes to stderr so this is the wrong test.
Hmm, I guess I didn't notice any issues because I always redirect stderr to stdout and then view that.
Working on a fix.
Yeah, for now using to redirect both to the logfile is an okay work-around.
FYI you can view the original color with , which prints them directly to the terminal. That doesn't work in an editor, though.
Change:
/// symmetrically and transitively: if `T: PartialEq<U>` and `U: PartialEq<V>` /// then `U: PartialEq<T>` and `T: PartialEq<V>`. /// <ins> /// ## Derivable /// /// This trait can be used with `#[derive]`. When `derive`d on structs, two /// instances are equal if all fields are equal, and non equal if any fields /// are not equal. When `derive`d on enums, each variant is equal to itself /// and not equal to the other variants. /// /// ## How can I implement `PartialEq`? /// </ins> /// PartialEq only requires the `eq` method to be implemented; `ne` is defined /// in terms of it by default. Any manual implementation of `ne` *must* respect /// the rule that `eq` is a strict inverse of `ne`; that is, `!(a == b)` if and /// only if `a != b`. /// <del> /// This trait can be used with `#[derive]`. </del> <ins> /// An example implementation for a domain in which two books are considered /// the same book if their ISBN matches, even if the formats differ: /// /// ``` /// enum BookFormat { Paperback, Hardback, Ebook } /// struct Book { ///     isbn: i32, ///     format: BookFormat, /// } /// impl PartialEq for Book { ///     fn eq(&self, other: &Self) -> bool { ///         self.isbn == other.isbn ///     } /// } /// /// let b1 = Book { isbn: 3, format: BookFormat::Paperback }; /// let b2 = Book { isbn: 3, format: BookFormat::Ebook }; /// let b3 = Book { isbn: 10, format: BookFormat::Paperback }; /// /// assert!(b1 == b2); /// assert!(b1 != b3); /// ``` </ins> /// /// # Examples ///

Discussion:
I'm using s as keys in a BtreeMap. I have to look up the map ~15 million times per second (10G ethernet line rate). Ipv4Addr cmp() compiles to this on my system (linux x86-64, rustc 1.10.0-nightly ( 2016-05-21)) Which seems kinda inefficient for a thing which is basically u32. I guess part of the reason is the which converts it to an array(!) first. I copied the definition and implemented Ord like this: It's about 10 times faster on my .
Nice find! Want to send a PR for this? Looks like something that'd be more than welcome :)
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 Foo { fn answer(self); } struct NoData<T>; //~^ ERROR: parameter `T` is never used impl<T> Foo for T where NoData<T>: Foo { //~^ ERROR: overflow evaluating the requirement fn answer(self) { let val: NoData<T> = NoData; } } fn main() {} </ins>

Discussion:
Per theme in , here's a minimized example exhibiting the same ICE:
This also triggers an ICE. The error and backtrace: output of rustc --version --verbose Note that removing the where clause eliminates the error. (although it isn't used anywhere)
Yet another variant:
Slight variant:
I'm currently getting the following ICE on the latest version of : The relevant code fragments: Changing the method call to use function notation, i.e. , as indicated in did not work here.
Change:
cvt(unsafe { c::SetCurrentDirectoryW(p.as_ptr()) }).map(drop) } <del> pub fn getenv(k: &OsStr) -> io::Result<Option<OsString>> { let k = to_u16s(k)?; let res = super::fill_utf16_buf( </del> <ins> pub fn getenv(k: &OsStr) -> Option<OsString> { let k = to_u16s(k).ok()?; super::fill_utf16_buf( </ins> |buf, sz| unsafe { c::GetEnvironmentVariableW(k.as_ptr(), buf, sz) }, |buf| OsStringExt::from_wide(buf), <del> ); match res { Ok(value) => Ok(Some(value)), Err(e) => { if e.raw_os_error() == Some(c::ERROR_ENVVAR_NOT_FOUND as i32) { Ok(None) } else { Err(e) } } } </del> <ins> ) .ok() </ins> } pub fn setenv(k: &OsStr, v: &OsStr) -> io::Result<()> {

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Simplified. The other malformed-looking bytes don't matter, do they?
You are right, they don't. I should have simplified it before submit.
Going to have a go at this. If I can't figure it out, I'll either ask for help or unassign myself. claim
Still working on this, but I figured an update may be helpful. My research indicates that the two characters that are potentially problematic are and . The work that needs to be done consists of 1) updating the macro expansion functions in to error in these cases; and 2) updating the macro documentation in to mention the new errors. Edit: It just occurred to me that I also need to add UI tests. Haven't figured out where to do that yet, but I will.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I don't think just adding a check to raise error in these cases would be enough. The function shouldn't really panic (from the internals discussion). Another problem is when the OS supports this kind of environment variable. e.g. as key. would deny it while it can be valid i.e. a false positive. You should still keep your work though (and eventually open a PR) as this must be changes to which would take a while.
If this is going to be fixed upstream in in even the mid-term future, I'm not sure fixing it here makes sense. Sure, it generates an ICE, but the ICE has an unusually helpful error message.
Actually, simple solution: I'll do the fix.

Working on that now.
Was this fuzzer output? If so, which fuzzer were you using
Yes, I am using kira, a work-in-progress fuzzing tool
Have you considered sorry using structure-aware fuzzing? That could help find bugs not just in the lexer and parser, but also in the middle and back ends.
Yes, actually kira is structure-aware.
Change:
Extern functions may be called directly from Rust code as Rust uses large, contiguous stack segments like C. <del> ### Type definitions </del> <ins> ### Type aliases </ins> <del> A _type definition_ defines a new name for an existing [type](#types). Type definitions are declared with the keyword `type`. Every value has a single, </del> <ins> A _type alias_ defines a new name for an existing [type](#types). Type aliases are declared with the keyword `type`. Every value has a single, </ins> specific type; the type-specified aspects of a value include: * Whether the value is composed of sub-values or is indivisible.

Discussion:
The section of the Manual would benefit from some code examples, especially those that clarify how traits and impls interact with the new name. I find the term "type definition" confusing because this section seems to be describing what I think of as "type aliases". Aren't and also examples of "type definitions"? If so, is it worth changing this terminology?
Here are some relevant thanks to
cc
Yeah, I'm not sure what the right terminology is here. Hmm.
what do you think?
+1 for "type alias" -- much clearer.
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-64519.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>

Discussion:
<short summary of the bugI tried this code: I expected to see this happen: It should build. Instead, this happened: rustc crashed with: Possible workaround: replace with . playground: rustc version: 1.39.0-nightly 2019-09-15
cc
Also ICEs without explicit feature gate enabled :/
Change:
.filter(|&(impl_, _)| { infcx.probe(|_| { let ocx = ObligationCtxt::new_in_snapshot(&infcx); <ins> ocx.register_obligations(obligations.clone()); </ins> let impl_substs = infcx.fresh_substs_for_item(span, impl_); let impl_ty = tcx.type_of(impl_).subst(tcx, impl_substs);

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hm, maybe not really a new (this month) regression but I also can't find any obvious duplicates right now...
searched toolchains nightly-2022-11-28 through nightly-2023-05-09 Regression in nightly-2022-12-05 Regression in cc
label F-inherentassociatedtypes
I'm pretty sure this can be fixed by erasing all regions no matter their de Bruijn index via instead of . This would "regress" but eh, I guess that's fine for now.
claim