jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // revisions: cfail #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] // regression test for #77650 struct C<T, const N: core::num::NonZeroUsize>([T; N.get()]) where [T; N.get()]: Sized; impl<'a, const N: core::num::NonZeroUsize, A, B: PartialEq<A>> PartialEq<&'a [A]> for C<B, N> where [B; N.get()]: Sized, { fn eq(&self, other: &&'a [A]) -> bool { self.0 == other //~^ error: can't compare } } fn main() {} </ins>

Related discussion:
text: <!-- 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. --I'm creating this issue mainly because it seems to be a different one than the ones listed in <!-- 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 command are you running? I tried this code , but I encountered an error that doesn't have a method.
how strange, for me just causes the ice and it doesn't even come to notice that the function is missing. I just ran , and with the newest rustc () I still get the same error as above (in a new cargo project with the code copied from the playground link above).
Just ran again today and still get an ICE. Made the example a bit smaller: Output of (build also fails with the same message): Considering the rustc versions it should be the same that is currently on the playground, however there it does not cause an ICE. Maybe someone could try to reproduce this in a local environment?
can reproduce this locally, not sure why it doesn't ICE on the playground
cc -- it ICEs locally, but not on the playground
Try with ?
That indeed removes the ICE, let me just check which one of the options it is. Adding to the (or profile.release in release mode) section causes the ice to disappear.
That's even weirder. Seems like this is partly an incr-comp bug then.
Note that the ICE occurs in the incr-comp hasher (ICH): So this seems to be an incr-comp bug.
Reposting : So I removed .
Code change:
<ins> // revisions: cfail #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] // regression test for #77650 struct C<T, const N: core::num::NonZeroUsize>([T; N.get()]) where [T; N.get()]: Sized; impl<'a, const N: core::num::NonZeroUsize, A, B: PartialEq<A>> PartialEq<&'a [A]> for C<B, N> where [B; N.get()]: Sized, { fn eq(&self, other: &&'a [A]) -> bool { self.0 == other //~^ error: can't compare } } fn main() {} </ins>

Related discussion:
text: <!-- 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<details<summary<strongQuery Stack</strong</summary<p</p</details
modify labels to +requires-nightly
The following snippet gives the same ICE. The types are intentionally wrong. <details<summary<strongBacktrace</strong</summary<p</p</details<details<summary<strongQuery Stack</strong</summary<p</p</details
Triage: This is now fixed on the recent nightly, marking as E-needs-test.
Code change:
retry pip3 install awscli --upgrade --user echo "##vso[task.prependpath]$HOME/.local/bin" displayName: Install awscli (Linux) <del> condition: and(succeeded(), eq(variables['Agent.OS'], 'Linux')) </del> <ins> condition: and(succeeded(), not(variables.SKIP_JOB), eq(variables['Agent.OS'], 'Linux')) </ins> - script: pip install awscli displayName: Install awscli (non-Linux) <del> condition: and(succeeded(), ne(variables['Agent.OS'], 'Linux')) </del> <ins> condition: and(succeeded(), not(variables.SKIP_JOB), ne(variables['Agent.OS'], 'Linux')) </ins> # Configure our CI_JOB_NAME variable which log analyzers can use for the main # step to see what's going on.

Related discussion:
text: This issue is meant to track where on Travis we currently whenever the commit message looks like it updates a submodule. We should enable something similar for Azure Pipelines where whenever a PR is detected as updating a submodule (either via actually looking at the git history or at the git commit message) then we schedule the builder on the PR. The purpose of this PR build is to help weed out errors even sooner than before where we're just running a smoke tests on Linux on each PR.
Code change:
<del> Subproject commit 941968db2fd9c85788a4f971c8e425d46b4cb734 </del> <ins> Subproject commit 75a5f9236c689a547fe207a10854f0775bce7937 </ins>

Related discussion:
text: modify labels: E-easy
I think it is known that those are broken, it is tracked in the . I'm not sure if is still interested in updating the submodule. Is it in a passable state now?
Oops I know I was missing something! PR opened. Thanks
Code change:
|| self.suggest_into(err, expr, expr_ty, expected) || self.suggest_floating_point_literal(err, expr, expected) || self.suggest_null_ptr_for_literal_zero_given_to_ptr_arg(err, expr, expected) <del> || self.suggest_coercing_result_via_try_operator(err, expr, expected, expr_ty) || self.suggest_missing_unwrap_expect(err, expr, expected, expr_ty); </del> <ins> || self.suggest_coercing_result_via_try_operator(err, expr, expected, expr_ty); </ins> if !suggested { self.note_source_of_type_mismatch_constraint(

Related discussion:
text: in Dec '22 introduced a cool new feature to suggest removing the last method call if it would alleviate a type mismatch error. This is particularly using for people wrestling with issues. in Oct '23 introduced another useful feature to suggest to users that they might consider ing an or type in order to solve a type mismatch. Also very cool, and conveniently by the same author Unfortunately, in cases where a method is called, the previous check takes precedence, and the compiler suggests removing that trailing method to get the code to compile. This isn't generally that useful as the expect suggestion, and I can't think of an example where it's a better one. If you can think of one though, please put it below for me to test! surfaced this with but it's more easily demonstrated with ints. I can see two ways to fix this: the trailing method check first, but ignore and types the checks so the option type is checked first. Note that the method check has to be high in the chain as the motive is to quickly suggest removing a call, before adding a whole load of new ones. This means the check has to be one of the first I am going to work on solving it via method 2, as it feels cleaner that the method check doesn't have to know about the and check. If anyone has strong feelings on this, please let me know! Playground No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I think this suggestion for removing the method call is way too eager, as it can easily be wrong and when it's wrong it's quite confusing. Maybe it should instead say that the type was correct before the method call (which is never wrong), nudging the user towards removing the call if they know that it's not important. Instead of strongly saying that it should be removed. Alternatively, it could be special cased to known "unimportant" functions like or .
I think this brings up two issues: should the method call suggestor should do, and say. There was some discussion of this in where it was decided to keep it generic rather than special-casing, but I don't think it's done badly at the moment. Perhaps the wording could be altered?
Code change:
|| self.suggest_into(err, expr, expr_ty, expected) || self.suggest_floating_point_literal(err, expr, expected) || self.suggest_null_ptr_for_literal_zero_given_to_ptr_arg(err, expr, expected) <del> || self.suggest_coercing_result_via_try_operator(err, expr, expected, expr_ty) || self.suggest_missing_unwrap_expect(err, expr, expected, expr_ty); </del> <ins> || self.suggest_coercing_result_via_try_operator(err, expr, expected, expr_ty); </ins> if !suggested { self.note_source_of_type_mismatch_constraint(

Related discussion:
text: it should run I'll focus on the latter here, but if you have examples where removing the method call doesn't make sense we can aggregate them and see if there is a holistic solution?
Code change:
<ins> error[E0425]: cannot find function `printf` in this scope --> $DIR/seggest_print_over_printf.rs:6:5 | LL |     printf("%d", x); |     ^^^^^^ not found in this scope | help: you may have meant to use the `print` macro | LL |     print!("%d", x); |     ~~~~~~ error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </ins>

Related discussion:
text: We already translate from C-style formatting strings to Rust formatting strings when passed to the family of macros. We should also detect invalid calls from other languages that were meant to be macro calls: currently emits the dry while it could be <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Mentoring on this issue label +E-mentor
Code change:
<ins> #[deny(single_use_lifetimes)] // edition:2018 // check-pass // Prior to the fix, the compiler complained that the 'a lifetime was only used // once. This was obviously wrong since the lifetime is used twice: For the s3 // parameter and the return type. The issue was caused by the compiler // desugaring the async function into a generator that uses only a single // lifetime, which then the validator complained about becauase of the // single_use_lifetimes constraints. async fn bar<'a>(s1: String, s2: &'_ str, s3: &'a str) -> &'a str { s3 } fn foo<'a>(s1: String, s2: &'_ str, s3: &'a str) -> &'a str { s3 } fn main() {} </ins>

Related discussion:
text: I tried this code: I expected to see this happen: the code is correct. Instead, this happened: Just swap the functions, then the code compiles: Update : The examples may be misleading. I forgot that takes effect on a single item. It was a typo. Here is a new example. It should be correct. But the compiler does not accept it. <!-- 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. --: :
Very strange. I'm thinking we have some stateful HIR lowering code that is hanging onto state it shouldn't.
This bug existed as far back as November 2019 (when was stabilized), so it's not a recent regression.
Marking this as P-medium based on the
I did some digging into this. I'm brand new to the compiler so slowly learning the architecture along the way. Below are some thoughts on what I've seen so far. The desugared HIR for both samples is the same: async first async last As expected both resolves the same set of lifetimes (from ) and process them in the same order (since ). Dump from the property at the first iteration: async first async last Interestingly both included the lifetime as used only once in the opaque/desugared async function and both . However, for the second case (async last) the compilation still succeeds - this is really confusing and I'm probably missing something big about the compiler architecture. Need to dig deeper.
The examples may be misleading. I forgot that takes effect on a single item. It was a typo. Here is a new example.
Makes sense. Then the behavior is no longer magical and makes a lot of sense.
Based on what I've seen the desugaring process is working correctly and the object is keeping the correct state. The lifetime linting identifies the lifetime as only used once within the return opaque type generated by the desugaring process. This behavior seems correct since we'd still want to catch this for an opaque type implementation from the user. My suggestion would be to include an exception in the linting specifically for opaque types of async functions that use a lifetime name already declared in the generic params of the parent function. I have validated this simple change (I named the loop ) and propose to include it alongside .
Code change:
<ins> #[deny(single_use_lifetimes)] // edition:2018 // check-pass // Prior to the fix, the compiler complained that the 'a lifetime was only used // once. This was obviously wrong since the lifetime is used twice: For the s3 // parameter and the return type. The issue was caused by the compiler // desugaring the async function into a generator that uses only a single // lifetime, which then the validator complained about becauase of the // single_use_lifetimes constraints. async fn bar<'a>(s1: String, s2: &'_ str, s3: &'a str) -> &'a str { s3 } fn foo<'a>(s1: String, s2: &'_ str, s3: &'a str) -> &'a str { s3 } fn main() {} </ins>

Related discussion:
text: One more question for the team ( what would we expect in this case? This compiles successfully, which is counter intuitive by looking at the function signature. It compiles because the desugared generator uses the same lifetime as the async function.
Code change:
<ins> error[E0277]: `&mut ()` is not a tuple --> $DIR/issue-57404.rs:6:41 | LL |     handlers.unwrap().as_mut().call_mut(&mut ()); |                                -------- -^^^^^^ |                                |        | |                                |        the trait `Tuple` is not implemented for `&mut ()` |                                |        help: consider removing the leading `&`-reference |                                required by a bound introduced by this call | note: required by a bound in `call_mut` --> $SRC_DIR/core/src/ops/function.rs:LL:COL error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Related discussion:
text: Reduced example
e
The first compilation error -- the example with looks fine to me. Types used for static variables must outlive the lifetime. The compiler can prove that outlives only if . Hence lifetimes are inferred in lieu of the anonymous lifetimes. Since your variable does not live for the whole lifetime, it cannot be used as you are trying to. Maybe the actual bug is that should desugar to , as it would be for ? It may be weird to special-case only the traits though -- i.e. if you define your own trait , then just means for some lifetime to be inferred by the compiler, it does not mean . Your reduced example is actually different since it actually does not involve static data. It seems to be the same bug as in , and hence is a bug with the feature. Going from to (note the tuple of size ) makes the ICE go away.
Fixed by
Code change:
impl Step for RustcDocs { type Output = Option<GeneratedTarball>; const DEFAULT: bool = true; <ins> const ONLY_HOSTS: bool = true; </ins> fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder;

Related discussion:
text: With and the following file: the command fails while installing docs because it can't find the target's directory. This makes sense because the directory is created in one of two places: and both of these are only invoked for the host (in the enclosing impls of each of those call sites, is set to true). So the problem is that the step, which relies on the existence of the directory (see ), is run for the target ( ), but the steps that would create that directory have only been run for the host. I was able to fix this by adding inside the ( ), so that rustc docs aren't generated for the target. I'm not sure if that's the right solution, and in general I'm unsure about the logic for which pieces of documentation are generated for the host and which ones for the target under cross-compilation. The end of the output, showing that fails due to reading a nonexistent directory, is:
n.b. I'm not sure I actually was using correctly -- my goal is to cross-compile snapshots that I can use for bootstrapping Rust on a riscv64 system, and based on the output, I think I probably should have used: instead. But this still shouldn't happen.
I think this will be fixed by
In general RustcDocs is pretty broken, see
merged but this is still unfortunately still an issue :( reproduced with did you ever find a quick workaround?
Code change:
euv::AutoRef(..) | euv::ClosureInvocation(..) | euv::ForLoop(..) | <del> euv::RefBinding(..) => { </del> <ins> euv::RefBinding(..) | euv::MatchDiscriminant(..) => { </ins> format!("previous borrow of `{}` occurs here", self.bccx.loan_path_to_string(&*old_loan.loan_path)) }

Related discussion:
text: Sorry for not providing smaller case but I hope this is better than nothing: Both versions works (compile and start), but runtime behavior changes. The code that follows the above part: will match no matter what really is, if the value is partially moved (so mouse events are updating my game). If I use the version with , the code works as intended and game is updated only on keyboard presses.
Minimal: This shouldn't compile at all.
Nominating.
Looks like a regression. 0.10 rejects this code.
Code change:
<ins> error[E0499]: cannot borrow `chars` as mutable more than once at a time --> $DIR/issue-102972.rs:4:9 | LL |     for _c in chars.by_ref() { |               -------------- |               | |               first mutable borrow occurs here |               first borrow later used here LL |         chars.next(); |         ^^^^^^^^^^^^ second mutable borrow occurs here | = note: a for loop advances the iterator for you, the result is stored in `_c`. = help: if you want to call `next` on a iterator within the loop, consider using `while let`. error[E0382]: borrow of moved value: `iter` --> $DIR/issue-102972.rs:12:9 | LL |     let mut iter = v.iter(); |         -------- move occurs because `iter` has type `std::slice::Iter<'_, i32>`, which does not implement the `Copy` trait LL |     for _i in iter { |               ---- `iter` moved due to this implicit call to `.into_iter()` LL |         iter.next(); |         ^^^^^^^^^^^ value borrowed here after move | = note: a for loop advances the iterator for you, the result is stored in `_i`. = help: if you want to call `next` on a iterator within the loop, consider using `while let`. note: `into_iter` takes ownership of the receiver `self`, which moves `iter` --> $SRC_DIR/core/src/iter/traits/collect.rs:LL:COL error: aborting due to 2 previous errors Some errors have detailed explanations: E0382, E0499. For more information about an error, try `rustc --explain E0382`. </ins>

Related discussion:
text: In this case, turns out there's only one: And there we see that there is already some conditional suggestion being made; it calls . And it seems there's a family of those . So I think it would make sense to try to write your own or something like that. You'll need to figure out how to sort of "back track" from the MIR back to the HIR or the AST so you can figure out whether you're inside a loop. I would study the code in to try to figure out how to do that. And don't forget to write a handful of regression tests in somewhere, maybe in : https://rustc-dev- It might also be possible to perform this check at a higher level, say, in . If you can figure out that you're in a for loop, and that the user is trying to call on the iterator, then you could raise the error then.
Code change:
fn fmt(&self, f: &mut Formatter) -> Result { try!(write!(f, """)); for c in self.chars().flat_map(|c| c.escape_default()) { <del> try!(write!(f, "{}", c)); </del> <ins> try!(f.write_char(c)) </ins> } write!(f, """) }

Related discussion:
text: Formatting a string containing special characters with usually prints them escaped i.e.. This snippet runs as expected in the . However on Windows, using both and , the is printed unescaped : From what I can gather,  only concerns itself with faulty surrogates and completely ignores special characters.
Code change:
<ins> //@ check-pass #![feature(inherent_associated_types)] //~^ WARN the feature `inherent_associated_types` is incomplete struct D<T> { a: T } impl<T: Default> D<T> { type Item = T; fn next() -> Self::Item { Self::Item::default() } } fn main() { } </ins>

Related discussion:
text: <!-- 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
related. label F-inherentassociatedtypes
It caused by a cycle query:
There's a related bug to this (I believe by involving some traits with associated types) that I would like to report, though I was able to raise mine on Stable (1.70.0) without using the feature flag. Should I make a separate bug report or attach it here?
Code change:
<ins> //@ check-pass #![feature(inherent_associated_types)] //~^ WARN the feature `inherent_associated_types` is incomplete struct D<T> { a: T } impl<T: Default> D<T> { type Item = T; fn next() -> Self::Item { Self::Item::default() } } fn main() { } </ins>

Related discussion:
text: Regression in nightly-2023-02-21 found 9 bors merge commits in the specified range commit[0] 2023-02-19: Auto merge of - cjgillot:codegen-overflow-check, r=tmiasko commit[1] 2023-02-19: Auto merge of - clubby789:builtin-derived-attr, r=jackh726 commit[2] 2023-02-20: Auto merge of - fmease:iat-type-directed-probing, r=jackh726 commit[3] 2023-02-20: Auto merge of - tmiasko:read-buf, r=the8472 commit[4] 2023-02-20: Auto merge of - camelid:rustdoc-all-only-stable, r=GuillaumeGomez commit[5] 2023-02-20: Auto merge of - b-naber:proj-relate-variance, r=lcnr commit[6] 2023-02-20: Auto merge of - megakorre:issue_105700, r=petrochenkov commit[7] 2023-02-20: Auto merge of - matthiaskrgr:rollup-4tdvnx6, r=matthiaskrgr commit[8] 2023-02-20: Auto merge of - lnicola:rust-analyzer-2023-02-20, r=lnicola ERROR: no CI builds available between and within last 167 days I guess ?
Seems this has been fixed on the latest nightly, marked as E-needs-test. labels: +E-needs-test
this regressed again in
Code change:
/// println!("{:?}", Foo(vec![("A".to_string(), 10), ("B".to_string(), 11)])); /// ``` #[stable(feature = "debug_builders", since = "1.2.0")] <del> #[inline] </del> pub fn debug_map<'b>(&'b mut self) -> DebugMap<'b, 'a> { builders::debug_map_new(self) }

Related discussion:
text: After discussing it on the forums I bit I decided to look into what the optimizer spends time on, and inlining seems to be a significant part of it. There seems to be a lot of room for improvement here. Tested by compiling syntex in rustc-benchmarks (though the inlining time seem quite significant in other crates as well.). I counted which functions were inlined the most, and and to a lesser extent , which are when automatically deriving , and which simply wrap two other functions inside fmt::builder show up a lot. Maybe derive(debug) could output the wrapped functions instead, or the equivalent code, so llvm doesn't have to spend time inlining them (unless this causes problems for debug info). is also inlined a lot, and also plays a role in derive(Debug). Maybe something could be done about that one as well, as it's that creates a struct but doesn't do anything else. <details<summaryOutput from time-llvm-passes</summaryUsing in the syntex-0.42.2 directory in rustc-benchmarks. It's a bit hard to say which crate is which, as the output from llvm and cargo isn't synced, though these are the bottom three (excluding the benchmark dummy) in reverse order: </details<details<summaryMost inlined functions: </summaryRunning , and filtering the output using this: (Yeah it's a bit of a monstrosity, and takes a long time, maybe I could look into making some tool analyze this if it turns out to be useful.)