jiebi/CodeConvo huggingface dataset:
Change:
} // Return the nullable type this Option-like enum can be safely represented with. <del> let field_ty_abi = &tcx.layout_of(param_env.and(field_ty)).unwrap().abi; </del> <ins> let field_ty_layout = tcx.layout_of(param_env.and(field_ty)); if field_ty_layout.is_err() && !field_ty.has_non_region_param() { bug!("should be able to compute the layout of non-polymorphic type"); } let field_ty_abi = &field_ty_layout.ok()?.abi; </ins> if let Abi::Scalar(field_ty_scalar) = field_ty_abi { match field_ty_scalar.valid_range(&tcx) { WrappingRange { start: 0, end }

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
build-pass -ice in nightly-2020-07-31 commit[0] 2020-07-29: Auto merge of - richkadel:llvm-coverage-map-gen-5, r=tmandry commit[1] 2020-07-29: Auto merge of - P1n3appl3:rustdoc-formats, r=tmandry commit[2] 2020-07-30: Auto merge of - Manishearth:rollup-z2vflrp, r=Manishearth commit[3] 2020-07-30: Auto merge of - ehuss:update-cargo, r=Mark-Simulacrum commit[4] 2020-07-30: Auto merge of - oli-obk:lumberjack_disable, r=RalfJung commit[5] 2020-07-30: Auto merge of - npmccallum:naked, r=matthewjasper commit[6] 2020-07-30: Auto merge of - ecstatic-morse:const-size-align-of-val, r=oli-obk commit[7] 2020-07-30: Auto merge of - jumbatm:clashing-extern-decl, r=nagisa commit[8] 2020-07-30: Auto merge of - RalfJung:miri, r=RalfJung commit[9] 2020-07-30: Auto merge of - Manishearth:rollup-3wudwlg, r=Manishearth ERROR: no CI builds available between and
probably ?
why did you mark this as P-critical if it's a stable-to-stable regression from 2020?

Minimal:
its a regression build pass -ice which is critical according to the rustc dev guide
According to (not the dev guide, which I was confused since the dev guide doesn't really mention criteria for priority): This is a regression since like 1.47, so I don't think it necessarily needs to block a release to fix :smiley_cat:
Ah sorry that's what i meant, right guess its p high then.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
match tcx.def_kind(id) { DefKind::Impl { .. } => false, DefKind::AssocConst | DefKind::AssocFn => !matches!(tcx.associated_item(id).container, AssocItemContainer::ImplContainer), <del> DefKind::Struct => struct_all_fields_are_public(tcx, id.to_def_id()), </del> <ins> DefKind::Struct => struct_all_fields_are_public(tcx, id.to_def_id()) || has_allow_dead_code_or_lang_attr(tcx, id).is_some(), </ins> _ => true }) .map(|id| (id, ComesFromAllowExpect::No))

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. --nothing The original code didn't have the , which was because of the "never constructed" deadcode lint, which I guess would be . Adding a constructor does make the function never used errors go away, so it seems doesn't have enough power. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
WG-prioritization assigning priority (). label -I-prioritize +P-medium
bisected to </detailscc
like
is about the struct itself, and there's a allow(unused). This is about the side effects.
Oh, I see. claim
Change:
// See issue #59123 for a full explanation. // edition:2018 <ins> // ignore-wasm32 issue #62807 </ins> #![feature(generators, generator_trait)]

Discussion:
With the change in function shouldrunsuccessfully() of commit : RunPass =true, Ui == Some(PassMode::Run), RunPass | Ui =self.effectivepass_mode() == Some(PassMode::Run), The test cases under run-pass directory are tested for building only, the compiled test cases are not running any more. Does it work as design?
Oh. This is bad. Will fix today. cc (on vacation)
Fixed in
Change:
} debug!("note_type_err(diag={:?})", diag); <ins> enum Mismatch<'a> { Variable(ty::error::ExpectedFound<Ty<'a>>), Fixed(&'static str), } </ins> let (expected_found, exp_found, is_simple_error) = match values { <del> None => (None, None, false), </del> <ins> None => (None, Mismatch::Fixed("type"), false), </ins> Some(values) => { let (is_simple_error, exp_found) = match values { ValuePairs::Types(exp_found) => {

Discussion:
Causes the following error: This is somewhat confusing, especially since is not a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This looks similar to what I reported in
Here we don't account for anything other than type mismatches which means that later we use the generic prefix We need to account for in the first snippet and ferry the prefix strings from there to the later (instead of what we do now).
I'd like to work on this claim
do not hesitate to reach out if you need help!
Do we need to get the correct prefix strings from the contents of or are they just ?
I believe they can be just "trait".
Change:
#[lang="return_to_mut"] #[inline(always)] pub unsafe fn return_to_mut(a: *u8) { <del> let a: *mut BoxRepr = transmute(a); (*a).header.ref_count &= !FROZEN_BIT; </del> <ins> // Sometimes the box is null, if it is conditionally frozen. // See e.g. #4904. if !a.is_null() { let a: *mut BoxRepr = transmute(a); (*a).header.ref_count &= !FROZEN_BIT; } </ins> } #[lang="check_not_borrowed"]

Discussion:
This segfaults.
Reproduced. I'll take a stab at it.
Hmm, I'm not sure if this should even be legal (that is, whether it should be accepted by borrowck). And, the failure (which also happens when i change the pattern from to just ) is a null-dereference in . I think I may be a bit out of my depth here.
I think this should be legal. Presumably we are failing to root the managed box or something like that, I'm not sure what this function is.
Fixed, just need to add the test case

This ICEs with 'tyregion() invoked on in appropriate ty: tybot' from Full output from : Sorry for making the poor compiler throw up with my bad code. :(
"Sorry for putting in effort to make your compiler better with no personal gain", you mean! :-D
Can't reproduce this anymore.
Change:
}) .collect::<Vec<_>>(); // Add the suggestion for the return type. <del> suggestions.push(( ret_ty.span, format!("Box<{}{}>", if has_dyn { "" } else { "dyn " }, snippet), )); </del> <ins> suggestions.push((ret_ty.span, format!("Box<dyn {}>", trait_obj))); </ins> err.multipart_suggestion( "return a boxed trait object instead", suggestions,

Discussion:
gives The in particular is confusing. This can be a pretty intimidating error message for someone new to async/await, when all they forgot was . I'm not sure if we can fix this without stabilizing so we can sprinkle some magic compiler dust on its error messages. Maybe there's something we can do, though. Maybe some intelligent use of type aliases in our error messages? cc
This can be handled without needing to stabilize the struct. It should act the same way that the primitive type cast suggestions do.
Some observations: There is no struct, it's a type-alias We could suggest invoking but that is a method defined only in the futures crate, which feels a bit awkward to me; I'd rather it were part of libstd We can* suggest as well ()
marking as OnDeck, since BoxFuture gets used quite often
I have a PR that suggests the right code for this: <img width="1269" alt="Screen Shot 2020-02-11 at 5 09 37 PM" src="https://user-"But if first you try : <img width="1271" alt="Screen Shot 2020-02-11 at 5 10 12 PM" src="https://user-"or : <img width="1303" alt="Screen Shot 2020-02-11 at 5 11 11 PM" src="https://user-"we will send you in a wild goose chase: <img width="946" alt="Screen Shot 2020-02-11 at 5 10 53 PM" src="https://user-"
Filed for the uncovered cases.
Change:
println!("cargo:rerun-if-changed={}", llvm_config.display()); <ins> if let Some(cfg_toml) = env::var_os("CFG_LLVM_TOML") { let cfg_path = PathBuf::from(cfg_toml); println!("cargo:rerun-if-changed={}", cfg_path.display()); } </ins> // Test whether we're cross-compiling LLVM. This is a pretty rare case // currently where we're producing an LLVM for a different platform than // what this build script is currently running on.

Discussion:
I got in my : but still seems to attempt using /usr/bin/llvm-config cc
I think that the actual behavior (from IRC) that happened here was that configuration change in , but the build script wasn't re-run. The build script should probably print out pointing at if it exists, passed through via rustbuild.
I think the build script doesn't point to with ; is it possible we could make this into an E-easy issue? I get the feeling that this would also make a decent intro into rustbuild.
Certainly! I think we'll need to pass the path of via an env var, but that shouldn't be too onerous to do in rustbuild either. If anyone's got any questions please feel free to ask!
I would like to work on this. Can I use the env var to pass the path of from ? Or or .
I think an env var would probably be the best approach. seems good, but that can be bikeshedded in the PR. Let us know if we can do anything to help!
Change:
"existential types are unstable" ); } <del> ast::ImplItemKind::Type(_) if !ii.generics.params.is_empty() => { gate_feature_post!(&self, generic_associated_types, ii.span, "generic associated types are unstable"); </del> <ins> ast::ImplItemKind::Type(_) => { if !ii.generics.params.is_empty() { gate_feature_post!(&self, generic_associated_types, ii.span, "generic associated types are unstable"); } if !ii.generics.where_clause.predicates.is_empty() { gate_feature_post!(&self, generic_associated_types, ii.span, "where clauses on associated types are unstable"); } </ins> } _ => {} }

Discussion:
Compiling this code results in no output by . But exits with 101 and does not produce any artifacts. () The error happens with: , , and -
If I set breakpoints on - It hits the first two but not the third, seemingly pointing to returning an .
The silent exit is a regression. From godbolt, #### 1.23.0 exit code = 101 #### 1.24.0–1.25.0 exit code = 101 #### 1.26.0–1.28.0(beta) No message, exit code = 101 #### 1.29.0(nightly) No message, exit code = 1
cc -- it'd be good to find out why we stopped providing any output at all here
I'm worried it might be one of my parser changes to provide better diagnostics... I would probably check for any odd looking .
It's not the parsing itself, it's that in 1.24 the feature was introduced:
do you think you see what the problem is?
Calling P-high but we don't yet have an obvious assignee. Still, seems bad that there is no diagnostic output at all! Not a good look.
The core issue is reported in However, the example here also demonstrates that clauses aren't being feature gated properly.
I've made to address the surface problem, which is that you can trigger this on stable, without declaring the feature. I thought it was better to fix that part of the problem straight away.
Narrowing it down a little more: is at this point when the clauses are defined, so something's going wrong before that point.
Change:
.into() } else { // `(T, U) -> R` <del> let (inputs, _) = self.parse_paren_comma_seq(|p| p.parse_ty())?; </del> <ins> let prev_token_before_parsing = self.prev_token.clone(); let token_before_parsing = self.token.clone(); let mut snapshot = None; if self.may_recover() && prev_token_before_parsing.kind == token::ModSep && (style == PathStyle::Expr && self.token.can_begin_expr() || style == PathStyle::Pat && self.token.can_begin_pattern()) { snapshot = Some(self.create_snapshot_for_diagnostic()); } let (inputs, _) = match self.parse_paren_comma_seq(|p| p.parse_ty()) { Ok(output) => output, Err(mut error) if prev_token_before_parsing.kind == token::ModSep => { error.span_label( prev_token_before_parsing.span.to(token_before_parsing.span), "while parsing this parenthesized list of type arguments starting here", ); if let Some(mut snapshot) = snapshot { snapshot.recover_fn_call_leading_path_sep( style, prev_token_before_parsing, &mut error, ) } return Err(error); } Err(error) => return Err(error), }; </ins> let inputs_span = lo.to(self.prev_token.span); let output = self.parse_ret_ty(AllowPlus::No, RecoverQPath::No, RecoverReturnSign::No)?;

Discussion:
Given an invalid call such as: The following diagnostic is issued: This gets much worse on multiline calls: Which just prints out a diagnostic nowhere near the error: Ideally this should mention something about either missing a missing turbofish (e.g. ), or a missing identifier (e.g. ). This would at least get the error pointing to the correct spot. Latest playground nightly (2024-02-09) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oh, wow, it didn't even occur to me until now that the expression is syntactically valid .< Edit: Wow, even is syntactically well-formed.
This should pretty easy to fix, basically if we fail to parse a type here we should first of all attach a label to the saying something akin to while parsing this list of parenthesized type arguments starting here and we should suggest removing the trailing path separator if the is , the parenthesized generics aren't followed by or and if the list of non-types we encountered can be successfully parsed as a list of expressions (using a snapshot parser). Furthermore, if the is we can try to reparse the list as a list of patterns and provide the same structured suggestion. I will gladly mentor & review any PR for this.
claim
Hello , is this issue still open for mentoring? I can see that already claimed the issue, but there seems to be no progress.
I read the code but no time to finish it at the moment. You can do it.
Change:
"binary operation `{}` cannot be applied to type `{}`", hir_util::binop_to_string(op.node), lhs_ty); <ins> let missing_trait = match op.node { hir::BiAdd    => Some("std::ops::Add"), hir::BiSub    => Some("std::ops::Sub"), hir::BiMul    => Some("std::ops::Mul"), hir::BiDiv    => Some("std::ops::Div"), hir::BiRem    => Some("std::ops::Rem"), hir::BiBitAnd => Some("std::ops::BitAnd"), hir::BiBitOr  => Some("std::ops::BitOr"), hir::BiShl    => Some("std::ops::Shl"), hir::BiShr    => Some("std::ops::Shr"), hir::BiEq | hir::BiNe => Some("std::cmp::PartialEq"), hir::BiLt | hir::BiLe | hir::BiGt | hir::BiGe => Some("std::cmp::PartialOrd"), _             => None }; if let Some(missing_trait) = missing_trait { span_note!(fcx.tcx().sess, lhs_expr.span, "an implementation of `{}` might be missing for `{}`", missing_trait, lhs_ty); } </ins> } } fcx.tcx().types.err

Discussion:
The error should give a note that the PartialEq trait might be missing. In the example below, I couldn't spot for a very long time why the Result<T, StringLikeTypewas working but my own error type failed with the error above. Rust beginners like me would enjoy such hints and save time finding simple problems. Relevant code: : rustc 1.5.0-nightly ( 2015-10-03)
Change:
<ins> error[E0407]: method `unresolved` is not a member of trait `MyTrait` --> $DIR/unresolved-trait-impl-item.rs:11:5 | LL |     async fn unresolved(&self) {} |     ^^^^^^^^^----------^^^^^^^^^^ |     |        | |     |        help: there is an associated function with a similar name: `resolved` |     not a member of trait `MyTrait` error[E0324]: item `RESOLVED_WRONG` is an associated method, which doesn't match its trait `MyTrait` --> $DIR/unresolved-trait-impl-item.rs:12:5 | LL |     const RESOLVED_WRONG: u8 = 0; |     ----------------------------- item in trait ... LL |     async fn RESOLVED_WRONG() {} |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ does not match trait error: aborting due to 2 previous errors Some errors have detailed explanations: E0324, E0407. For more information about an error, try `rustc --explain E0324`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' File: --auto-reduced (treereduce-rust): original: Version 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: [visibility] computing visibility of [effectivevisibilities] checking effective visibilities [checkmoditem_types] checking item types in top-level module [analysis] running analysis passes on this crate --
Regression in ping
Fixed in
Change:
); let trait_ref = ty::TraitRef::from_method(tcx, trait_id, rcvr_substs); <del> let vtbl = tcx.codegen_fulfill_obligation((param_env, ty::Binder::bind(trait_ref))); </del> <ins> let vtbl = tcx.codegen_fulfill_obligation((param_env, ty::Binder::bind(trait_ref)))?; </ins> // Now that we know which impl is being used, we can dispatch to // the actual function:

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on stable, beta, and nightly.
This regressed in .
cc
triage: already has fix in pipeline. P-high. removing nomination label.
Change:
let unsized_part = tcx.struct_tail_erasing_lifetimes(pointee, param_env); <del> let metadata = if let Some(metadata_def_id) = tcx.lang_items().metadata_type() { </del> <ins> let metadata = if let Some(metadata_def_id) = tcx.lang_items().metadata_type() // Projection eagerly bails out when the pointee references errors, // fall back to structurally deducing metadata. && !pointee.references_error() { </ins> let metadata_ty = tcx.normalize_erasing_regions( param_env, tcx.mk_projection(metadata_def_id, [pointee]),

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. --This is a fuzzed test case, found with and minimized with , but found no similar issues. <!-- 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 --
searched nightlies: from nightly-2021-01-01 to nightly-2023-03-12 regressed nightly: nightly-2023-01-05 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsNote that this requires edition 2015/2018, as edition 2021 hard errors on the bare trait object before ever getting to layout code. cc
claim
Change:
text-overflow: ellipsis; margin: 0; } <del> .docblock-short code { </del> <ins> .docblock code, .docblock-short code { </ins> white-space: pre-wrap; }

Discussion:
In some documentation that I recently wrote, I had an inline code block that has a leading space. This is rendered as — notice the lack of a leading space. Given that the documentation in question is literally to show how a leading space is , and given that code blocks otherwise display content as-is, this seems like a bug to me. Reference for full source code in case this behavior isn't consistent:
Thanks for opening this issue I moved this issue from to as this is a rustdoc bug ( just calls rustdoc to build the documentation).
Thanks! Wasn't sure if rustdoc had its own repo.
Fix is in
Thanks
As discussed in , better keep it as is and let users decide what they want on their own.
Change:
unmatched_braces: Vec::new(), matching_delim_spans: Vec::new(), last_unclosed_found_span: None, <ins> last_delim_empty_block_spans: FxHashMap::default() </ins> }; let res = tt_reader.parse_all_token_trees(); (res, tt_reader.unmatched_braces)

Discussion:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.
Change:
})); self.add_test(desc, testfn); } <ins> fn total_len(&self) -> usize { self.tests.len() + self.benchs.len() } </ins> } pub fn run_tests<F>(

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 running benchmarks with current nightly rust: Running with the previous nightly works: Also, note the difference in the line . This happens for the benchmarks in both the and crates. looks to be related ( <!-- 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<summaryBacktrace</summary<p</p</details
Ouch. I guess libtest needs better tests. I might be able to get to this in 12 hours or so, if anyone else sees this please do take care of it.
Oof, missed that started as the full list of tests+benches before getting shadowed as only the tests. Not a fan of the way TestEvent is used to manage state (haven't ever been a fan of it, TBH), but I'll have to think a bit about how to fix it without undoing the perf wins we just got here.
Confirm the bug as well: started to fail after changing the toolset to the current nighly.
Yeah, should be fixed by . Hopefully will be in the next nightly, if we're lucky.
Change:
<ins> // check-pass #![feature(const_if_match)] enum E { A, B, C } const fn f(e: E) -> usize { match e { _ => 0 } } fn main() { const X: usize = f(E::C); assert_eq!(X, 0); assert_eq!(f(E::A), 0); } </ins>

Discussion:
This works; let's consider adding a test for it since it's a bit of a special case. Reported to be working in by
do you mind if I add this? My laptop is no longer broken ^^ so I can actually get some work done without disappearing for a week at a time. I put this in a file called and ran , is that about the right approach?
It is, but I'd recommend using to make it go faster. Also use to just test that file. Also, I'd rename the test to not suggest ... something like .
I ran about an hour ago and that worked fine (although it took a while ^^). However, since then I updated nightly and I'm now getting compile errors when building stage 1: What am I doing wrong? Full error: (cross posted from https://rust-)