jiebi/CodeConvo huggingface dataset:
Change:
} impl FromInner<fs_imp::File> for File { fn from_inner(f: fs_imp::File) -> File { <del> File { inner: f, path: None } </del> <ins> File { inner: f } </ins> } }

Discussion:
takes a object as reference, although it only clones it afterwards. It's also impossible to re-use the allocation for the file path, because it's only dropped at the end.
It is pretty hard to not involve allocations because Rust-native strings will have to be converted into null terminated one to pass into the native API at some point anyway.
That's true.. Maybe we can avoid the double-allocation?
The path is cloned only so that it can later be used in error messages, which is a somewhat debatable use case. We could resolve this in the future by taking an bound (if we had a trait like that). cc
In that case it would probably be better to just take a PathBuf. But does it really justify an extra allocation just to provide error messages?
That would be a lot less ergonomic -- I want to be able to feed in a string literal with no extra steps. Probably not, hence why I said it was a "somewhat debatable use case." :)
What about a variable-length stack allocation?
allocating on stack comes with its own downsides. Also, it doesn’t guarantee a trailing null byte either, AFAIK?
If you had a stack allocation, you could just append a null byte.
As tbu- said. And the downsides of are nothing compared to linking in 195kB of jemalloc (the absolute minimum jemalloc size on OS X x86_64 with LTO).
Change:
#[inline] fn exp(self) -> f64 { num::Float::exp(self) } #[inline] <del> fn exp2(self) -> f64 { num::Float::exp(self) } </del> <ins> fn exp2(self) -> f64 { num::Float::exp2(self) } </ins> #[inline] fn ln(self) -> f64 { num::Float::ln(self) } #[inline]

Discussion:
This succeeds and shouldn't. In , is also calling . Might just have to add a 2...
And tests probably...
Change:
} } <ins> #[stable(feature = "str_parse_error2", since = "1.8.0")] impl fmt::Display for ParseError { fn fmt(&self, _: &mut fmt::Formatter) -> fmt::Result { match *self {} } } </ins> #[stable(feature = "str_parse_error", since = "1.5.0")] impl PartialEq for ParseError { fn eq(&self, _: &ParseError) -> bool {

Discussion:
subj
Tagging as as should be a pretty good first bug to tackle for libstd!
Going to give this a shot! One question, given that is sort of a non-error (at least according to ), will returning/writing "parse error" be enough to satisfy and ?
ok! Yeah it should be fine to just ensure that something semi-reasonable comes out, it's more likely the case that just having these traits implemented is useful rather than ensuring the implementations themselves are useful :)
Since it's a void enum, you can use the same implementation as clone does in fact: It handles the enum exhaustively (as match forces you to) and makes sure all possible cases (zero cases) are handled. !
PR is up!
Change:
<ins> #![u=||{static d=||1;}] //~^ unexpected token //~| cannot find attribute `u` in this scope //~| `main` function not found in crate `issue_90873` //~| missing type for `static` item #![a={impl std::ops::Neg for i8 {}}] //~^ ERROR unexpected token //~| ERROR cannot find attribute `a` in this scope </ins>

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting a few other errors, because the code is nonsense, so low priority. Affected versions: I tried nightly 2021-11-12 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</detailsAlso note how there is one additional error below the backtrace, not sure if that's expected.
Thanks for the bug report, could this be related to the recent HIR map/lowering refactorings?
This issue looks very similar to , but the examples from there don't panic anymore.

<!-- 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 got a very large poc file, and reduce it into following code. But after reducing (via a simple delta debugging tech), the code looks kind of confusing. Please let me know if anyone prefers a better-formed but long test-case, and I will try me best to get one. md5: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --The bug is reproduced with nightly and beta versions, but not with stable version. : The output is from nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This can be "solved" by using and create a instead of panicking.
Assigning as discussed as part of the and removing .
A reproduction with fewer errors:
The provided examples do not panic anymore, can this issue be closed or does it need tests?
lets keep it open purely to track adding regression tests for these.
Change:
| LL |         print!(); |         ^^^^^ <ins> | = note: consider importing this macro: std::print </ins> error: aborting due to previous error

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: compiler should suggest importing from (it is in ). Instead, this happened: compiler say cannot find macro 'Component' but did not suggest importing it like other functions <!-- 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. --: Also not available in stable.
Change:
is_local); (v, inlineable) } <del> ast::ExprVstore(sub, ast::ExprVstoreSlice) => { </del> <ins> ast::ExprVstore(sub, store @ ast::ExprVstoreSlice) | ast::ExprVstore(sub, store @ ast::ExprVstoreMutSlice) => { </ins> match sub.node { ast::ExprLit(ref lit) => { match lit.node {

Discussion:
This line in my project currently causes an unimplemented expression error, told me to submit an issue
Change:
/// ``` #[inline] #[stable(feature = "rust1", since = "1.0.0")] <del> fn all<F>(self, mut f: F) -> bool where F: FnMut(Self::Item) -> bool { for x in self { if !f(x) { return false; } } </del> <ins> fn all<F>(&mut self, mut f: F) -> bool where F: FnMut(Self::Item) -> bool { for x in self.by_ref() { if !f(x) { return false; } } </ins> true }

Discussion:
One of the methods takes , the other takes , which is strange, since they are almost exactly the same code. I'm guessing that should take , like does.
cc
isn't this because consumes the iterator completely and only up to the first occurrence?
both iterators behave the same way, stops at the first value, stops at the first value.
Thanks for the report, This was a mistake, and both should take precisely to clarify the consumption semantics. This should be a trivial fix.
(Should be flagged 1.0-beta P-backcompat-libs)
0 beta, P-backcompat-libs.
Change:
} } <del> /// Returns an iterator visiting all key-value pairs in ascending order by /// the keys, emptying (but not consuming) the original `VecMap`. </del> <ins> /// Returns an iterator visiting all key-value pairs in ascending order of /// the keys, consuming the original `VecMap`. </ins> /// The iterator's element type is `(uint, &'r V)`. /// /// # Examples

Discussion:
cc I'm in the process of -ifying the collections, and I've discovered that the takes a instead of the convention of consuming the value. It's also marked stable, even though the type itself is marked unstable. Should this instead be a candidate for the method discussed in the collection reform trait?
Yeah this is just a mistake. Feel free to fix it to match conventions.
Just to be clear, the solution to this is to make consume the value and introduce a function (and iterator). Is this right or am I missing something?
Yep!
Change:
<ins> // check-pass #![feature(associated_type_defaults)] trait Foo { type Bar<T>: Baz<Self> = i32; // We should be able to prove that `i32: Baz<Self>` because of // the impl below, which requires that `Self::Bar<()>: Eq<i32>` // which is true, because we assume `for<T> Self::Bar<T> = i32`. } trait Baz<T: ?Sized> {} impl<T: Foo + ?Sized> Baz<T> for i32 where T::Bar<()>: Eq<i32> {} trait Eq<T> {} impl<T> Eq<T> for T {} fn main() {} </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: compiles, or a helpful error message Instead, this happened: Confusing error message, there doesn't seem to be a future that could be awaited?... Interestingly if the default implementation is removed, it compiles. Playground: <!-- 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
The error message on the playground is a bit different, seems to be correlating with the actual problem more, but even more confusing: Expected and found are the same!
Minimal: Something funky going on with the default projection predicate installed for the GAT. I'll look into it
I'm impressed by the speedy handling of this issue! Was hoping this would get a fix in a few weeks . You're awesome!
Once the pr is merged, it will be available the next day on nightly, correct? Btw, the pr failed some tests.
Change:
LL |  | } |  |_- ...not the enclosing function body <del> error: aborting due to 2 previous errors </del> <ins> error: aborting due to 4 previous errors </ins> For more information about this error, try `rustc --explain E0572`.

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
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
This is a regression considering it doesn't happen in beta.
Change:
<ins> error[E0308]: mismatched types --> $DIR/assoc-const-missing-type.rs:12:18 | LL |     const K<T> = (); |             -    ^^ expected type parameter `T`, found `()` |             | |             expected this type parameter | = note: expected type parameter `T` found unit type `()` error: missing type for `const` item --> $DIR/assoc-const-missing-type.rs:12:15 | LL |     const K<T> = (); |               ^ help: provide a type for the associated constant: `()` error[E0195]: lifetime parameters or bounds on const `Q` do not match the trait declaration --> $DIR/assoc-const-missing-type.rs:16:12 | LL |     const Q<'a>: &'a str; |            ---- lifetimes in impl do not match this const in trait ... LL |     const Q = ""; |            ^ lifetimes do not match const in trait error: missing type for `const` item --> $DIR/assoc-const-missing-type.rs:16:12 | LL |     const Q = ""; |            ^ help: provide a type for the associated constant: `: &str` error[E0308]: mismatched types --> $DIR/assoc-const-missing-type.rs:12:18 | LL |     const K<T> = (); |             -    ^^ expected type parameter `T`, found `()` |             | |             expected this type parameter | = note: expected type parameter `T` found unit type `()` = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` error: aborting due to 5 previous errors Some errors have detailed explanations: E0195, E0308. For more information about an error, try `rustc --explain E0195`. </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. --(reduced) (original) This code is very similar to closed issue . The only difference is in line 17 which was in previous issue and now it's <!-- 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 --
label -needs-triage F-genericconstitems claim
Change:
<ins> // edition:2018 #![feature(async_await)] pub async fn f(x: Option<usize>) { x.take(); //~^ ERROR cannot borrow `x` as mutable, as it is not declared as mutable [E0596] } pub async fn g(x: usize) { x += 1; //~^ ERROR cannot assign twice to immutable variable `x` [E0384] } fn main() {} </ins>

Discussion:
ICE when some lints fail on an async-fn. Make the xs mutable and no ICE. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: A-async-await C-bug I-ICE
Discussed in async-await meeting. Marking as blocking as this looks pretty bad for the user experience. Hopefully an easy fix. Presumably in the desugared form we are somehow failing because the keyword is missing or something like that.
claim
Change:
<ins> // Copyright 2017 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. pub trait Partial: Copy { } pub trait Complete: Partial { } impl<T> Partial for T where T: Complete {} impl<T> Complete for T {} //~ ERROR the trait bound `T: std::marker::Copy` is not satisfied </ins>

Discussion:
First reported in cc - let's discuss this when you are back from vacation (unless can come up with a solution?)
Associated types variant, which bypasses some fixes based only on supertraits:
Chalk's strategy will solve this, but I guess that shouldn't be extremely difficult to fix even with the current strategy. The first impl is valid: since indeed implies that . The second however, is not: the impl declaration should be able to prove that holds (ok because of the first impl), but also that is well-formed, i.e. that holds. Same thing in the second example, this impl declaration: should prove that (ok) and that is well-formed, i.e. . The latter is not being proved currently.
triage: P-high -- has pending fix
Change:
assert_eq!(ys, [5, 4, 3, 2, 1]); } <ins> #[test] </ins> fn test_peekable_is_empty() { let a = [1]; let mut it = a.iter().peekable();

Discussion:
An iterator returns None if it is empty, but Peekable's isempty is defined like this: This needs to be changed to use isnone(). In fact, the code from testpeekableis_empty() fails. It looks like this escaped detection because of a missing "#[test]"
Whoops! Feel free to submit a pull request fixing it. :)
Change:
|         ^^^^^^ returning this value requires that `'1` must outlive `'2` | = note: closure implements `Fn`, so references to captured variables can't escape the closure <ins> help: consider adding 'move' keyword before the nested closure | LL |         move || f() // The `nested` closure |         ++++ </ins> error: aborting due to previous error

Discussion:
Given the following code: The current output is: The actually needed fix here is the following, which should ideally be recommended <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
slightly more minimal:
claim
I came up with a solution of printing an extra line of to give user a recommendation of fixing the error by adding 'move' keyword before the closure parameter of map(). The following is the output for the first testing code. Is this good enough? This is the output from the second testing code ():
Refined the fix with a verbose suggestion of where to add keyword. The output of the first test case is: The output of the second test case is: In addition, the fix will also add the suggestion for nested closure block like this test case: The output of the above test case is:
Change:
| LL |     1u32 as char; |     ^^^^^^^^^^^^ invalid cast <ins> | help: try `char::from_u32` instead --> $DIR/E0604.rs:2:5 | LL |     1u32 as char; |     ^^^^^^^^^^^^ </ins> error: aborting due to previous error

Discussion:
Given the following code: The current output is: This is not very clear. There are two pieces of background information the user needs here: s are Unicode scalar values, which are any integer value from 0 to 0xD7FF and 0xE000 to 0x10FFFF. Only u8 can be statically guaranteed to meet this requirement so only u8 can be cast to char. is probably what the user wants, if they are interested in non-ASCII values. The user is directed to further information available at and , neither of which explains either of those two points. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think a good improvement would be to a) Add more detail about this to b) Add a to this error that suggests are you interested in working on one or both of those? :)
claim
While I was reading the docs I noticed a minor error in : This isn't true; a USV is a Code Point within either of two ranges, not one. It's also a bit cagey about what the ranges are numerically; I don't know if this is intentional. Personally I would re-write it to the below: Would I put that in the same PR (as they're both documentation) or a new issue?
A new PR would be better.
Change:
<ins> // This is a non-regression test for issue #126670 where RPITIT refinement checking encountered // errors during resolution and ICEd. //@ edition: 2018 pub trait Mirror { type Assoc; } impl<T: ?Sized> Mirror for () { //~^ ERROR the type parameter `T` is not constrained type Assoc = T; } pub trait First { async fn first() -> <() as Mirror>::Assoc; //~^ ERROR type annotations needed } impl First for () { async fn first() {} } fn main() {} </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. --(hand-reduced) <details<summary<strong(original)</strong</summary<p</p</details<!-- 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. --: Command: I put the option to remove "async fn" error, but I guess it is not an essential option to trigger ICE. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details- ICE location: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
searched nightlies: from nightly-2022-02-19 to nightly-2024-06-19 regressed nightly: nightly-2024-03-08 searched commit range: regressed commit: ()
Change:
p!(print(self.0.trait_ref.print_only_trait_path())); } <ins> PrintClosureAsImpl<'tcx> { p!(pretty_closure_as_impl(self.closure)) } </ins> ty::ParamTy { p!(write("{}", self.name)) }

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest how to specify the return type when a function returns a closure. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Is some thing like this not ok ?
release-assignment
It's ok but I was wondering if it's possible to make the compiler give some form of a suggestion to the user on how to do this. Cause the current diagnostics does not suggest how to fix it.
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. #![feature(unsafe_destructor)] // issue #20126 #[derive(Copy)] //~ ERROR the trait `Copy` may not be implemented struct Foo; impl Drop for Foo { fn drop(&mut self) {} } #[derive(Copy)] //~ ERROR the trait `Copy` may not be implemented struct Bar<T>; #[unsafe_destructor] impl<T> Drop for Bar<T> { fn drop(&mut self) {} } fn main() {} </ins>

Discussion:
Basically, it's now possible to write: and have everything work. This unfortunately means that doing something like with a will zero b, but not move it. /cc
I noticed this possibility too and was debating if this is a problem. It's not clear to me. Probably best to disallow it for now.
at the very least, it's causing incorrect behaviour at runtime, since it's zeroing out types like a move, but not forbidding the use of them like a copy.
Looks unsafe to me: Program received signal SIGSEGV, Segmentation fault. 0x0000555555598e5c in ()
I agree that combining it with zeroing is unsafe. If zeroing did not occur, or we did not zero for types that were copy, there wouldn't necessarily be a problem.
Anyhow, it's easiest to forbid it for now. We can always make it legal later if someone comes up with a persuasive use case. Idempotent destructors seem like a bit of an odd thing.