jiebi/CodeConvo huggingface dataset:
Change:
<ins> warning: unused variable: `baz` --> $DIR/dont-try-removing-the-field.rs:12:25 | LL |     let Foo { foo, bar, baz } = x; |                         ^^^ help: try ignoring the field: `baz: _` | = note: `#[warn(unused_variables)]` on by default warning: 1 warning emitted </ins>

Discussion:
I got this error message recently: will work, but just removing completely from the pattern would be better. E.g. the suggestion could be . The particular example was within rustc, but it should be very easy to replicate in a self-contained example. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Is this ? Where does this suggestion come from? Can I please get the path for it!
claim
It's been 3 months - are you still working on this? If not, I'd like to claim it instead.
There was no activity for a while, so I took a liberty of implementing this. claim
Change:
let mut blk = Vec::new(); for (k, v) in env { <del> blk.extend(ensure_no_nuls(k.0)?.encode_wide()); </del> <ins> ensure_no_nuls(k.os_string)?; blk.extend(k.utf16); </ins> blk.push('=' as u16); blk.extend(ensure_no_nuls(v)?.encode_wide()); blk.push(0);

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:
<ins> // Copyright 2016 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(rustc_attrs)] macro_rules! m { () => { #[cfg(any())] fn f() {} } } trait T {} impl T for () { m!(); } #[rustc_error] fn main() {} //~ ERROR compilation successful </ins>

Discussion:
no longer compiles on nightly due to what I think is a regression in macro hygiene: Here we have methods on a trait that are defined by hand, but implemented by macro. The function names are not generated by the macro - they're passed in, so I would not expect any hygiene shenanigans to apply. Possibly ? cc
Thanks for the report! I fixed this in -- it was caused by .
Change:
assert from_str("-.5") == some(-0.5); assert from_str("-.5") == some(-0.5); assert from_str("-5") == some(-5.); <ins> assert from_str("-0") == some(-0.); assert from_str("0") == some(0.); assert from_str("inf") == some(infinity); assert from_str("-inf") == some(neg_infinity); // note: NaN != NaN, hence this slightly complex test alt from_str("NaN") { some(f) { assert is_NaN(f); } none { fail; } } </ins> assert from_str("") == none; assert from_str("x") == none;

Discussion:
Should float::fromstr do the following conversions? "NaN" -float::NaN "inf" -float::infinity "-inf" -float::neginfinity That'd match what float::to_str does (if my pull request is merged.) If this sounds good I'll chuck a patch in.
It will be very good when this will be fixed. There are some additional points to be considered: If I remember correctly, the floating point standard allows for both short ("inf") and long ("infinity") syntax. Are you aware of the other float formatting related issues? I think there used to be a floating point literal parsing problem in rustc for very large literals (not fitting into 32 bits) that is related (can't find the issue right now). Besides adding support for NaN and inf in fromstr/tostr, I personally think rust should define a literal syntax for these, i.e. the compiler should support them directly.
If this is standard behavior for converting from strings than I say go for it.
More things to check proper handling of +0.0 vs -0.0 vs 0.0 hexadecimal notation for the mantissa for the lossless exchange of values
The last one is discusses in . The real kicker would be if all this were supposed by the parser as literal syntax.
Fixed by
Change:
err.emit(); } <del> // We also need to make sure we at least write the ty of the other // arguments which we skipped above. if c_variadic { fn variadic_error<'tcx>(sess: &Session, span: Span, ty: Ty<'tcx>, cast_ty: &str) { use crate::structured_errors::MissingCastForVariadicArg; </del> <ins> for arg in provided_args.iter().skip(minimum_input_count) { let arg_ty = self.check_expr(&arg); </ins> <del> MissingCastForVariadicArg { sess, span, ty, cast_ty }.diagnostic().emit(); } </del> <ins> if c_variadic { // We also need to make sure we at least write the ty of the other // arguments which we skipped above, either because they were additional // c_variadic args, or because we had an argument count mismatch. fn variadic_error<'tcx>(sess: &Session, span: Span, ty: Ty<'tcx>, cast_ty: &str) { use crate::structured_errors::MissingCastForVariadicArg; </ins> <del> for arg in provided_args.iter().skip(expected_arg_count) { let arg_ty = self.check_expr(&arg); </del> <ins> MissingCastForVariadicArg { sess, span, ty, cast_ty }.diagnostic().emit(); } </ins> // There are a few types which get autopromoted when passed via varargs // in C but we just error out instead and require explicit casts.

Discussion:
If using format inside a closure (e.g. in iter functions) and the returning String is passed into a function that takes less args, rustc panics. Minimized code snippet: version: 1.60.0-beta.2 and 1.61.0-nightly query: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
playground link:
Probably duplicate of
Actually, not sure if it's a duplicate of . Still failing on master after the fix for that one landed, and failed with the same error (and not a duplicated adjustment bug) on beta. I will look into it! claim
Minimized:
Change:
#[inline] fn exp(self) -> f32 { num::Float::exp(self) } #[inline] <del> fn exp2(self) -> f32 { num::Float::exp(self) } </del> <ins> fn exp2(self) -> f32 { num::Float::exp2(self) } </ins> #[inline] fn ln(self) -> f32 { 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:
#![doc(html_root_url = "https://doc.rust-lang.org/nightly/")] #![feature(nll)] <ins> #![feature(once_cell)] </ins> #![recursion_limit = "256"] #[macro_use]

Discussion:
After is merged, usage of in this module: should be replaced by . The dependency from corresponding can be removed afterwards. It might make sense to request a perf run, as version uses parkinglot, while the standard one uses std mutex, but I expect the difference to not matter -- fast path is equivalent for both.
claim
is done! Though, I am not unsure if we maybe should wait until it tickles down to beta? Not sure how bootstraping works with libstd, I guess, we can just try and see if the build fails.
The compiler always builds with the in-tree standard library, so cfg(bootstrap) should never be necessary (beyond lints, and other compiler-implemented rather than library-implemented) details.
ping this is ready to be implemented.
I'll start soon! Sorry I got a bit overwhelmed with work. If in the next couple of days I haven't replied feel free to re-assign.
On it!
once this is merged, should other sub-crates that depend on also be updated? Like for example. Also, what about ? Some usage can probably be replaced by .
We definitely should actively remove oncecell crate from all rustc’s crates, because having two difference sources of the same data structure feels bad. Replacing lazystatic with std::lazy would also be good!
I'll try to take of it once this issue is fixed :+1:
Change:
u: IO_STATUS_BLOCK_union, pub Information: usize, } <ins> impl IO_STATUS_BLOCK { pub fn status(&self) -> NTSTATUS { // SAFETY: If `self.u.Status` was set then this is obviously safe. // If `self.u.Pointer` was set then this is the equivalent to converting // the pointer to an integer, which is also safe. // Currently the only safe way to construct `IO_STATUS_BLOCK` outside of // this module is to call the `default` method, which sets the `Status`. unsafe { self.u.Status } } } </ins> pub type LPOVERLAPPED_COMPLETION_ROUTINE = unsafe extern "system" fn( dwErrorCode: DWORD,

Discussion:
on windows. with and rename it back to git bash I expected to see this happen: my really long string gets printed twice, followed by a clean exit Instead, this happened: some amount of my really long string gets printed, followed by: The test case, while simple, does appear to have a minimum size requirement to trigger this crash. Shrinking the string will cause it to stop crashing. I'm using in the steps for simplicity, but we've observed this happening with other programs at the end of the pipe too. Redirecting to a file instead of a pipe seems to not trigger this crash. Using is not necessary to trigger the crash, running the built executable directly also crashes. This PR this new error condition: I am not the only one seeing this new error message: modify labels: +regression-from-stable-to-stable +O-windows
I believe this must be because git bash (cygwin? msys?) is opening pipes between processes with . In my original bug report, I suggested calling once if returned , since that will at least resolve the pending IO correctly in the case where the file is not being used for other IOs concurrently. This would cover this and other cases at least as well as the original code calling . This isn't perfect, since of course takes , so you can probably deadlock in a multi-threaded process in this async pipe configuration. But it would at least avoid the common case. However, it seems that this got missed from the actual change (sorry, I should have caught that). Is there a reason this was skipped?
Oh, hrm. That looks like an oversight on my part. I'll PR a fix asap.
Thanks for fixing the issue quickly. When the PR that fixes this issue is merged, will a patch release 1.62.1 be published? Or will we have to wait for a fix in 1.63?
PR was nominated and accepted for both beta and stable backport by T-libs. Leaving this open until those play out. Assigning P-high for the same reasons it was accepted for backports.
Change:
name = "rustc_errors" version = "0.0.0" dependencies = [ <del> "annotate-snippets 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "annotate-snippets 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "atty 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", "rustc_data_structures 0.0.0",

Discussion:
Part of To support lines in the first column of UI test output, we have to make use of the flag and update the library. Relevant : The relevant PR in the annotate-snippet library and a new version needs to be released. Once that's done, we have to pass as a second argument to . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
modify labels: A-diagnostics E-help-wanted
claim
Change:
opt::opt_s( "", "edition", <del> "Specify which edition of the compiler to use when compiling code.", </del> <ins> &*EDITION_STRING, </ins> EDITION_NAME_LIST, ), opt::multi_s(

Discussion:
rustc --edition: rustc --edition=help: --editionhelprustc --help The default is not mentioned anywhere. I assume it is 2015? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The default is indeed 2015. It should probably not only mention the default (2015) but also the latest stable edition (2021).
Mentoring instructions: modify to include and somewhere.
claim
What is the best way to insert the values for and into the string? only takes 's and I don't see an easy way to create one while inlining those variables. Neither nor works - former only accepts literals rather than the static variable, and the latter would create a &str, but then drop a temporary variable. I don't believe it would be a good idea to simply write the value of these variables into the string, so I'm wondering what other options I have. However, if that's the way forward, I can do so.
Where does that requirement come from? Seems fine to loosen it.
ah I see, the string ends up stored in RustcOptGroup. Honestly, given that this is only used once and the string is tiny, using seems fine.
Change:
/// Build linunwind.a fn run(self, builder: &Builder<'_>) -> Self::Output { <ins> builder.update_submodule(&Path::new("src/llvm-project")); </ins> if builder.config.dry_run() { return PathBuf::new(); }

Discussion:
I cloned the Rust repo with the intention of building rustc for cross-compilation to the target. I did the following: selected the "codegen" option the file to append: This failed; the end of the output is as follows: After I executed and retried the build command, the LLVM submodule was checked out and the build was able to make progress. It seems like this should be done automatically. I'm not sure if the issue is specific to this target or if it's happening with other cross-compilation targets. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hmm. This is some interaction between and cross-compiling, but I'm not sure exactly what — it should be a no-op unless you're building for the host. As a workaround you can set and that should handle the submodule automatically.
(Note that is implied by .)
Ok, it looks like we only try to build crtbegin.o for musl targets: So I think we would have checked out the submodule if we were doing a full LLVM build, but because we're only building the CRT it got missed when download-ci-llvm was implemented. I think the simplest fix is to call at the start of , like we do for the step:
looks like it also has the same bug: as well as :
claim
Does fixing also come under the scope of this issue? I'd be happy to fix that as well.
sure thing, feel free to fix all three at once :)
Do I pause work on this till gets resolved? Since it's implementing the workaround you mentioned as a solution
no, this fix still makes sense - not everyone is using the profile without changes.
Change:
LL | fn f(_: X) -> X { |               ^ | <del> = note: lifetimes appearing in an associated type are not considered constrained </del> <ins> = note: lifetimes appearing in an associated or opaque type are not considered constrained = note: consider introducing a named lifetime parameter </ins> error[E0581]: return type references lifetime `'a`, which is not constrained by the fn input types --> $DIR/issue-47511.rs:12:23

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. --. Prior to , these types were rejected with this error: Currently, they're accepted. Based on the assumption that generic parameters on opaque type are not constrained (see Niko's comment ), I believe the previous behavior is correct. CC: label F-typealiasimpl_trait A-impl-trait T-compiler A-lifetimes
Out of curiosity, here's an exploit derived from . It type-checks but fails at monomorphization.
The above exploit is and should be easier to do with , where indirection through would not be necessary, so label I-unsound requires-nightly T-types
if the same code were written without lifetime params and used arguments instead, we'd see the same problem before , right?
Sorry, I've clearly missed the notification :sweat_smile:. I think you already know the answer given that you've just pushed a fix :).
Change:
pub struct Foo { pub field: i32, } <ins> pub fn missing_optimized_mir() { println!("indeed"); } </ins>

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:
Values { iter: self.iter().map(second) } } <del> /// Returns an iterator visiting all key-value pairs in ascending order by the keys. </del> <ins> /// Returns an iterator visiting all key-value pairs in ascending order of the keys. </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:
} if !tcx.is_mir_available(def_id) { <del> bug!("no MIR available for {:?}", def_id); </del> <ins> tcx.sess.emit_fatal(NoOptimizedMir { span: tcx.def_span(def_id), crate_name: tcx.crate_name(def_id.krate), }); </ins> } true

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:
before=link_range.start - last_new_line_offset, found=link_range.len(), )); <ins> diag </ins> } <del> diag </del> } else { cx.tcx.struct_span_lint_node(lint::builtin::INTRA_DOC_LINK_RESOLUTION_FAILURE, NodeId::from_u32(0),

Discussion:
Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs:
Change:
<ins> // check-pass // compile-flags: -Zmir-opt-level=3 #![feature(type_alias_impl_trait)] trait T { type Item; } type Alias<'a> = impl T<Item = &'a ()>; struct S; impl<'a> T for &'a S { type Item = &'a (); } fn filter_positive<'a>() -> Alias<'a> { &S } fn with_positive(fun: impl Fn(Alias<'_>)) { fun(filter_positive()); } fn main() { with_positive(|_| ()); } </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. --Here's MCVE: (Edited by JohnTitor) Prettied a bit: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Just for reference - works fine with explicit lifetimes:
modify labels: +requires-nightly +F-typealiasimpl_trait
Smaller:
Seems this is fixed in the latest nightly (not bisected yet). Marking as and will try to bisect later.
Still crashes with Ohh, good catch! Still, the regression test here is useful but let's keep this open then :) Oops, closed by mistake XD
Bisected, it's fixed by .
This ICEs again now:
Because of , dropped .
This no longer crashes with rustc-git ! modify labels: E-needs-test
Hm, I was too quick. It no longer crashes because it misses a feature gate. ` If I add the gate, it crashes again :/ modify labels: E-needs-test
cc which probably fixes this
Seems to be fixed again