jiebi/CodeConvo huggingface dataset:
Change:
) } PatKind::Path(ref qpath) => { <del> self.check_pat_path(pat, qpath, expected) </del> <ins> self.check_pat_path(pat, path_resolution.unwrap(), qpath, expected) </ins> } PatKind::Struct(ref qpath, ref fields, etc) => { self.check_pat_struct(pat, qpath, fields, etc, expected, def_bm, discrim_span)

Discussion:
The following, which I expect to work, fails to infer the type of : In HIR, should correspond to: However, if we change the snippet to: it all works out fine. I also tested changing to a tuple variant and that works also. cc cc
It might be a good idea to trace the difference between and because they look relatively similar and yet they behave differently in terms of inference.
Value (/) and type () namespaces execute very different logic for type inference (/ vs ). It's quite possible that there are intended and unintended observable differences (not necessarily specific to ). checkpatpath and checkpattuplestruct Rather and . ( is the same "value" case as .)
Change:
hir::ItemFn(.., ref generics, _) => { let mut error = false; if !generics.params.is_empty() { <del> struct_span_err!(tcx.sess, generics.span, E0131, "`main` function is not allowed to have type parameters") .span_label(generics.span, "`main` cannot have type parameters") </del> <ins> let param_type = if generics.is_lt_parameterized() { "lifetime" } else { "type" }; let msg = format!("`main` function is not allowed to have {} parameters", param_type); let label = format!("`main` cannot have {} parameters", param_type); struct_span_err!(tcx.sess, generics.span, E0131, "{}", msg) .span_label(generics.span, label) </ins> .emit(); error = true; }

Discussion:
The error says type parameters when it should say lifetime parameters in this case. This is definitely a low priority issue. Might make a good first issue though?
I propose to work on that one.
Change:
if let hir::ItemKind::Impl(impl_item) = tcx.hir().item(item).kind { let mut dead_items = Vec::new(); for item in impl_item.items { <del> let did = item.id.owner_id.def_id; if !visitor.is_live_code(did) { dead_items.push(did) </del> <ins> let def_id = item.id.owner_id.def_id; if !visitor.is_live_code(def_id) { let name = tcx.item_name(def_id.to_def_id()); let hir_id = tcx.hir().local_def_id_to_hir_id(def_id); let level = tcx.lint_level_at_node(lint::builtin::DEAD_CODE, hir_id).0; dead_items.push(DeadItem { def_id, name, level }) </ins> } } <del> visitor.warn_multiple_dead_codes( &dead_items, "used", Some(item.owner_id.def_id), false, ); </del> <ins> visitor.warn_multiple(item.owner_id.def_id, "used", dead_items, false); </ins> } if !live_symbols.contains(&item.owner_id.def_id) {

Discussion:
At some point between (works) and (does not work) the following stopped compiling: I have not bisected for the exact commit that broke this. I have only tried to reproduce this error using . It's possible that this is also broken for other lints. PR:
Without properly double-checking this, I'm certain that this regressed in (merged April 14) which condensed multiple diagnostics triggered by methods into a single one for readability meddling with the affairs of . I don't know how is implemented but if it only considers the first primary span of a (buffered) lint diagnostic, then one fix will be changing the relevant part of the code to consider all primary spans. label T-compiler A-lint F-lintreasons
Change:
// CHECK-LABEL: @swap_rgb48_manually( #[no_mangle] pub fn swap_rgb48_manually(x: &mut RGB48, y: &mut RGB48) { <del> // CHECK-NOT: alloca // CHECK: %[[TEMP0:.+]] = load <3 x i16>, ptr %x, align 2 // CHECK: %[[TEMP1:.+]] = load <3 x i16>, ptr %y, align 2 // CHECK: store <3 x i16> %[[TEMP1]], ptr %x, align 2 // CHECK: store <3 x i16> %[[TEMP0]], ptr %y, align 2 </del> <ins> // FIXME: See #115212 for why this has an alloca again // CHECK: alloca [3 x i16], align 2 // CHECK: call void @llvm.memcpy.p0.p0.i64({{.+}}, i64 6, i1 false) // CHECK: call void @llvm.memcpy.p0.p0.i64({{.+}}, i64 6, i1 false) // CHECK: call void @llvm.memcpy.p0.p0.i64({{.+}}, i64 6, i1 false) </ins> let temp = *x; *x = *y;

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. --Nearly 50% performance regression between versions 1.71 and 1.72 when copying small byte arrays with platform (Macbook Pro M1). Used to track down the regression to I tried this code: I expected to see this happen: to run about 6,200,000 ns/iter like version 1.71 Instead, this happened: 9,159,412 ns/iter <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.71 More specifically nightly-2023-06-06-aarch64-apple-darwin 72 nightly-2023-06-07-aarch64-apple-darwin <!-- Provide the version you are using that has the regression. --: Searched nightlies: from nightly-2023-06-06 to nightly-2023-06-07 regressed nightly: nightly-2023-06-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-apple-darwin Reproduce with: </details modify labels: +regression-from-stable-to-stable -regression-untriaged
Here's a demo for :
Oof, that's massively worse. But even with a nice size (), it's still a small regression: We should probably revert , or limit it to very small arrays (<= 8 bytes / 1 usize? )
The original motivation of that PR is for arrays larger than that, so I'm not so sure. If I strip this down to just the pointer write it's not as bad, but it's quite clear that the problem is just x86-isel: Is that even good instruction selection?

Hmm, curiously looking at just the part of the push logic that copies the value, the assembly is entirely reasonable: then in the context of a "real" push, it somehow still blows up:
Here's a small tweak to try to fix this for 1.73:
I've opened to track the suboptimal codegen mentioned in Once a new nightly is out, please give it a shot and reopen if you're still seeing the regression.
On Ubuntu VM running on Ryzen 5950X this is far worse: 4x regression.
Things look much better with . Thanks for the quick fix!
Thanks for confirming! I'll see if it can make 1.73.
Change:
macro_rules! bootstrap_tool { ($( $name:ident, $path:expr, $tool_name:expr <del> $(,llvm_tools = $llvm:expr)* </del> $(,is_external_tool = $external:expr)* <ins> $(,is_unstable_tool = $unstable:expr)* </ins> $(,features = $features:expr)* ; )+) => {

Discussion:
See . Unfortunately the "fix" to that bug breaks the build when building using 1.31.0 and you have to unapply the patch to make it work against 1.31.0. e.g. from : ~ The problem here is that if stage0 is 1.31.0 then the patch MUST be unapplied, if stage0 is 1.32.0 then the patch MUST be applied. Obviously we can't do both at once. However in both Debian and Fedora we occasionally use either the current or the previous version of rustc to build a given version of rustc, and both of these versions should work. cc
Doing things this way (using stage2) would also have ensured that was detected early, and never made it into a release.
We would prefer to build tools such as compiletest with the bootstrap compiler because stage1, stage2 compilers take a long time to build. I think largely we just can't at this point support building with multiple compilers -- i.e., the bootstrap compiler should be the same one we use in tree. We just don't have the CI budget and resources to test and support multiple versions of the compiler for crates using unstable features. As such, I think the only resolution here will be to close this... cc and though since this is somewhat of a policy type decision (and we don't have a firm policy AFAIK).
As a matter of policy, we do need such rebuild-bootstrapping to continue to be supported to some extent, even if it's only a "tier-2" use case. That is, fixing these sort of issues reactively is still better than nothing.
Is conditional compilation based on the compiler version possible in Rust today? That could be an alternative solution, instead of always using stage2. The language is a bit technical and I couldn't figure it out.
I guess for now, I could hack that sort of logic into the Debian build script manually in an ad-hoc way - applying the patch vs not, based on the stage0 compiler version.

I think if we wanted to solve this issue the best way to do it would be to: Require compiles on stable, except for the dependency on the crate Have depend on std/test in-tree binaries, so we always build them (with the stage0 compiler) That way works with rebuild-bootstraping and normal use cases because it's not using anything unstable except libtest, which is built from source to link against and already solves this problem otherwise.
I think in general a policy of unstable tools/dependencies having the requirement of being in-tree deps instead of beta is reasonable, yeah. I can try to make a patch that makes compiletest (and if there are any other such tools) do this sometime this week.
Same issue with 1.40.0 again, when using itself as stage0: ~ CC AFAICT you do not have a patch that fixes this on Fedora either.
For 1.40.0 the relevant commit to conditionally-apply or not is . For the upcoming 1.41.0 (or is it 1.42.0) stable release it seems we will have to do the same thing for .
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 DigitCollection: Sized { type Iter: Iterator<Item = u8>; fn digit_iter(self) -> Self::Iter; fn digit_sum(self) -> u32 { self.digit_iter() .map(|digit: u8| digit as u32) .fold(0, |sum, digit| sum + digit) } } impl<I> DigitCollection for I where I: Iterator<Item=u8> { type Iter = I; fn digit_iter(self) -> I { self } } fn main() { let xs = vec![1u8, 2, 3, 4, 5]; assert_eq!(xs.into_iter().digit_sum(), 15); } </ins>

Discussion:
That's a mouthful! To exemplify: This doesn't compile with , even though it does without it. Note that the only difference between the two configurations is that the function on is a free function instead of a default method. With , this fails with: Tested on
cc me
I've been running into very similar errors all day while updating my libs to the latest nightly. Here's an example of a method that works fine along with one that does not (simplest example I could come up with).
This example works now. I think this was a dup of
I just updated to master and I'm still running into the same error - perhaps my error is a separate issue?
Edwardw's PR does seem to fix my issue however, perhaps it addresses something extra?
The original issue is still present if the example on the first post is compiled with . I tested on , which contains Edit: just compiled . Still reproducible
Change:
/// consolidate multiple unresolved import errors into a single diagnostic. fn finalize_import(&mut self, import: &'b Import<'b>) -> Option<UnresolvedImportError> { let orig_vis = import.vis.replace(ty::Visibility::Invisible); <ins> let orig_blacklisted_binding = match &import.kind { ImportKind::Single { target_bindings, .. } => { Some(mem::replace(&mut self.r.blacklisted_binding, target_bindings[TypeNS].get())) } _ => None, }; </ins> let prev_ambiguity_errors_len = self.r.ambiguity_errors.len(); let path_res = self.r.resolve_path( &import.module_path,

Discussion:
Reproduction code: If I re-export in the module, it works as expected, having enum in the type-namespace and variant in the value-namespace ().
Compiler team check-in: I'm marking this as P-medium for now as it is not classified as a regression, although it seems like a fairly major problem. appears to be on it, though.
Feel free to add the I-nominated label if you think it should be P-high
late last year. could you take a look at this to see if it is valid for the invariant being checked not to hold in this case? If I comment out the the output is reasonable:
I'll see what happens (that's why I self-assigned). The assert is there to catch the cases that resolve logic assumes to be impossible. It may work ok if the assert is removed, but it may also mean some deeper issues, this needs a more detailed look.
The above error message without the looks a lot like and .
but it may also mean some deeper issues was exactly the case here! Thank you for reporting. Fixed in
Change:
<ins> error[E0425]: cannot find function `missing` in this scope --> $DIR/no-fallback-multiple-impls.rs:12:5 | LL |     missing(); |     ^^^^^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </ins>

Discussion:
When I run this code (via ): I get the output I expected (i.e., a single line of output that says "My number is 42"). However, if I run this code (via the same with no other changes): I get two compiler errors. The first error indicates that is not in scope - this makes sense, I have not defined anywhere. However, the second error indicates (provided below) does not make sense: It appears that, when there are no other compiler issues, the compiler can infer a type for just fine. However, as soon as any other compiler issue appears, it loses the ability to infer type. That doesn't make sense to me - the ability to infer type should be unrelated to any other compiler errors present. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I partially fixed this for and in , but not in general. I am dissatisfied with this error message. I'll look into fixing it. claim
Change:
} #titles > button:hover, #titles > button.selected { <ins> background-color: #ffffff; </ins> border-top-color: #0089ff; <del> background-color: #353535; </del> } #titles > button > div.count {

Discussion:
The rustdoc search results page has three tabs of results: "In Names", "In Parameters", and "In Return Types". In my browser with the default theme, the selected tab heading is drawn in black on black. !
modify labels +T-rustdoc +A-rustdoc-ui +regression-from-stable-to-nightly
Yes, I've been having this too. You beat me to reporting this bug and ; thank you for making good reports!
I did some bisection and it seems the most likely cause is .
Ah, I think I know what the issue is.
Labeled as P-medium since I made the fix and it's in the bors queue.
Change:
{ lhs = *lhs_value; rhs = *rhs_value; <del> if let Some(op) = self.try_as_operand(lhs, location) { *lhs_operand = op; } if let Some(op) = self.try_as_operand(rhs, location) { *rhs_operand = op; </del> <ins> if let Some(lhs_op) = self.try_as_operand(lhs, location) && let Some(rhs_op) = self.try_as_operand(rhs, location) { *lhs_operand = lhs_op; *rhs_operand = rhs_op; </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. --Compiling the following code with results in ICE. Strangely, this code compiles fine without . Replace with plain comparison also works. : <!-- 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
This seems to bisect to cc
Thanks for the ping! I'll take a look. I thought I'd checked for this with , but clearly I missed something.
Change:
} self.suggest_bare_struct_literal(&mut err); <del> self.suggest_pattern_match_with_let(&mut err, source, span); </del> <ins> if self.suggest_pattern_match_with_let(&mut err, source, span) { // Fallback label. err.span_label(base_error.span, &base_error.fallback_label); return (err, Vec::new()); } </ins> self.suggest_self_or_self_ref(&mut err, path, span); self.detect_assoct_type_constraint_meant_as_path(&mut err, &base_error);

Discussion:
Given the following code: The current output is: Ideally the output should look like: How do we remove other diagnostics in this scenario?
label +D-verbose
Change:
<ins> error[E0107]: missing generics for associated type `Trait::Assoc` --> $DIR/elided-in-expr-position.rs:10:26 | LL |     fn g(&self) -> Self::Assoc; |                          ^^^^^ expected 1 lifetime argument | note: associated type defined here, with 1 lifetime parameter: `'a` --> $DIR/elided-in-expr-position.rs:5:10 | LL |     type Assoc<'a> where Self: 'a; |          ^^^^^ -- help: add missing lifetime argument | LL |     fn g(&self) -> Self::Assoc<'_>; |                          ~~~~~~~~~ error[E0107]: missing generics for associated type `Trait::Assoc` --> $DIR/elided-in-expr-position.rs:32:26 | LL |     fn g(&self) -> Self::Assoc { |                          ^^^^^ expected 1 lifetime argument | note: associated type defined here, with 1 lifetime parameter: `'a` --> $DIR/elided-in-expr-position.rs:5:10 | LL |     type Assoc<'a> where Self: 'a; |          ^^^^^ -- help: add missing lifetime argument | LL |     fn g(&self) -> Self::Assoc<'_> { |                          ~~~~~~~~~ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0107`. </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. --I tried this code: I expected to see this happen: the lifetime is correctly inferred when using Instead, this happened: I have to use one of the work arounds described in the linked code. Swap from GAT lifetime to the trait parameterized by a lifetime it works: <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Interested in fixing this. I think all we need to do is treat like other paths with elided lifetimes (e.g. ). you're the go-to person for GATs, right? If so, does that sound correct? Secondly I might also put up a PR that suggests adding when parsing since that's also what's wrong with the second solution. claim
ah yes, good catch, the second solution does work with . In the way I had originally encountered this it didn't work without more nightly features () - a GAT, on a trait, on a , which parametrized a trait. Which left the type alias way the only way around.
I don't know if I've looked at this code before. But seems about right. I'm wondering if something like works and there's just code somewhere that doesn't take into account that the associated type itself can have substs.
This might be a little bit difficult though. When using a concrete struck like , we can infer that lifetime because we know how it's used in the struct itself. With associated types, we don't know, necessarily. In a way, I would expect that to be somewhat opaque, tbh. I'm not sure how I feel about this tbh. If you can fix it, I'd probably want to get some second thoughts before merging.
Change:
cached_block: None }); return; <del> } else { // We must invalidate all the cached_blocks leading up to the scope we’re looking // for, because otherwise some/most of the blocks in the chain will become // incorrect. scope.invalidate_cache(); </del> } } span_bug!(span, "extent {:?} not in scope to free {:?}", extent, value);

Discussion:
This was discovered in database connection pooling where connections were not returned to the pool properly, and reported under Unfortunately I do not have example code small enough to share at this point. I narrowed down the rust-nightly version that introduced the bug to nightly-2016-08-03-x86_64-unknown-linux-gnu
when compiled with RUSTFLAGS="-Zorbit=off" the issue does not appear, so yes it is the MIR as suspected.
The compiler not running drop glue is not considered unsafe behaviour (i.e. it is allowed to happen), but it is still weird this happens. cc could be your drop elaboration not catching this () case? Something that we could run without having postgresql installed would be ideal test case, even if it depended on other crates for now.
Minimal reproduction:
More minimal: Removing either of early s in the function makes the issue go away. Seems like a scoping issue.
regression-from-stable-to-nightly (for a two more days at least).
Yeah I jumped the gun on the tag, but the beta is building right now.
I saw your commit -- I feel like the extent should be unique for the cleanup scope. That is, we should push a given extent only once -- but perhaps I am wrong about this? It'd be good to add an assertion (or warning) for when we push cleanup scopes with the same extent more than once so we can see what it happens.
Ah, but reading IRC chatter I see that the problem is that the extent of the "outermost scope" changed and thus the helper is out of date? That seems pretty plausible.
As pointed out on the IRC the commit linked above is a shot in the dark and is not a fix.
Change:
trait_selection_closure_kind_requirement = the requirement to implement `{$trait_prefix}{$expected}` derives from here <ins> trait_selection_disallowed_positional_argument = positional format arguments are not allowed here .help = only named format arguments with the name of one of the generic types are allowed in this context </ins> trait_selection_dump_vtable_entries = vtable entries for `{$trait_ref}`: {$entries} trait_selection_empty_on_clause_in_rustc_on_unimplemented = empty `on`-clause in `#[rustc_on_unimplemented]`

Discussion:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?