jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: lifetime parameter `'a` never used --> $DIR/unused-lifetime.rs:26:40 | LL | pub async fn func_with_unused_lifetime<'a>(s: &'a str) { |                                        ^^ | note: lint level defined here --> $DIR/unused-lifetime.rs:7:9 | LL | #![deny(unused_lifetimes)] |         ^^^^^^^^^^^^^^^^ error: lifetime parameter `'a` never used --> $DIR/unused-lifetime.rs:31:44 | LL | pub async fn func_with_two_unused_lifetime<'a, 'b>(s: &'a str, t: &'b str) { |                                            ^^ error: lifetime parameter `'b` never used --> $DIR/unused-lifetime.rs:31:48 | LL | pub async fn func_with_two_unused_lifetime<'a, 'b>(s: &'a str, t: &'b str) { |                                                ^^ error: lifetime parameter `'c` never used --> $DIR/unused-lifetime.rs:37:54 | LL | pub async fn func_with_unused_lifetime_in_two_params<'c>(s: &'c str, t: &'c str) { |                                                      ^^ error: aborting due to 4 previous errors </ins>

Discussion:
Async functions that take references seem to always trigger the lint (which is allow-by-default). Example: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I found which describes basically the same problem.
Seeing as this lint is not enabled by default, marking as deferred, though this would be good to fix and probably not too hard.
claim
Looks the same issue as . A little inelegant but if we can suppress the lint I think...
Change:
<ins> error: lifetime parameter `'a` never used --> $DIR/unused-lifetime.rs:26:40 | LL | pub async fn func_with_unused_lifetime<'a>(s: &'a str) { |                                        ^^ | note: lint level defined here --> $DIR/unused-lifetime.rs:7:9 | LL | #![deny(unused_lifetimes)] |         ^^^^^^^^^^^^^^^^ error: lifetime parameter `'a` never used --> $DIR/unused-lifetime.rs:31:44 | LL | pub async fn func_with_two_unused_lifetime<'a, 'b>(s: &'a str, t: &'b str) { |                                            ^^ error: lifetime parameter `'b` never used --> $DIR/unused-lifetime.rs:31:48 | LL | pub async fn func_with_two_unused_lifetime<'a, 'b>(s: &'a str, t: &'b str) { |                                                ^^ error: lifetime parameter `'c` never used --> $DIR/unused-lifetime.rs:37:54 | LL | pub async fn func_with_unused_lifetime_in_two_params<'c>(s: &'c str, t: &'c str) { |                                                      ^^ error: aborting due to 4 previous errors </ins>

Discussion:
<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Duplicate of
Change:
LL |     use super::a; |         ^^^^^^^^ | <del> help: consider adding a `#[cfg(test)]` to the containing module </del> <ins> help: if this is a test module, consider adding a `#[cfg(test)]` to the containing module </ins> --> $DIR/unused-imports-in-test-module.rs:28:1 | LL | mod test_a {

Discussion:
This help message seems weird. I'd expect the help to be more like: Consider adding if you want to silent the lint on the unused import Consider removing the unused import Suggesting to add to the module is the least expected option, and it seems too assertive in its current wording. No response Perhaps the detection for triggering on the module could be smarter and only consider a module as a potential test module if it contains at least one annotated function? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
How can i proceed to solve this any suggestions on how can it be done changes to which file will make it happen since i am new to this repo
Hi thank you for your interest. For now, I think making the help message less assertive would be sufficient. Here are some tips to get you started: will need to find where this help message is emitted. You can identify where this help message is coming from by grepping the repo, i.e. this case, it might be as simple as changing this string to make it sound less assertive. can reformat your changes via . the UI test suite to make sure at least one test fails -- this means at least one test is actually testing this diagnostic. you're happy with the stderr output from your change, re-bless the UI test suite and now make sure the UI test suite passes. to make sure tidy checks passes locally. a PR and wait for review. Your reviewer will discuss with you to see if any further changes are desirable. <https://rustc-dev- the more in-depth reference. If you are stuck, feel free to ask here, or make a new thread in .
claim
(Unless already submitted a change and I didn't find it, I should be able to create a PR soon)
Change:
#![feature(fn_traits)] #![feature(fundamental)] #![feature(inplace_iteration)] <del> #![feature(int_bits_const)] </del> #![feature(lang_items)] #![feature(layout_for_ptr)] #![feature(maybe_uninit_ref)]

Discussion:
Tracking issue for as introduced by Gated behind .
modify labels: +T-libs
Error: Label P can only be set by Rust team members Please let know if you're having trouble with this bot.
This has been in a few releases, is used in many places in rustc itself, and there's no open questions so far. Time to stabilize? merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
We agreed in the libs meeting just now to revert stablization, since the is significant throughout the ecosystem, through . :( We can stabilize it again once that is solved upstream.
Closing this since has been merged.
Change:
| help: consider cloning the value if the performance cost is acceptable | <del> LL -     *u.c LL +     u.c.clone() | </del> <ins> LL |     (*u.c).clone() |     +    +++++++++ </ins> error[E0507]: cannot move out of `*u.d` which is behind a raw pointer --> $DIR/move-from-union-field-issue-66500.rs:24:5

Discussion:
Cloning the pointer doesn't make sense in that situation and would cause a type mismatch error. I'm not sure whether any of the two current suggestions should be kept or removed in this case. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that this works: It works because is a place expression and then we attach to that, which then reborrows the String. I don't think we should suggest , which may have undesirable or unexpected effects in the case of things like types that handle backing buffers, instead of issuing a safe which will recreate the backing allocation correctly.
I didn't know that was possible, thanks for letting me know. I guess that the best approach would then be to change the suggestion accordingly as below?
Correct. Also, we could mention in the error for pointers, but we shouldn't recommend it. It's unsafe code, we should strive to preserve the "you break it, you buy it" / "do your own research" experience for that.
The relevant section of diagnostic code is here but it will require some restructuring to account for the fact that the suggestion will not be doing things like stripping parentheses, but suggesting adding them if they don't exist.
claim It looks good for me to make a try.
Change:
use rustc_ast::visit::{FnCtxt, FnKind}; use rustc_ast_pretty::pprust::{self, expr_to_string}; use rustc_data_structures::fx::{FxHashMap, FxHashSet}; <ins> use rustc_data_structures::stack::ensure_sufficient_stack; </ins> use rustc_errors::{Applicability, DiagnosticBuilder, DiagnosticStyledString}; use rustc_feature::{deprecated_attributes, AttributeGate, AttributeTemplate, AttributeType}; use rustc_feature::{GateIssue, Stability};

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. --It seems rustc can no longer handle how much is defined in these two binding files. If I comment out either module, it will successfully build. It was previously building on . Building this project on Windows: <!-- 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 --<!-- TRIAGEBOT_END --
This is the stack overflow. Some recursive call in ClashingExternDeclaration checking. I think this is . I tried to set across the files to see if it might help, but I am not sure if that is exposed. I didn't dig into too much, but it still seems to trigger. <!-- 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. --I am not sure why I don't see the commit hash in the build. First time building the compiler. : <details<summary<strongWindbg stacktrace</strong</summary</details
Pinging for clashingexterndeclarations in the meantime.
Uh oh, that's not good. Thanks for reporting! I'll get on this now. claim
Change:
Bar { x: Foo::x } => {}, } } <ins> { struct Baz { x: isize, y: isize, z: isize, } let Baz { x: mut x, //~ ERROR the `x:` in this pattern is redundant y: ref y, //~ ERROR the `y:` in this pattern is redundant z: ref mut z, //~ ERROR the `z:` in this pattern is redundant } = Baz { x: 0, y: 0, z: 0 }; } </ins> }

Discussion:
Code: output: Note that in the attempted fix is incorrect syntax (it ate a colon). Edit: it probably actually isn't. Version info:
thanks for feedback :) it seems a rustfix bug, could you please file a issue there? cc
Will do. Is it intentional that suggests filing a bug in this repo (see the error message), or should that be changed?
This is the correct place to file the issue, it is a bug in . The issue is that the lint is providing a bad suggestion. Either the span needs to encompass the entire binding, or the suggested text needs to be the empty string.
Change:
fn main() { let a = if true { true }; <del> //~^ ERROR if may be missing an else clause </del> <ins> //~^ ERROR if may be missing an else clause [E0317] </ins> //~| expected type `()` //~| found type `bool` //~| expected (), found bool

Discussion:
Here's my code (2.rs): On running , I get And gives Am I missing something? Shouldn't the explanation talk about ?
The error explanation was in . The code reporting contains the following note: And, from :
Change:
// run-fail <del> // error-pattern:assertion failed: `(left == right)` // error-pattern: left: `2` // error-pattern:right: `3`: 1 + 1 definitely should be 3 </del> <ins> // error-pattern:assertion `left == right` failed: 1 + 1 definitely should be 3 // error-pattern:  left: 2 // error-pattern: right: 3 </ins> // ignore-emscripten no processes fn main() {

Discussion:
The custom message in macro is shown right after the . This is hard to read because the value strings could be very long. I think it is better to print the custom message (if available) on a separate line. The above (playground) prints this: Note that custom message and the location in source are still on the same line <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I will try it. claim
Note that the linked PR, , has a lot of review comments. I think rebasing that PR and addressing the comments would already be very close to landing this change.
(taking over due to inactivity) claim
:tada: Horray! It only took 548 days (1.5+ years) since I created on Feb 14th, 2022. Numerous commits. Tens of people. 4 PRs... 100s of files. All to change a few lines of output :) Special thanks to for all the support!
Change:
<ins> error: this file contains an un-closed delimiter --> $DIR/issue-63116.rs:3:18 | LL | impl W <s(f;Y(;] |          -       ^ |          | |          un-closed delimiter error: expected one of `!`, `(`, `)`, `+`, `,`, `::`, or `<`, found `;` --> $DIR/issue-63116.rs:3:12 | LL | impl W <s(f;Y(;] |            ^ expected one of 7 possible tokens error: expected one of `!`, `&&`, `&`, `(`, `)`, `*`, `+`, `,`, `->`, `...`, `::`, `<`, `>`, `?`, `[`, `_`, `dyn`, `extern`, `fn`, `for`, `impl`, `unsafe`, or lifetime, found `;` --> $DIR/issue-63116.rs:3:15 | LL | impl W <s(f;Y(;] |              -^ help: `)` may belong here |              | |              unclosed delimiter error: aborting due to 3 previous errors </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): This error does not occur on stable or beta, nor on a nightly from last week.
The panic is being thrown from here: That code assumes that will always return . However, in this case calls , which returns from here:
cc
Seems fixed in the latest nightly(), marked as E-needstest
I'll add a test for this
Change:
if is_input { for j in 0..ai.len() { // If we find at least one argument that could satisfy this input <del> // this argument isn't useless </del> <ins> // this input isn't useless </ins> if matches!(mat[i][j], Compatibility::Compatible) { useless = false; break;

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 compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.
Change:
let mut inserted = FxHashSet::default(); items.extend(doc.foreigns.iter().map(|(item, renamed)| { let item = clean_maybe_renamed_foreign_item(cx, item, *renamed); <del> if let Some(name) = item.name { </del> <ins> if let Some(name) = item.name && !item.attrs.lists(sym::doc).has_word(sym::hidden) { </ins> inserted.insert((item.type_(), name)); } item })); <del> items.extend(doc.mods.iter().map(|x| { inserted.insert((ItemType::Module, x.name)); clean_doc_module(x, cx) </del> <ins> items.extend(doc.mods.iter().filter_map(|x| { if !inserted.insert((ItemType::Module, x.name)) { return None; } let item = clean_doc_module(x, cx); if item.attrs.lists(sym::doc).has_word(sym::hidden) { // Hidden modules are stripped at a later stage. // If a hidden module has the same name as a visible one, we want // to keep both of them around. inserted.remove(&(ItemType::Module, x.name)); } Some(item) </ins> })); // Split up imports from all other items.

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 glob reexport reexports module and there is already module , the documentation duplicates. Current behaviour: ! ( module is duplicated, though both module links point to as expected) The expected behaviour: module is only shown once. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
pub fn try_recv(&self) -> TryRecvResult<T> { // If a thread is spinning in try_recv, we should take the opportunity // to reschedule things occasionally. See notes above in scheduling on <del> // sends for why this doesn't always hit TLS. </del> <ins> // sends for why this doesn't always hit TLS, and also for why this uses // `try_take` instead of `take`. </ins> let cnt = self.receives.get() + 1; self.receives.set(cnt); if cnt % (RESCHED_FREQ as uint) == 0 { <del> let task: ~Task = Local::take(); task.maybe_yield(); </del> <ins> let task: Option<~Task> = Local::try_take(); task.map(|t| t.maybe_yield()); </ins> } loop {

Discussion:
Reporting this here after asking in IRC something like this: where c_callback is called from a thread created by the c library crashes the application after a while with: previously SharedChan seemed to work without problem
cc It looks like the new can no longer be used outside a runtime?
Whoops, testing a fix now (sorry about that!)
thanks!
sorry to post on a closed issue, but i'm finding the same problem now in SyncChan/SyncPort not sure if it's a real bug or in this case it's supposed to work like that?
You won't be able to use those off the runtime because a send involves then receiving which blocks the task. You're only able to block if you have a local rust task available.
that's what i was suspecting, thanks!
Change:
<ins> // run-pass // edition:2021 enum Variant { A, B, //~ WARNING: variant is never constructed: `B` } struct A { field: Variant, } fn discriminant_is_a_ref() { let here = A { field: Variant::A }; let out_ref = &here.field; || match out_ref { //~ WARNING: unused closure that must be used Variant::A => (), Variant::B => (), }; } fn discriminant_is_a_field() { let here = A { field: Variant::A }; || match here.field { //~ WARNING: unused closure that must be used Variant::A => (), Variant::B => (), }; } fn main() { discriminant_is_a_ref(); discriminant_is_a_field(); } </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. --Nightly only, since it depends on the feature gate. Without the feature gate, the code compiles without an ICE. is the first nightly with the ICE. Still occurs on the latest nightly ( at the time of writing). ICE still occurs when is substituted with , e.g. <!-- 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
cc
can you take a look please
I started looking into the issue and I think it spans from failing to resolve the upvars when the feature is enabled: fails which leads to the field of the Candidate to not be assigned as the assignment of this field is being done
The underlying issue is that currently the compiler does not realize, for the above example, that the discriminant should be read. We incorrectly assumed that would only be of type when they could be of other types like we should be looking at the when we actually want to look at Working on a fix
Change:
<ins> error[E0277]: `()` cannot be safely transmuted into `ExplicitlyPadded` in the defining scope of `assert::Context` --> $DIR/issue-115402-overflow-size.rs:22:41 | LL |     assert::is_maybe_transmutable::<(), ExplicitlyPadded>(); |                                         ^^^^^^^^^^^^^^^^ values of the type `ExplicitlyPadded` are too big for the current architecture | note: required by a bound in `is_maybe_transmutable` --> $DIR/issue-115402-overflow-size.rs:9:14 | LL |     pub fn is_maybe_transmutable<Src, Dst>() |            --------------------- required by a bound in this function LL |     where LL |         Dst: BikeshedIntrinsicFrom<Src, Context>, |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `is_maybe_transmutable` error[E0277]: `ExplicitlyPadded` cannot be safely transmuted into `()` in the defining scope of `assert::Context` --> $DIR/issue-115402-overflow-size.rs:25:55 | LL |     assert::is_maybe_transmutable::<ExplicitlyPadded, ()>(); |                                                       ^^ values of the type `ExplicitlyPadded` are too big for the current architecture | note: required by a bound in `is_maybe_transmutable` --> $DIR/issue-115402-overflow-size.rs:9:14 | LL |     pub fn is_maybe_transmutable<Src, Dst>() |            --------------------- required by a bound in this function LL |     where LL |         Dst: BikeshedIntrinsicFrom<Src, Context>, |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `is_maybe_transmutable` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </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. --<!-- 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
Crashes since 1.65.0.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<del> error: `&'static [u32]` is forbidden as the type of a const generic parameter --> $DIR/static-reference-array-const-param.rs:1:15 | LL | fn a<const X: &'static [u32]>() {} |               ^^^^^^^^^^^^^^ | = note: the only supported types are integers, `bool` and `char` = help: more complex types are supported with `#![feature(adt_const_params)]` error: aborting due to previous error </del>

Discussion:
<!-- 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 works with because the type is forbidden. However, it continues to ICE with .
No longer ICEs since
Change:
{} #[doc(hidden)] <del> unsafe impl<'a, I, T: 'a> TrustedRandomAccess for Cloned<I> </del> <ins> default unsafe impl<'a, I, T: 'a> TrustedRandomAccess for Cloned<I> </ins> where I: TrustedRandomAccess<Item=&'a T>, T: Clone { unsafe fn get_unchecked(&mut self, i: usize) -> Self::Item {

Discussion:
I compared the performance of three equivalent functions: This is results (release mode):
IIRC zip is specialized for slices which is why the last case is so much faster.
Try also to compile with
A question could be: is it possible for to return something similar to ?
It makes the two times faster, the speed of the and the has stayed the same as before.
You've discovered the "untweaked speed" of zip :frowning_face:, which is what has. can implement the same way slice iterators do, in fact is just a newtype around an iterator that already implements that trait.
Change:
# aarch64-linux-android configuration # CROSS_PREFIX_aarch64-linux-android- CC_aarch64-linux-android=$(CFG_ANDROID_CROSS_PATH)/bin/aarch64-linux-android-gcc <del> LINK_aarch64-linux-android=$(CFG_ANDROID_CROSS_PATH)/bin/aarch64-linux-android-gcc </del> CXX_aarch64-linux-android=$(CFG_ANDROID_CROSS_PATH)/bin/aarch64-linux-android-g++ CPP_aarch64-linux-android=$(CFG_ANDROID_CROSS_PATH)/bin/aarch64-linux-android-gcc -E AR_aarch64-linux-android=$(CFG_ANDROID_CROSS_PATH)/bin/aarch64-linux-android-ar

Discussion:
Appears like: Essentially, 'LINK_foo' is empty. Heres a list:
I think this is your issue. (I ran into it myself while doing a build)
Dup of , apparently.
I believe this will be fixed by
Closing as a duplicate.