jiebi/CodeConvo huggingface dataset:
Change:
mod tests; use crate::borrow::Borrow; <ins> use crate::cmp; </ins> use crate::collections::BTreeMap; use crate::convert::{TryFrom, TryInto}; use crate::env;

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:
} else { self.report_unknown_field(adt_ty, variant, field, ast_fields, kind_name); } <del> } </del> <ins> tcx.types.err }; </ins> // Make sure to give a type to the field even if there's // an error, so we can continue typechecking <del> let ty = self.check_expr_with_hint(&field.expr, field_type_hint); self.demand_coerce(&field.expr, ty, final_field_type); </del> <ins> self.check_expr_coercable_to_type(&field.expr, field_type); </ins> } // Make sure the programmer specified correct number of fields.

Discussion:
fails to type check, while succeeds.
This coercion is important when using byte string literals.
The tuple struct case is actually the function call "expected type" propagation, which would have to be adapted to struct literals as well.
Yes.
Coercion already happens in non-generic struct literals:
Yes, but the field types are taken from the struct and not combined with the overall expected type for the struct literal.
I just discovered this bug/unexpected behavior today (). I would like to see some movement on it because it's surprising that these two don't work the same way. Here's a workaround I found; it's ugly as hell but I'm using it in a generated file that no human would want to look through anyway: I tried type ascription but it seems to not cue coercion, it just moves the type error: It seems that forcing a concrete type on the struct literal works as well (I didn't expect this syntax to work, honestly): Unfortunately this won't work for me because I'm using too and I can't add this extra syntax myself.
Any news on this?
Is anyone working on it?
It seems like implemented a partial fix in but suggests that there are backwards incompatibility issues to be considered that preventing him from going further. I'm not quite sure what he had in mind there, perhaps he can elaborate.
Making sure we remember to look at this.
What I did is I computed a "light hint" (which becomes "strong hint", i.e. forcing coercion, if it reaches a block, and it's enough to help integer inference for ). This is a common problem with coercion hints, in that unless there's enough type information to prevent them from triggering, they will trigger early even if that breaks later on. The thing to try here is to replace with the simpler: doesn't even need to be computed if that works, since is at least as specific - AFAICT, we already have that "specificity" with function calls, but since it hasn't been used with struct literals before, crater/cargobomb might reveal regressions.
ok, I was mostly wondering if you encountered actual regressions in practice, or just theorize that this might lead to problems.
I don't think I got the chance to do a crater run and then I lost track of it.
will open a PR and we can try a crater run at least.

There is still a similar problem with the type inference of temporaries when you have an array that should be interpreted as a slice buried in a tuple inside an outer slice.
Change:
source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "2e7573632e6454cf6b99d7aac4ccca54be06da05aca2ef7423d22d27d4d4bcd8" dependencies = [ <del> "libc 0.2.112", </del> <ins> "libc", </ins> "rand_chacha", "rand_core", "rand_hc",

Discussion:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.
Change:
use anyhow::{Context, Error}; use flate2::{read::GzDecoder, write::GzEncoder}; use rayon::prelude::*; <del> use std::{convert::TryFrom, fmt, io::Read, io::Write, path::Path, str::FromStr}; </del> <ins> use std::{fmt, io::Read, io::Write, path::Path, str::FromStr}; </ins> use xz2::{read::XzDecoder, write::XzEncoder}; #[derive(Default, Debug, Copy, Clone)] pub enum CompressionProfile { <ins> NoOp, </ins> Fast, #[default] Balanced,

Discussion:
Right now when doing a local , we first compress the artifacts with max compression ratio, just to immediately unpack them again when installing them to disk. Making the compression level less aggressive or skipping it altogether can probably save 5-10 minutes on an x.py install. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc You probably want to use the gzip'd artifacts which are less intensely compressed.
tbh it seems strange that we're compressing these at all - why not put them into an uncompressed .tar archive when using ?
or even better, copy them directly from the build directory to the install directory without going through a .tar archive first.
claim
Skipping the compressions and archiving in favor of directly copying the artifacts seems like a reasonable solution for . But it requires significant changes to how we currently handle . I'm planning to do a comprehensive review on bootstrapping from all angles(including T-bootstrap issues) and make a roadmap for future development. To avoid conflicts(e.g, if we have improvement ideas on dist/install modules, implementing this might increase the technical debt which will require more effort from the team), I will postpone this task for now and re-prioritize it once we have organized the plans.
Change:
<ins> // check-pass // edition:2021 // for the `impl` + keyword test macro_rules! impl_primitive { ($ty:ty) => { compile_error!("whoops"); }; (impl async) => {}; } impl_primitive!(impl async); 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: Macro is expanded to Instead, this happened: On stable it works as expected. On beta and nightly it fails with the following error It is probably caused by fragment that now treats as a start of type. So makes sense. But breaks existing code :) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
searched nightlies: from nightly-2022-06-01 to nightly-2023-02-01 regressed nightly: nightly-2023-01-18 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsI think I see where the issue is, I'll fix it. claim
WG-prioritization assigning priority (). label -I-prioritize +P-high
IIRC issues with a backport pending should stay open to track the backport process (not 100% sure tho)
beta backport in
Change:
// Otherwise proceed with linting. _ => {} } <del> let spans = if value.span.from_expansion() || inner.span.from_expansion() { ( value.span.with_hi(value.span.lo() + BytePos(1)), value.span.with_lo(value.span.hi() - BytePos(1)), ) </del> <ins> let spans = if let Some(inner) = inner.span.find_ancestor_inside(value.span) { Some((value.span.with_hi(inner.lo()), value.span.with_lo(inner.hi()))) </ins> } else { <del> (value.span.with_hi(inner.span.lo()), value.span.with_lo(inner.span.hi())) </del> <ins> None </ins> }; <del> self.emit_unused_delims(cx, spans, "pattern", (false, false)); </del> <ins> self.emit_unused_delims(cx, value.span, spans, "pattern", (false, false)); </ins> } } }

Discussion:
Reported by here: (Note that but does not fix this bug.)
searched nightlies: from nightly-2021-01-07 to nightly-2021-12-24 regressed nightly: nightly-2021-09-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This regression was introduced in . cc
Not a fix, but if I make this change then there is no longer an ICE and I get
Thanks for opening the issue If someone finds a fix but doesn't know how to add the test, this pull request which solves a similar ICE has an example of how to add a test when there is a missing newline:
Change:
use rustc_middle::hir::nested_filter; use rustc_middle::ty::TyCtxt; use rustc_span::def_id::{CRATE_DEF_ID, LOCAL_CRATE}; <ins> use rustc_span::hygiene::MacroKind; </ins> use rustc_span::symbol::{kw, sym, Symbol}; use rustc_span::Span;

Discussion:
If we run with the option on this code: Both and are documented, but not being accessible outside of , it shouldn't be documented.
probably knows this, but for others seeing this issue, I think it's probably due to (which was reverted in , and later re-applied in ). It has to do with the fact that we're using a HIR visitor now, so we're visiting nested items unconditionally.
Yes I know where it's coming from. :smile: I was just thinking today that since we were going through the whole HIR without checking whether or not we were in a block, all elements inside the block could be visible. Tested and... :fearful: Should be pretty easy to fix.
For reference, I put up because this was causing documentation to become really verbose with serde + . If you fix this such that we no longer document those items, we could probably revert that PR.
Indeed. Don't hesitate to come to me if you have such issues with rustdoc. Such problems should definitely not go unnoticed.
The thing is, it was not particularly clear from the PRs whether this was intentional or not.
Unfortunately it wasn't. The goal was to retrieve the missing impl blocks. But if anything isn't clear, don't hesitate to ask too. :wink:
Change:
/// /// # Examples /// <del> /// ```no_run </del> <ins> /// ``` /// # use std::io; </ins> /// use std::net::{TcpListener, TcpStream}; /// <del> /// let listener = TcpListener::bind("127.0.0.1:80").unwrap(); /// </del> /// fn handle_client(stream: TcpStream) { ///     // ... /// } /// <ins> /// # fn process() -> io::Result<()> { /// let listener = TcpListener::bind("127.0.0.1:80").unwrap(); /// </ins> /// // accept connections and process them serially /// for stream in listener.incoming() { <del> ///     match stream { ///         Ok(stream) => { ///             handle_client(stream); ///         } ///         Err(e) => { /* connection failed */ } ///     } </del> <ins> ///     handle_client(stream?); </ins> /// } <ins> /// # Ok(()) /// # } </ins> /// ``` #[stable(feature = "rust1", since = "1.0.0")] pub struct TcpListener(net_imp::TcpListener);

Discussion:
The iterator never returns , so the at the end will never be reached. The explicit matching against the socket result also seems potentially nonconventional docs-wise?
Also, what are the semantics of this iterator when the listener is set to nonblocking mode? If it's equivalent to it should run the loop with errors until a connection is made.
That's what it'd do, yeah. The method is super simple:
Change:
<ins> error[E0515]: cannot return value referencing function parameter `x` --> $DIR/return-disjoint-regions.rs:4:5 | LL |     let y = &x; |             -- `x` is borrowed here LL |     (y, y) |     ^^^^^^ returns a value referencing data owned by the current function error: aborting due to previous error For more information about this error, try `rustc --explain E0515`. </ins>

Discussion:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.
Change:
<ins> // Copyright 2018 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. #include "llvm/Linker/Linker.h" #include "rustllvm.h" using namespace llvm; struct RustLinker { Linker L; LLVMContext &Ctx; RustLinker(Module &M) : L(M), Ctx(M.getContext()) {} }; extern "C" RustLinker* LLVMRustLinkerNew(LLVMModuleRef DstRef) { Module *Dst = unwrap(DstRef); auto Ret = llvm::make_unique<RustLinker>(*Dst); return Ret.release(); } extern "C" void LLVMRustLinkerFree(RustLinker *L) { delete L; } extern "C" bool LLVMRustLinkerAdd(RustLinker *L, char *BC, size_t Len) { std::unique_ptr<MemoryBuffer> Buf = MemoryBuffer::getMemBufferCopy(StringRef(BC, Len)); #if LLVM_VERSION_GE(4, 0) Expected<std::unique_ptr<Module>> SrcOrError = llvm::getLazyBitcodeModule(Buf->getMemBufferRef(), L->Ctx); if (!SrcOrError) { LLVMRustSetLastError(toString(SrcOrError.takeError()).c_str()); return false; } auto Src = std::move(*SrcOrError); #else ErrorOr<std::unique_ptr<Module>> Src = llvm::getLazyBitcodeModule(std::move(Buf), L->Ctx); if (!Src) { LLVMRustSetLastError(Src.getError().message().c_str()); return false; } #endif #if LLVM_VERSION_GE(4, 0) if (L->L.linkInModule(std::move(Src))) { #else if (L->L.linkInModule(std::move(Src.get()))) { #endif LLVMRustSetLastError(""); return false; } return true; } </ins>

Discussion:
I noticed my project took noticeably longer to build with "lto=true" at some point. I benchmarked link time (touch ; cargo build --release) which appear to blow up as soon as we have several codegen units. link times: So it seem codegen-units=1 makes for bad parallelism while building but speeds up lto because less translation units need to be merged. Maybe it is possible to dynamically use as little codegen units as possible (but still enough to utilize all cores) when building? //cc
Or maybe just don't use multiple codegen units by default when monolithic LTO is enabled.
I think the optimal "balance" for linktime/buildtime with monolithic lto would be to 1) compile all crates with codgen-units=1 as long as we can compile several crates in parallel. 2) if we have to compile a single crate at a time, use ${thread_number} codegen units. However this will probably introduce indeterministic builds depending on the number of threads a host machine has. So a single core machine would optimize better than a 8 core machine when building the same crate with monolithic lto. :/
I made some benchmarks (cpu: i5-2540M dual core), rustc 1.25.0-nightly ( 2018-02-11) `
I believe this is fixed in
er, didn't mean to close yet
Change:
<Self as UnusedDelimLint>::check_expr(self, cx, e) } <ins> fn check_expr_post(&mut self, _cx: &EarlyContext<'_>, e: &ast::Expr) { if let ExprKind::Binary(op, lhs, _rhs) = &e.kind && (op.node == ast::BinOpKind::Lt || op.node == ast::BinOpKind::Shl) && let ExprKind::Cast(_expr, ty) = &lhs.kind && let ast::TyKind::Paren(_) = &ty.kind { let id = self.parens_in_cast_in_lt.pop().expect("check_expr and check_expr_post must balance"); assert_eq!(id, ty.id, "check_expr, check_ty, and check_expr_post are called, in that order, by the visitor"); } } </ins> fn check_pat(&mut self, cx: &EarlyContext<'_>, p: &ast::Pat) { use ast::{Mutability, PatKind::*}; let keep_space = (false, false);

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: But with the suggestion applied the compiler displays an error with a different suggestion: <!-- The following is not always necessary. --Ideally the compiler should not output a warning and treat and as identical. <!-- 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. -- label D-incorrect A-suggestion-diagnostics <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I think it's relate with and
It would be great if it could give since parenthesizing the expression instead avoids the potential "is that a tuple?" confusion of .
Duplicate of .
Change:
} } <ins> query is_impossible_method(key: (DefId, DefId)) -> bool { desc { |tcx| "checking if {} is impossible to call within {}", tcx.def_path_str(key.1), tcx.def_path_str(key.0), } } </ins> query method_autoderef_steps( goal: CanonicalTyGoal<'tcx> ) -> MethodAutoderefStepsResult<'tcx> {

Discussion:
Found in [this topic] on URLO. It shows the method on the page for . This is misleading, because you can't actually call that method, because . [this topic]: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The same issue with and . do you know how to exclude these options from hashmap? I'm still digging with it, if hashmap has this kind of issue, other data structures maybe have similar kind of issue. I think we need to check the trait bounds when generating the doc.
I expect you want to do it while — turning the rustc IR into rustdoc's own IR — or earlier. Doing it later would mean reimplementing parts of rustc's type checker using rustdoc's IR, and nobody wants to do that.
For the record I was working on this, sorry for not claiming this... Anyways, let me know if you don't get around to this, and I'll pick it back up :smile_cat: . Seems like you've claimed a few issues in the past hours so not sure which ones you've gotten started with.
I haven't started this one, released it, please go ahead. It's funny and also helpful to learn some Rust internals, I'm starting with some trivial fixes
Thank you Sorry for the mistake, and I am excited for you to get involved more in the compiler :) claim
This is a dupe of
Uh, sorry, actually not a dupe. That's impl level, this is method level. I think there were legitimate concerns with hiding whole impls in that other issue. Reopening this, andf I'll probably solve this first.
Change:
<ins> error: any use of this value will cause an error --> $DIR/uninhabited-const-issue-61744.rs:8:5 | LL |     fake_type() |     ^^^^^^^^^^^ |     | |     tried to call a function with return type T passing return place of type ! |     inside call to `hint_unreachable` at $DIR/uninhabited-const-issue-61744.rs:4:5 |     inside call to `fake_type::<i32>` at $DIR/uninhabited-const-issue-61744.rs:12:36 ... LL |     const CONSTANT: i32 = unsafe { fake_type() }; |     --------------------------------------------- | = note: #[deny(const_err)] on by default error[E0080]: erroneous constant used --> $DIR/uninhabited-const-issue-61744.rs:18:10 | LL |     dbg!(i32::CONSTANT); |          ^^^^^^^^^^^^^ referenced constant has errors error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0080`. </ins>

Discussion:
Probably one should never write this, and I wonder if it will be disallowed in the future. Happens on stable, beta and nightly, in all const-forms existing (includes const generics) <details<summaryBacktrace:</summary</details
Note: You could also write it the following way, in order to not need the attribute, as the previous code complains about recursion without that attribute.
Regression introduced in
cc due to Edit: I think I have a fix for this.