jiebi/CodeConvo huggingface dataset:
Change:
self.add_static_impl_trait_suggestion(&mut diag, *fr, fr_name, *outlived_fr); self.suggest_adding_lifetime_params(&mut diag, *fr, *outlived_fr); <ins> self.suggest_move_on_borrowing_closure(&mut diag); </ins> diag }

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:
<ins> pub const ITEM: Item = Item; pub struct Item; pub fn item() {} pub use doesnt_exist::*; //~^ ERROR unresolved import `doesnt_exist` mod a { use crate::{item, Item, ITEM}; } mod b { use crate::item; use crate::Item; use crate::ITEM; } mod c { use crate::item; } 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 an error that only says that " is unresolved". But the error says that all uses of items from the module with glob import ( in this case) are unresolved too: This may lead to extremely long and unreadable errors. The issue was originally found while developing where it caused . <!-- 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. --:
<details<summaryOutput on 1.38:</summary</details label A-diagnostics A-resolve regression-from-stable-to-stable
why do you think it's a "regression-from-stable-to-stable"? IMO the output from is even worse
The error is much shorter, and only points at the actual problem. The unused import warnings, of course, wouldn't be there if those imports were actually used.
From those rollups, looks relevant.
ah, you are right, I've misread the output thinking that the warnings were errors too.
I spent some time trying to debug this last week and I'm fairly sure is the PR that introduced this. I wasn't aware of that PR at the time but I spent a lot of time trying to understand what is "determinate" vs. "indeterminate" (which is unfortunately not documented) and I remember finding out that with glob import the import is becoming "indeterminate" while it's normally (without the glob import) it is "determinate", which is one of the things we check elsewhere when generating these warnings.
Assigning as and removing .
Change:
} } <del> /// The other methods hand out references while taking &self. /// As such, callers of this method must ensure no `&` and `&mut` are /// available and used at the same time. </del> <ins> /// Watch out: unsynchronized internal mutability! /// /// # Safety /// Causes UB if any reference to the value is used after this. </ins> #[allow(unused)] <del> pub unsafe fn take(&mut self) -> Option<T> { // SAFETY: See doc comment for this method. unsafe { (*self.inner.get()).take() } </del> <ins> pub(crate) unsafe fn take(&self) -> Option<T> { let mutable: *mut _ = UnsafeCell::get(&self.inner); // SAFETY: That's the caller's problem. unsafe { mutable.replace(None) } </ins> } } }

Discussion:
At , acquire a pointer of type from a shared reference , and subsequently, in the , we reinterpret as and use it as a mutable pointer At the method of the field requires as defined in The whole process can be that we use to acquire a and call a mutable method on that variable, which seems problematic.
The code is sound if it uses , and all the fields inside that type is covered by . It should use or instead of pointer-casting.
Edit: I think what I want to ask about is the following example, which is almost identical to the original question and passes miri's check:
No, you should not do that.
So this is what is happening in the standard library: There is a structure like ; In , is converted to and passed to ; In , is converted to , then is called. requires , so it is actually , which means that a is born from a . In the entire process, we haven’t touched on anything related to . And, I also believe that containing an is not a reason for to be treated differently.
Yes, should be and not .
I should clarify that my "should not" here is that it can potentially pass miri, but my understanding is that it is brittle and relying on the operational semantics being a certain way, rather than being a "necessarily true" interpretation of Rust's semantics. Programs which are slight modifications easily become unsound, and libstd unfortunately has slight modifications done to it all the time, so... aiui this code currently passes miri because we do run miri on libstd's tests, but is not what I would consider "durable".
( probably. )
Change:
/* current */ &'static str, ), /// Error E0530: `X` bindings cannot shadow `Y`s. <del> BindingShadowsSomethingUnacceptable(&'static str, Symbol, &'a NameBinding<'a>), </del> <ins> BindingShadowsSomethingUnacceptable { shadowing_binding_descr: &'static str, name: Symbol, participle: &'static str, article: &'static str, shadowed_binding_descr: &'static str, shadowed_binding_span: Span, }, </ins> /// Error E0128: generic parameters with a default cannot use forward-declared identifiers. ForwardDeclaredTyParam, // FIXME(const_generics_defaults) /// ERROR E0770: the type of const parameters must not depend on other generic parameters.

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-medium
Change:
self } <del> /// Extracts a string slice containing the entire string. </del> <ins> /// Converts a `String` into a mutable string slice. /// /// # Examples /// /// Basic usage: /// /// ``` /// use std::ascii::AsciiExt; /// /// let mut s = String::from("foobar"); /// let s_mut_str = s.as_mut_str(); /// /// s_mut_str.make_ascii_uppercase(); /// /// assert_eq!("FOOBAR", s_mut_str); /// ``` </ins> #[inline] #[stable(feature = "string_as_str", since = "1.7.0")] pub fn as_mut_str(&mut self) -> &mut str {

Discussion:
For this one, ideally the example would demonstrate mutation. If anyone anyone wants to work on this, just mention it in a comment to prevent duplicate work. If you need any help or have any questions, don't hesitate to ping me :)
I will work on this.
Change:
<ins> running 1 test test $DIR/issue-91134.rs - Something (line 10) ... ok test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in $TIME </ins>

Discussion:
We have a Rust-2015 doc test which has an which started failing to build on nightly 2021-11-21 (but passes on stable/2021-11-20). It now fails with
Probably caused by (; no rollup?).
That seems unlikely, is more plausible. doesn't affect doctests.
Oh, I think I got misled by the "rustdoc" bit.
I can't reproduce this. I tried /// extern crate inner; /// and running , but all the tests passed fine. can you link the original code?
The failure is You can see the first failure in CI at
The following seems like a minimal reproduction when used with 2015: /// extern crate mycrate; /// mycrate::foo(); /// Bisected to .
cc , I think it might make sense to revert temporarily unless you already have an idea for a fix.
Change:
pub const TRUE: BOOL = 1; pub const FALSE: BOOL = 0; <ins> pub const CSTR_LESS_THAN: c_int = 1; pub const CSTR_EQUAL: c_int = 2; pub const CSTR_GREATER_THAN: c_int = 3; </ins> pub const FILE_ATTRIBUTE_READONLY: DWORD = 0x1; pub const FILE_ATTRIBUTE_DIRECTORY: DWORD = 0x10; pub const FILE_ATTRIBUTE_REPARSE_POINT: DWORD = 0x400;

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: a case-sensitive list of environment variables and values, matching the output of from C# and .NET and the output of from PowerShell. It seems we should align the output to match the modern APIs for Windows that Microsoft provides. Instead, this happened: returns all environment variable names in all uppercase. Rust via : C# via : <!-- 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. --: </p</details
I don't think this is related to reading environment variables, but is related to process spawning. If you are spawning a process from a Rust program, then they will be uppercased. But if the Rust program is spawned from something else (like PowerShell), then the env keys should be case-preserved. The issue is . This was originally in to I personally don't think that issue is all that important that all environment keys should be forced to be uppercase. However, if there is a desire to fix both issues, then there would need to be a case-insensitive map (maybe just keep a separate set of uppercased keys?).
thanks for the pointer. For our case, Nushell should be able to spawn processes and keep the environment as expected rather than uppercasing. This allows Nushell to work just as PowerShell spawning a program. As best as I can tell, it's the lookup of a single variable that should be case-insensitive and that listing of variables should maintain the case they had, though I'm far from an expert here.
Hm, the current code does look wrong. Windows environment variables are compared case-insensitive but when set they keep the same case. The simplest improvement here would be remove the and instead implement , and in a way that ignores case differences. However, note that Windows uses Unicode casing, not just ASCII. There is for comparing but using it for would mean lots of conversions from OsString to the Windows string type (and back again). Calling Rust's Unicode functions with a WTF-8 OsString looks tricky too (though maybe there's something I'm missing). I'm uncertain how to approach a proper fix.
Change:
use std::path::PathBuf; use crate::errors::{ <del> EncounteredErrorWhileInstantiating, LargeAssignmentsLint, RecursionLimit, TypeLengthLimit, </del> <ins> EncounteredErrorWhileInstantiating, LargeAssignmentsLint, NoOptimizedMir, RecursionLimit, TypeLengthLimit, </ins> }; #[derive(PartialEq)]

Discussion:
The following scenario used to work fine 1.25.0: This would create two .bc files that could be linked together into a program, but when I try this on 1.26.{0,1,2} the compiler crashes like so:
Possibly dupe/related to ?
Yea I think this is a dupe, handling over there
The issue you mention seems to have something to do with impl trait (and looks like it goes away when the use is removed?) , whereas the issue I posted here crashes with even the simplest rust code. Are they really the same?
Hmm... you're right. I mean impl Trait in the other issue is just the trigger, the cause is in a normal function calling another one, but here you have another crate
I've discovered that if I tell the compiler to emit another type along with like this issue goes away. It makes me suspect this piece of code in : I'm wondering if by not running the code-gen or linking when outputting the metadata is causing this.
Triage: still repros:
Since , doesn't include optimized MIR, so produced rlib cannot be used to perform codegen. It would be nice to detect that particular situtation and produce more meaningful error describing that this is unsupported.
PR with fix:
Change:
| RegionNameSource::AnonRegionFromUpvar(..) | RegionNameSource::AnonRegionFromOutput(..) | RegionNameSource::AnonRegionFromYieldTy(..) <del> | RegionNameSource::AnonRegionFromAsyncFn(..) => false, </del> <ins> | RegionNameSource::AnonRegionFromAsyncFn(..) | RegionNameSource::AnonRegionFromImplSignature(..) => false, </ins> } }

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details
Changing Self{field} to MyStruct{field} makes it build btw.
I haven't done a search for the exact commit, but on the playground this regressed between beta and nightly. label +regression-from-stable-to-nightly
This is due to the NLL stabilization PR , since it manifests with on 1.61 (with to allow feature flags). I'll be looking at it in a few hours when I get home!
Change:
<ins> // check-pass #![allow(incomplete_features, dead_code, unconditional_recursion)] #![feature(const_generics)] fn fact<const N: usize>() { fact::<{ N - 1 }>(); } fn main() {} </ins>

Discussion:
This code (): results in an ICE:
Isn't that a close cousin of
Not really, this is an associated function rather than an inner function.
I'm investigating this. Still repros on . With : <details<summaryBacktrace </summary</details
After investigating, the current ICE is caused by the () inside of not being able to locate the generic parameter it is trying to substitute for. The code at fault is: Which should try and find based on the (), but the current code only handles the situation like .
No longer ICEs, I believe down to Looking at the backtrace on nightly-2019-12-05 this seems related to and also
This no longer ICEs OR errors, at least for me. What backtrace do you mean? AFAICT this can be closed.
Whoops, wrote the wrong date down. I meant the nightly when it did ICE, it was 2019-12-01 or thereabouts. Yeah it can be closed once there's a regression test
Change:
<ins> // check-pass #![allow(incomplete_features, dead_code, unconditional_recursion)] #![feature(const_generics)] fn fact<const N: usize>() { fact::<{ N - 1 }>(); } fn main() {} </ins>

Discussion:
paniked when I tried to use GAT, I didn't know does not support it then. Anyway I think it is not supposed to panic. I have confirmed with version 1.39 on Windows, my PC version 1.36 on Linux. It said,
Seems a duplicate of , I did not noticed it when I was opening this issue, sorry. There is also a small difference that I did not turn on
cc &
This should be fixed in the next nightly

This is a toy example I made in order to later make tests which run for with . This is the error I get: Error notes: - compiler flags: I don't know if this kind of pattern is intended as part of the feature or in its future, but if not, I think it can be satisfied by using a procedural macro so that's probably alright. The point of the pattern, as I mentioned at the beginning of the post, is to be able to test a particular generic type's implementation up to an arbitrary range of numeric constants. While implementing another project to help test the feature, I stumbled upon the problem of wanting to test hundreds of different constants, but having no way of doing so with say, a loop over a range of constants. This is one way I thought of making it work. Am I making the right decisions here? How should I go about testing hundreds of constants? Thanks :)
Note: another example that also panics. I know, yes, expressions aren't yet supported as const parameters. But it has the same panic, which is WEIRD! When I wrote this one, I thought "okay maybe inside a statement, the compiler won't try things like because the case when is is already covered... and with exhaustiveness check it should know that N = 0 won't enter the second branch". But I must be wrong there, or otherwise how did it panic? Error:
Minified: I'm pretty sure that I saw this ICE before, but I can't find it ;/
This is just a result of having an expression () as a const generic argument. I don't actually think there's a canonical issue, though many of the issues are essentially the same. is the best tracking issue.
No longer ICEs on the latest nightly
Oh, the new output is interesting. It probably needs to be monomorphized so that the compiler detects the infinite recursion. And then we could also write one that doesn't have infinite recursion :3 In order to force an error, a test function should suffice right?
What do you mean?
I mean that I imagined it might detect that the function recurses infinitely onto itself. But I guess it reads it lazily, and lets monomorphization do the job of recursing the function? which would make a lot of sense to me.
Change:
<ins> // run-rustfix fn main() { if 1 == 1 { //~ ERROR invalid comparison operator `===` println!("yup!"); } else if 1 != 1 { //~ ERROR invalid comparison operator `!==` println!("nope!"); } } </ins>

Discussion:
Been working in JavaScript a lot lately and find myself accidentally typing this a lot. It would be nice to automatically detect this and offer a proper fix. Lots of languages use this syntax in addition to JavaScript so it seems like a reasonable error to make. Playground example below. () Errors:
I think the current error message is clear enough. Also I don't think providing auto-fix suggestion is easy, because the error happened when parsing AST.
Nice. But I still think the current error message is fine as is.
don't disagree, but handling it was relatively easy because there's no case where would be valid.
Change:
<ins> warning: the item `String` is imported redundantly --> $DIR/use-redundant-issue-71450.rs:26:13 | LL |         use std::string::String; |             ^^^^^^^^^^^^^^^^^^^ --> $SRC_DIR/std/src/prelude/mod.rs:LL:COL | = note: the item `String` is already defined here | note: the lint level is defined here --> $DIR/use-redundant-issue-71450.rs:3:9 | LL | #![warn(unused_imports)] |         ^^^^^^^^^^^^^^ warning: 1 warning emitted </ins>

Discussion:
This (very contrived) example emits a warning: Playground: This is a false positive because removing results in a compilation error: Same for and .
It seems this regressed somewhere between 1.34.0 and 1.35.0
More accurately, it looks like the false positive has been present since the introduction of the warning in
I was actually a little surprised that did not cause a compilation error due to two imports of the same name at the same level.
I got something similar while implementing ops::Div when removed, it errors
This issue no longer reproduces and can be closed when a corresponding test is .
Change:
"compiletest_rs 0.3.21 (registry+https://github.com/rust-lang/crates.io-index)", "directories 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)", "env_logger 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)", <ins> "hex 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", <ins> "rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "rustc-workspace-hack 1.0.0", "rustc_version 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)", "shell-escape 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
Miri fix: I'd like to see landing before updating the submodule, as that will break Miri again.
This was automatically nominated by rust-highfive. Based on past discussion with about miri-prioritization, tagging as P-medium.
Change:
<ins> // check-pass // revisions: names_before names_after // compile-flags: -Z unstable-options // compile-flags: --check-cfg=names(names_before,names_after) // [names_before]compile-flags: --check-cfg=names(a) --check-cfg=values(a,"b") // [names_after]compile-flags: --check-cfg=values(a,"b") --check-cfg=names(a) #[cfg(a)] //~^ WARNING unexpected `cfg` condition value fn my_cfg() {} #[cfg(a = "unk")] //~^ WARNING unexpected `cfg` condition value fn my_cfg() {} 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. --Run It works if the order of and is swapped. (e.i., ) <!-- 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 backtrace points to in cc label +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Sorry about that. Will fix it. claim
Change:
env_remove.push("IPHONEOS_DEPLOYMENT_TARGET".to_string()); env_remove } <ins> fn ios_deployment_target() -> (u32, u32) { deployment_target("IPHONEOS_DEPLOYMENT_TARGET").unwrap_or((7, 0)) } pub fn ios_sim_llvm_target(arch: &str) -> String { let (major, minor) = ios_deployment_target(); format!("{}-apple-ios{}.{}.0-simulator", arch, major, minor) } </ins>

Discussion:
Currently in our application we cannot run the iOS simulator on M1 machines because it is expecting architecture. Forcing using the target can build the project and ship the application but this targets the iOS Device SDK, and will not build in the simulator for testing with this error: should provide an target that uses the iOS Simulator SDK.
Is relevant at all? Can the same path be followed?
Awesome find I'll try doing this! If successful I'll open a similar PR :)
Ran into this now too. Happy to help here as well. Did you already get started?
I did but having trouble I've pushed my changes here: More than happy to work with you on this Jan!
I'll try to get a dev environment set up and then I'll take a look.
I built the toolchain successfully, but when I try to compile my project (with either or ) I'm getting: I think I've missed a setting in the build config I'm using, because the normal nightly compiles fine :( : Edit looks like I will try off :
Yeah, that looks like upstream breakage in because of recent changes. I can try taking your code tomorrow and throw this against my project to see if that fixes my simulator issues.
Yeah I the patch mentioned in that issue and am getting further but: which Xcode still seems to be getting x8664 somewhere: I tried replacing all the with and got closer: but got:
I believe my current version is working but there's something off in my Xcode project that I need to figure out:
Ah, you're building a binary? Yeah, that seems to sort-of work now? I managed to build your branch, my static library is still unchanged. I think we actually need LLVM 12 first to fully enable this ().
It was just a test to see if the simulator is working at all XD. Yeah my file is still saying it's :