jiebi/CodeConvo huggingface dataset:
Change:
pub fn uv_tcp_init(l: *mut uv_loop_t, h: *mut uv_tcp_t) -> c_int; pub fn uv_tcp_connect(c: *mut uv_connect_t, h: *mut uv_tcp_t, addr: *const sockaddr, cb: uv_connect_cb) -> c_int; <del> pub fn uv_tcp_bind(t: *mut uv_tcp_t, addr: *const sockaddr) -> c_int; </del> <ins> pub fn uv_tcp_bind(t: *mut uv_tcp_t, addr: *const sockaddr, flags: c_uint) -> c_int; </ins> pub fn uv_tcp_nodelay(h: *mut uv_tcp_t, enable: c_int) -> c_int; pub fn uv_tcp_keepalive(h: *mut uv_tcp_t, enable: c_int, delay: c_uint) -> c_int; pub fn uv_tcp_simultaneous_accepts(h: *mut uv_tcp_t, enable: c_int) -> c_int; <del> pub fn uv_tcp_getsockname(h: *mut uv_tcp_t, name: *mut sockaddr, </del> <ins> pub fn uv_tcp_getsockname(h: *const uv_tcp_t, name: *mut sockaddr, </ins> len: *mut c_int) -> c_int; <del> pub fn uv_tcp_getpeername(h: *mut uv_tcp_t, name: *mut sockaddr, </del> <ins> pub fn uv_tcp_getpeername(h: *const uv_tcp_t, name: *mut sockaddr, </ins> len: *mut c_int) -> c_int; // udp bindings

Discussion:
For example, this program prints on unix, and on windows:
The appears to be different on windows for both libgreen and libnative.
I believe this happens because the arguments end up being quoted for Windows. Simplest fix would be to drop empty arguments. Thoughts?
(Alternatively, we could quote empty arguments on Unix.)
I would expect the empty arguments to be passed through as significant argument position. I ran into this in cargo because passed on unix but on windows it would try to consume the next argument for the test args. It looks like to fix this we just need to alter to see if the argument is 0-length, and if so we quote it. Libuv already does . I'm investigating a fix for libgreen, it looks like it should be working...
Change:
}; if !type_is_zero_size(ccx, result_ty) { <del> let repr = adt::represent_type(ccx, result_ty); </del> match args { callee::ArgExprs(exprs) => { let fields = exprs.iter().map(|x| *x).enumerate().collect::<Vec<_>>(); <del> bcx = expr::trans_adt(bcx, &*repr, disr, fields.as_slice(), </del> <ins> bcx = expr::trans_adt(bcx, result_ty, disr, fields.as_slice(), </ins> None, expr::SaveIn(llresult)); } _ => ccx.sess().bug("expected expr as arguments for variant/struct tuple constructor")

Discussion:
The current translation for struct update in the case of ignore looks incorrect. It should only move those fields that are not specified manually. This can mean the difference between moving the base as a whole and not. Probably the easiest thing to do is to create an alloca, use the same code as the normal path, and just drop the alloca afterwards.
See FIXME.
visiting for triage. nominating for production ready.
Accepted for production-ready
visting for triage, still relevant. FYI, the module in question is
Change:
} fn visit_variant_data(&mut self, data: &'a VariantData) { <ins> // The assumption here is that non-`cfg` macro expansion cannot change field indices. // It currently holds because only inert attributes are accepted on fields, // and every such attribute expands into a single field after it's resolved. </ins> for (index, field) in data.fields().iter().enumerate() { <del> if field.is_placeholder { self.visit_macro_invoc(field.id); continue; </del> <ins> self.collect_field(field, Some(index)); if field.is_placeholder && field.ident.is_none() { self.definitions.placeholder_field_indices.insert(field.id, index); </ins> } <del> let name = field.ident.map(|ident| ident.name) .unwrap_or_else(|| sym::integer(index)); let def = self.create_def(field.id, DefPathData::ValueNs(name.as_interned_str()), field.span); self.with_parent(def, |this| visit::walk_struct_field(this, field)); </del> } }

Discussion:
Stable, and nightly-2019-09-09: nightly-2019-09-10: Mentioning because this is likely from .
Yeah, this is some known shortcut taken in , sorry. Didn't expect people to hit it that fast. Will fix ~this weekend.
Thanks. The realistic usage where this appears is if you forget to import a derive macro, which happens commonly.
Un-nominating since Vadim self-assigned.
triage: P-high.
Fixed in
Change:
} } <del> span_bug!( </del> <ins> // Errors in earlier passes can yield error variables without // resolution errors here; delay ICE in favor of those errors. self.tcx().sess.delay_span_bug( </ins> self.var_infos[node_idx].origin.span(), <del> "collect_error_for_expanding_node() could not find  error for var {:?} in universe {:?}, lower_bounds={:#?},  upper_bounds={:#?}", node_idx, node_universe, lower_bounds, upper_bounds ); </del> <ins> &format!("collect_error_for_expanding_node() could not find  error for var {:?} in universe {:?}, lower_bounds={:#?},  upper_bounds={:#?}", node_idx, node_universe, lower_bounds, upper_bounds)); </ins> } fn collect_concrete_regions(

Discussion:
The following code results in an ICE on stable, beta, and nightly () Errors:
thanks to for providing a ICE appears to have been injected between 1.32.0 and 1.33.0. We could obviously use further bisection.
triage: P-high, removing nomination, marking needs-bisect, and assigning to self.
ICE was injected between nightly-2019-01-03 ( 2019-01-02) and nightly-2019-01-04 ( 2019-01-03). We did not have many PR's merged in that time frame, just these: Based on past experience, I'm guessing this is due to the Universes PR .
I'm going to take a shot at just turning the current call into a and see where that gets us.
Change:
/// /// # Example /// <del> /// ``` </del> <ins> /// ```ignore(cannot-test-this-because-non-exported-macro) </ins> /// cfg_if! { ///     if #[cfg(unix)] { ///         fn foo() { /* unix specific functionality */ }

Discussion:
At present, doctests aren't run on macros that are not annotated with . After , it will become possible to fix this problem. However, doing so will cause tests to run that were skipped previously to run, which will likely cause test failures and may mess up people's CI. It might be helpful to provide some form of warning period first. The relevant code is here: Fixing this issue technically just requires removing that special case. However, things are complicated by the fact that this will cause people's tests to suddenly fail. I'm not really sure how we should handle that. do you have any ideas? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
See also https://rust-
I think we should just change this; it's no different than in that the code was already broken before and we just didn't happen to run it. If you're really worried we can do a crater run but I would honestly be ok with just landing this.
label +E-easy +E-mentor
Looks like accidentally prevented these doctests from being run even if is passed :(
claim
FYI, rayon has an internal macro with an example that wasn't ready to be treated as a test: ... discovered by failing in a .
Hmm, I'm not even sure how to turn that into a working doctest, because the macro isn't exported. The in is also telling -- then what's the point?
Change:
<ins> // #120427 // This test checks we won't suggest more than 3 span suggestions for cfg names // // check-pass // compile-flags: -Z unstable-options // compile-flags: --check-cfg=cfg(foo,values("value")) --check-cfg=cfg(bar,values("value")) --check-cfg=cfg(bee,values("value")) --check-cfg=cfg(cow,values("value")) #[cfg(value)] //~^ WARNING unexpected `cfg` condition name: `value` fn x() {} fn main() {} </ins>

Discussion:
The user wanted something with "linux", and there is a name-value cfg that has the value "linux", so they probably wanted that. No response
Change:
<ins> #![feature(start)] #[start] #[track_caller] //~ ERROR `start` is not allowed to be `#[track_caller]` fn start(_argc: isize, _argv: *const *const u8) -> isize { panic!("{}: oh no", std::panic::Location::caller()); } </ins>

Discussion:
Crash occurs in both 1.46.0 beta and in current nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I made the false assumption that this was rustc crashing, but it's actually the binary that crashes upon running it.
Cc We probably just want to ban track caller on main (and maybe any lang item function?)
claim
Same with : results in edit: I think is a more general problem so I won't change that here
Assigning as and removing .
Change:
.code-header { color: #e6e1cf; } <del> pre > code { </del> <ins> .docblock pre > code, pre > code { </ins> color: #e6e1cf; } span code {

Discussion:
My guess is that the yellow inline code style is incorrectly being applied to code blocks too. ! !
cc since you're knowledgeable about rustdoc's CSS
I'll send a fix shortly.
looks to be the likely cause. searched nightlies: from nightly-2021-07-01 to nightly-2021-08-25 regressed nightly: nightly-2021-08-20 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Change:
err: &mut Diag<'_>, item_def_id: DefId, hir_id: hir::HirId, <del> rcvr_ty: Ty<'_>, </del> <ins> rcvr_ty: Option<Ty<'_>>, </ins> ) -> bool { let hir_id = self.tcx.parent_hir_id(hir_id); let Some(traits) = self.tcx.in_scope_traits(hir_id) else { return false };

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unexpected non-type Node::GenericParam: Type { default: None, synthetic: false }', 'error: internal compiler error: unexpected non-type Node::GenericParam: Type { default: None, synthetic: false }' 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: [typeof] computing type of [typeck] type-checking --
mvce:
:thinking: cc
I'm gonna assume that it is this line that needs additional logic:
Change:
.args(["-m", "unittest", "bootstrap_test.py"]) .env("BUILD_DIR", &builder.out) .env("BUILD_PLATFORM", builder.build.build.triple) <ins> .env("BOOTSTRAP_TEST_RUSTC_BIN", &builder.initial_rustc) .env("BOOTSTRAP_TEST_CARGO_BIN", &builder.initial_cargo) </ins> .current_dir(builder.src.join("src/bootstrap/")); // NOTE: we intentionally don't pass test_args here because the args for unittest and cargo test are mutually incompatible. // Use `python -m unittest` manually if you want to pass arguments.

Discussion:
I tried this with Rust 1.66.0, simplified from my build for Fedora: I expected to see this happen: passing tests Instead, this happened: 20 failures, all of this sort: My stage0 should be using . It most recently worked on: Rust 1.65.0 : I bisected this to , commit , which stopped using and environment variables when building a . <details<summaryBacktrace</summary<p</p</details modify labels: +regression-from-stable-to-stable -regression-untriaged +A-bootstrap <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
FYI we had the same problem on Debian, worked around with a custom patch:
Change:
} fn print_tuple_struct_fields(w: &mut Buffer, cx: &Context<'_>, s: &[clean::Item]) { <del> for (i, ty) in s .iter() .map(|f| if let clean::StructFieldItem(ref ty) = *f.kind { ty } else { unreachable!() }) .enumerate() { </del> <ins> for (i, ty) in s.iter().enumerate() { </ins> if i > 0 { w.write_str(",&nbsp;"); } <del> write!(w, "{}", ty.print(cx)); </del> <ins> match *ty.kind { clean::StrippedItem(box clean::StructFieldItem(_)) => w.write_str("_"), clean::StructFieldItem(ref ty) => write!(w, "{}", ty.print(cx)), _ => unreachable!(), } </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. --panics when running . This seems to come from cc <!-- 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
what is that attribute intended to do? Enum fields are always public.
I wanted to hide the field from docs because it was not important. But I agree it's probably a bit strange.
Assigning priority as in the prioritization working group.
Change:
fn assemble_inherent_candidates_from_param(&mut self, param_ty: ty::ParamTy) { // FIXME: do we want to commit to this behavior for param bounds? <ins> debug!("assemble_inherent_candidates_from_param(param_ty={:?})", param_ty); </ins> let bounds = self.param_env.caller_bounds.iter().filter_map(|predicate| match *predicate { ty::Predicate::Trait(ref trait_predicate, _) => {

Discussion:
When a trait alias to a trait with a method with the same name as a method on a struct is in scope, rustc is suddenly unable to disambiguate the trait method from the struct method.
cc
cc and -- Is importing the trait with higher priority than inherent items?
Is importing the trait with higher priority than inherent items? It shouldn't do that, looks like a bug. A method introduced into scope via trait alias (import) should behave identically to methods introduced with a trait (import), that means lower priority than inherent items.
Change:
self.fix_bin_or_dylib("{}/bin/rustc".format(bin_root)) self.fix_bin_or_dylib("{}/bin/rustdoc".format(bin_root)) <del> self.fix_bin_or_dylib("{}/bin/cargo".format(bin_root)) </del> lib_dir = "{}/lib".format(bin_root) for lib in os.listdir(lib_dir): if lib.endswith(".so"):

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: x.py patches stage0/cargo Instead, this happened: x.py tries to patch ci-rustc/cargo, fails, and never patches stage0/cargo, causing a build failure. In particular, does not exist: and stage0/bin/cargo is never patched.
Hmm this seems to be related to caching somehow - if I delete stage0/ altogether it works properly.
I was not able to replicate this :( checking out without clearing the cache didn't reproduce the bug.
And now it broke again :/ maybe it only happens on completely fresh builds?
It did try to patch cargo this time, though:
Ok, this looks suspicious: it's downloading the component, but cargo does not show up in ci-rustc/bin/cargo. I think the issue is it successfully patches stage0 cargo, extracts ci-rustc cargo to the wrong folder, overwriting the patched version, and then tries to patch the correct folder. I think the fix is to just not try to download cargo for the ci-rustc toolchain, it's not necessary in the first place.
Change:
if traits::search_for_structural_match_violation(param.hir_id, param.span, tcx, ty) .is_some() { <del> struct_span_err!( tcx.sess, hir_ty.span, E0741, "the types of const generic parameters must derive `PartialEq` and `Eq`", ) .span_label( hir_ty.span, format!("`{}` doesn't derive both `PartialEq` and `Eq`", ty), ) .emit(); </del> <ins> // We use the same error code in both branches, because this is really the same // issue: we just special-case the message for type parameters to make it // clearer. if let ty::Param(_) = ty.peel_refs().kind { // Const parameters may not have type parameters as their types, // because we cannot be sure that the type parameter derives `PartialEq` // and `Eq` (just implementing them is not enough for `structural_match`). struct_span_err!( tcx.sess, hir_ty.span, E0741, "`{}` is not guaranteed to `#[derive(PartialEq, Eq)]`, so may not be  used as the type of a const parameter", ty, ) .span_label( hir_ty.span, format!("`{}` may not derive both `PartialEq` and `Eq`", ty), ) .note( "it is not currently possible to use a type parameter as the type of a  const parameter", ) .emit(); } else { struct_span_err!( tcx.sess, hir_ty.span, E0741, "`{}` must be annotated with `#[derive(PartialEq, Eq)]` to be used as  the type of a const parameter", ty, ) .span_label( hir_ty.span, format!("`{}` doesn't derive both `PartialEq` and `Eq`", ty), ) .emit(); } </ins> } ty }

Discussion:
I tried this code: This produces the following error on rustc 1.44.0-nightly: I guess that const generics with a generic type isn't supported/allowed. If that's the case, this should be mentioned in the error message. :
The type needs to derive , not just implement them. This is because only types can be used for const generics at the moment, but we don't expose that to the user. Maybe we could improve the diagnostic here by actually mentioning .
thanks for fixing this so quickly! Is there a chance that this restriction will be lifted, so the above code compiles?
We would like to lift the restriction, but probably not in the first stabilised version of const generics, as it's not easy to get right: we need to be very careful in making sure that we don't accidentally allow unsoundness to sneak in, and there are many subtleties.
Change:
<ins> error: expected one of `!` or `::`, found keyword `const` --> $DIR/public-instead-of-pub-3.rs:3:12 | LL |     public const X: i32 = 123; |            ^^^^^ expected one of `!` or `::` | help: write `pub` instead of `public` to make the item public | LL |     pub const X: i32 = 123; |     ~~~ error: aborting due to previous error </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output on stable 1.63.0: The current output on Beta version 1.64.0-beta.6 (2022-09-09 ): The current output on Nightly version 1.65.0-nightly (2022-09-09 ): Since ( cc ) is somewhat recent the help diagnostics improvement currently is only on beta. However, the latest nightly has regressions regarding the suggestion as shown above. Hence, the output should suggest changing with as that is the desired output. Note: base issue for improved diagnostics ( -): Note: since this is technically a regression from beta to nightly, what should be the appropriate label to add? The one below this? label +regression-untriaged <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Can you please add the Rustc versions?
[Note that I don't think this should have happened at all, I wrote tests for the changed diagnostic suggestions]
I have retested the above code snippet against the current stable, beta and nightly version (I have the version numbers above) of the compiler in the official rust playground and the regression still persist. Not sure if this only occurs on the rust playground although I highly doubt it. Maybe you could look into this as the implementation of that diagnostics improvement is written by you. If you have any evidence that this regression issue is misinformed do let me know and I will happily close the issue. Thanks a lot.

Not sure if this is the cause but maybe the test you wrote in is slightly different to the above code snippet as the test uses the wrong keyword in the top-level. However, the above code snippet uses the incorrect keyword inside of a user-defined module. Hence, this may lead to a PR that potentially causes a regression in the recovery of -to not trip off a CI fail. Therefore, undetected. That being said, all those are just my guess and it may be wrong. label +E-needs-bisection
This may related to my PR:
claim
label -E-needs-bisection
Change:
//! Enforces the Rust effect system. Currently there is just one effect, /// `unsafe`. <del> use middle::ty::{ty_bare_fn, ty_closure, ty_ptr}; </del> use middle::ty; use middle::typeck::method_map; use util::ppaux; <del> use syntax::ast::{UnDeref, ExprCall, ExprInlineAsm, ExprMethodCall}; use syntax::ast::{ExprUnary, unsafe_fn, ExprPath}; </del> use syntax::ast; use syntax::codemap::Span; <del> use syntax::visit::{fk_item_fn, fk_method}; </del> use syntax::visit; <del> use syntax::visit::{Visitor,fn_kind}; use syntax::ast::{fn_decl,Block,NodeId,Expr}; </del> <ins> use syntax::visit::Visitor; </ins> #[deriving(Eq)] enum UnsafeContext {

Discussion:
As far as I understand, the str types have a pretty strong assumption that they contain valid UTF-8. Any method/function that could break this (such as ) is marked as unsafe. However, it is possible to assign random bytes in the middle of a ~str, breaking the UTF-8 invariant: I think that such assignments should only be allowed in unsafe code. Update: should also be unsafe, IMO.
I had no idea str even allowed index-assign.
forbidding it entirely could also fix the issue, but might be overkill.
Hmm... This could be tricker than just forbidding assignment because this code compiles as well
I suppose we could also forbid (in safe code) to borrow mutable references to individual bytes in a string. Similarly, I believe that should be unsafe (but does not need to be.)
I think we should just forbid index-assign and borrowing mutable references. It can still be done through unsafe methods, but doesn't need to be in the language as a feature. The only language feature we have is raw pointer dereferencing so it's nice to keep it simple.
Nominating for the backwards compatible milestone.
doesn't need to be unsafe because it passes you a raw pointer, which is unusable without
Accepted for well-defined. (Also: document what "unsafe" means, which is a separate issue.)
Change:
<ins> fn main() { let x = |a: u8, b: (usize, u32), c: fn() -> char| -> String { "I love beans.".to_string() }; //~^ NOTE: the found closure let x: fn(i32) = x; //~^ ERROR: 5:22: 5:23: mismatched types [E0308] //~| NOTE: incorrect number of function parameters //~| NOTE: expected due to this //~| NOTE: expected fn pointer `fn(i32)` //~| NOTE: closure has signature: `fn(u8, (usize, u32), fn() -> char) -> String` } </ins>

Discussion:
Here it's obvious, but when the error says that it is mismatched with and that "types differ in mutability" then I have zero chance of figuring what's going on. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim Sounds like a feature I would like to use as well.
Change:
region_scope_tree: &'tcx region::ScopeTree, expr_count: usize, kind: hir::GeneratorKind, <ins> prev_unresolved_span: Option<Span>, </ins> } impl<'a, 'tcx> InteriorVisitor<'a, 'tcx> {

Discussion:
Consider for example this code (using ): This code will fail to compile due to types which cannot be fully inferred, with an error like this: However neither of these spans are anywhere near to the real problem which is the fact that variant is not inferred for . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
assign will do some investigation here and see if they can get an idea what's going on (and maybe fix)