jiebi/CodeConvo huggingface dataset:
Change:
/// Copies the `src` directory recursively to `dst`. Both are assumed to exist /// when this function is called. Unwanted files or directories can be skipped /// by returning `false` from the filter function. <del> pub fn cp_filtered<F: Fn(&Path) -> bool>(src: &Path, dst: &Path, filter: &F) { </del> <ins> pub fn cp_filtered(src: &Path, dst: &Path, filter: &Fn(&Path) -> bool) { </ins> // Inner function does the actual work <del> fn recurse<F: Fn(&Path) -> bool>(src: &Path, dst: &Path, relative: &Path, filter: &F) { </del> <ins> fn recurse(src: &Path, dst: &Path, relative: &Path, filter: &Fn(&Path) -> bool) { </ins> for f in t!(fs::read_dir(src)) { let f = t!(f); let path = f.path();

Discussion:
The process of creating the tarballs doesn't include .gitignore files from src/vendor. This results in a missmatched hash failure when building with vendoring enabled. Hoping to switch to rustbuild with the next rust release! FYI: I'd be happy with the vendoring happening during the create tarball process, having enormous vendoring commits in the git history is ugly... !
Needs to be fixed for 1.15.
cc
Seems like the vendoring process should include a sanity check that the vendored sources hash correctly.
Fixed in
Things move fast around here. Awesome thanks!
Change:
<ins> // `unused_crate_dependencies` is not currently in the `unused` group // due to false positives from Cargo. // check-pass // aux-crate:bar=bar.rs #![deny(unused)] fn main() {} </ins>

Discussion:
lint introduced in causes false positives for . To reproduce: I expected to execute correctly. Instead, this happened: I expect to be ignored by this lint, because they are in fact used in modules. "remove the dependency or add " help message is also unhelpful, because it will cause unresolved imports for and similar commands. : <details<summaryFull verbose build log</summary<p</p</details
cc needs to be removed from the lint group, I didn't notice this when reviewing Otherwise it can be enabled in a blanket way without enabling specifically, which is undesirable given the amount of redundant options passed by Cargo.
Fixed in
Yeah this is the reason it's not on by default. We still need to work out if/how it can be used with cargo in a reasonable way. Adding it to made sense to me but I didn't think through the fallout.
Though TBH I'm a bit confused - what targets is Cargo passing dev-dependencies to aside from tests? I would have thought your case would be OK. Hm, I think there may be another bug that isn't seeing uses in blocks. At the very least it needs a test for that.
As far as I can tell, this issue wasn't fixed, was just removed from the group. The functionality of is still desirable! See
Change:
use rustc_middle::mir; use rustc_middle::ty::{self, TyCtxt}; use rustc_span::{source_map::DUMMY_SP, symbol::Symbol}; <del> use rustc_target::abi::VariantIdx; </del> use crate::interpret::{intern_const_alloc_recursive, ConstValue, InternKind, InterpCx};

Discussion:
Followup to I think we only have one use site of left: and it iterates over all fields anyway. So we can call instead and iterate over the resulting fields. There should be no more results for searching in the rust source after this, so some comments may need updating to mentioning instead of . These mentoring instructions are a bit vague, I do realize that, so if you encounter any hickup of any magnitude, don't hesitate to write here or contact me via discord/zulip. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
EDIT: Okay, it is a word. Still, to me "destruct" sounds better. But maybe that's just because I am used to theorem provers?
Change:
<ins> fn main() {} struct CLI { #[derive(parse())] //~^ ERROR traits in `#[derive(...)]` don't accept arguments //~| ERROR cannot find derive macro `parse` in this scope //~| ERROR cannot find derive macro `parse` in this scope path: (), //~^ ERROR `derive` may only be applied to structs, enums and unions } </ins>

Discussion:
` :
This crashes on stable, beta and nightly.
cc
says this regressed between releases 1.40 and 1.41.
triage: P-high to bisect and determine severity. Removing nomination. Added stable-to-stable regression label.
searched nightlies: from nightly-2019-11-01 to nightly-2020-02-25 regressed nightly: nightly-2019-12-08 searched commits: from to regressed commit: source code: Confirmed automated tests with manual run using <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details<details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details
modify labels: -E-needs-bisection
Maybe
Reduced:
Fixed by
Change:
$$(HLIB$(2)_H_$(4))/$(CFG_RUSTLLVM_$(4))  $$(HCORELIB_DEFAULT$(2)_H_$(4))  $$(HSTDLIB_DEFAULT$(2)_H_$(4))  <del> | $$(HBIN$(2)_H_$(4))/ </del> <ins> | $$(HLIB$(2)_H_$(4))/ </ins> @$$(call E, cp: $$@) $$(Q)cp $$< $$@ $$(Q)cp -R $$(TLIB$(1)_T_$(4)_H_$(3))/$(LIBSYNTAX_GLOB_$(4)) 

Discussion:
There comes a time in the life of every Rust developer when they have to blow away various parts of the directory to avoid messages about "multiple matching crates". Then when they do the next build they get things like: . It would be better if the Makefile would just create all the needed parent directories automatically.
+1
I'm pretty sure I know how to do this. (I think the right tools for the job are some in and )
I haven't actually waited for a whole build to go through yet, and I have to leave for the evening. But I'd welcome it if you would be willing to pull this (SHA: ) into your repo and give it a spin. If you don't get around to it, no sweat; it can obviously wait until Monday.
argh ignore comment above; the commit isn't anywhere near fully baked yet; somethings off with my make syntax.
Okay. It would be nice to do this in the interim, but eventually when rustpkg is the build system it will do this (much more easily than with Makefile hacking), so no sweat if you don't get it done :-)
Change:
// If this is a break with a value, we need to type-check // the expression. Get an expected type from the loop context. let opt_coerce_to = { <ins> // We should release `enclosing_breakables` before the `check_expr_with_hint` // below, so can't move this block of code to the enclosing scope and share // `ctxt` with the second `encloding_breakables` borrow below. </ins> let mut enclosing_breakables = self.enclosing_breakables.borrow_mut(); <del> enclosing_breakables.find_breakable(target_id) .coerce .as_ref() .map(|coerce| coerce.expected_ty()) </del> <ins> match enclosing_breakables.opt_find_breakable(target_id) { Some(ctxt) => ctxt.coerce.as_ref().map(|coerce| coerce.expected_ty()), None => { // Avoid ICE when `break` is inside a closure (#65383). self.tcx.sess.delay_span_bug( expr.span, "break was outside loop, but no error was emitted", ); return tcx.types.err; } } </ins> }; // If the loop context is not a `loop { }`, then break with

Discussion:
The following code ICE's on stable, beta and nightly: <details<summaryBacktrace:</summary</details
reduced
This is not an bug, here's another reproducer for the same bug: EDIT: Fix coming ...
A closure is just enough: modify labels: -A-async-await +A-closures
Change:
// taken from https://github.com/rust-lang/rust/issues/70507#issuecomment-615268893 struct Foo; impl Foo { <del> fn foo<const N: usize>(self) {} </del> <ins> fn foo<const A: usize, const B: usize>(self) {} </ins> } fn main() { Foo.foo();

Discussion:
At the moment, we simply emit errors like: It would be good to suggest to the user how to fix this, like with uninferred type arguments.
cc
Stu over has picked this issue up.
Change:
<ins> #![feature(extended_key_value_attributes)] #![feature(rustc_attrs)] #[rustc_dummy = stringify!(a)] // OK macro_rules! bar { () => {}; } // FIXME?: `bar` here expands before `stringify` has a chance to expand. // `#[rustc_dummy = ...]` is validated and dropped during expansion of `bar`, // the "unexpected token" errors comes from the validation. #[rustc_dummy = stringify!(b)] //~ ERROR unexpected token: `stringify!(b)` bar!(); 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. --Found an ICE with when trying to use it in the standard library (). cc . <!-- 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
I can hit an additional ICE by using an unknown attribute instead of a valid one: <details<summary<strongBacktrace</strong</summary<p</p</detailsI don't really think it's useful for this issue though, since it's a delayed error.
Fixed in
Change:
use std::{cmp, env, fs}; use build_helper::exit; <del> use build_helper::git::GitConfig; </del> <ins> use build_helper::git::{output_result, GitConfig}; </ins> use serde::{Deserialize, Deserializer}; use serde_derive::Deserialize;

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: in is not specified explicitly, the default value is used. I expected to see this happen: LLVM is downloaded from CI, when LLVM version is bumped the new LLVM is downloaded from CI as well. Instead, this happened: LLVM starts building from source code after an LLVM update, instead of being downloaded, unless I remove the build directory and do a fresh build, then it starts downloading from CI again. <!-- 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. --:
Or maybe it's a stage0 toolchain update that triggers this issue, not LLVM update (I observed this today). But I've seen this issue several times in the past as well. cc
The section in is completely empty, nothing is overridden.
Update: LLVM is built from source only on the first build attempt, after that it is correctly downloaded from CI.
This is still an issue that I observe regularly.
There were some issues with the change detection logic for LLVM and I think should fix it. Let's see if it still happens with the next LLVM update.
Change:
} } <ins> struct LocalReturnTyVisitor<'ck, 'mir, 'tcx> { kind: LocalKind, checker: &'ck mut Checker<'mir, 'tcx>, } impl<'ck, 'mir, 'tcx> TypeVisitor<TyCtxt<'tcx>> for LocalReturnTyVisitor<'ck, 'mir, 'tcx> { fn visit_ty(&mut self, t: Ty<'tcx>) -> ControlFlow<Self::BreakTy> { match t.kind() { ty::FnPtr(_) => ControlFlow::Continue(()), ty::Ref(_, _, hir::Mutability::Mut) => { self.checker.check_op(ops::ty::MutRef(self.kind)); t.super_visit_with(self) } _ => t.super_visit_with(self), } } } </ins> pub struct Checker<'mir, 'tcx> { ccx: &'mir ConstCx<'mir, 'tcx>, qualifs: Qualifs<'mir, 'tcx>,

Discussion:
Proposing to extract this from . The following examples shouldn't error: While this has been considered part of for a while, it's also been acknowledged as a bug and suggested by to address separately ahead of stabilizing . Indeed it's surprising for users that this would count as handling a mutable reference in const contexts. See: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Cc Fixing this requires changing to skip traversing things inside function pointers. I'm not sure what the best way to achieve that is.
claim
Is there any reason returning a function trait object (e.g. , , etc.) does not work? It works with the feature, but IMO it should have been pulled out like the function pointers. For example this does not compile:
We didn't exhaustively look through all cases that we can exempt here. Anyway, is on the , so this question will be moot soon. :)
Change:
emit_metadata: EmitMetadata, allow_unused: AllowUnused, ) -> Command { <del> let is_rustdoc = self.is_rustdoc(); </del> <ins> let is_aux = input_file.components().map(|c| c.as_os_str()).any(|c| c == "auxiliary"); let is_rustdoc = self.is_rustdoc() && !is_aux; </ins> let mut rustc = if !is_rustdoc { Command::new(&self.config.rustc_path) } else {

Discussion:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.
Change:
error[E0282]: type annotations needed <del> --> $DIR/expect-two-infer-vars-supply-ty-with-bound-region.rs:8:27 </del> <ins> --> $DIR/expect-two-infer-vars-supply-ty-with-bound-region.rs:8:5 </ins> | LL |     with_closure(|x: u32, y| {}); <del> |                           ^ consider giving this closure parameter a type </del> <ins> |     ^^^^^^^^^^^^ cannot infer type for type parameter `B` declared on the function `with_closure` </ins> error: aborting due to previous error

Discussion:
This compiles just fine: But this gives a compiler error: It seems really weird that the second statement is affected like this? Empty project (created with ), unmodified (so no extra dependencies): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It is actually that the first statement has type error, but somehow the error is reported to the second statement. The first statement alone reports the error correctly and by fixing the error, the following compiles fine
This happens on Nightly and on Stable.
Labeling as this was a regression introduced by 1.41.0.
Assigning .
Problem seems to be that we always assume the last closure was the source of the inference failure
Just sticking a return after is enough to get the correct diagnostic in this specific instance. However, we clearly need to be smarter than that, as in a sequence of closures, any of them could be the source of an inference error (current implementation always assumes last, just adding a return always assumes first).
Definitely not the case - looking into some alternative fixes. claim
Ok this is even more subtle than I first thought. There's just far too much ambiguity here for this diagnostic code to produce a sensible suggestion. Any time a sub-expression/local pattern/argument pattern/closure's type contains the inference target it immediately becomes a candidate for suggesting on. In this case though, the inference target is , so any code that has anything to do with strings will trip the diagnostic...
Compiling the above results in this - clearly the has nothing to do with the error...
I have a similar message to: But what I don't understand is: why does it complain it can't infer the type if it clearly knows the type?
Change:
// `where`, so stop if it's it. // We also continue if we find types (not traits), again for error recovery. while self.can_begin_bound() <del> || self.token.can_begin_type() || (self.token.is_reserved_ident() && !self.token.is_keyword(kw::Where)) </del> <ins> || (self.may_recover() && (self.token.can_begin_type() || (self.token.is_reserved_ident() && !self.token.is_keyword(kw::Where)))) </ins> { if self.token.is_keyword(kw::Dyn) { // Account for `&dyn Trait + dyn Other`.

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:
#![feature(nll)] #![feature(nonnull_slice_from_raw_parts)] #![feature(once_cell)] <del> #![feature(auto_traits)] </del> #![feature(panic_info_message)] #![feature(panic_internals)] #![feature(panic_unwind)]

Discussion:
See for an example of the problem. Here we panic without any landing pads available upstack, because we are already the top-most(-ish) frame in the first place. This is UB.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Playground link with full code:
FWIW, Miri does detect this. :)
Change:
``` Rust files always end in a `.rs` extension. If you're using more than one word <del> in your file name, use an underscore. `hello_world.rs` rather than </del> <ins> in your filename, use an underscore. `hello_world.rs` rather than </ins> `helloworld.rs`. Now that you've got your file open, type this in:

Discussion:
There are a number of small typos in the guide, and some of the prose could be tightened up or clarified. In general the tone of the guide comes across as trying too hard to be chatty. Keeping things casual is probably a good idea for Rust's introductory document, but we can probably remove most (all?) of the chatty prose without becoming stodgy or boring.
The guide is inconsistent with its use of certain conventions. These don't really have a correct form, but a single style should be enforced. Single-quotes () versus double-quotes () in prose. Example: Periods and commas within quotes versus without. Example: "different from" versus "different than". Example: "filename" versus "file name"
If you find any obvious errors, or think you can write a section in a better way, please don't hesitate to submit a PR with a fix. You don't need to compile a compiler or download the source to edit the guide. You can do it all in github's ui, for the most part.
thanks for being specific. And for your earlier pull request. As for these... They should be double quotes. Ideally, they'd even be actual curlies rather than . Periods and commas go within in almost all cases. In both of the cases you show, they should go inside. "Different from" vs. "Different than" isn't something that's generally settled. Some styles choose it in different situations, others say "from" is the only correct way to say this. "file name" is my preferred way, though there's no specific actual guidance.
Change:
<ins> // Copyright 2014 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. #![crate_type = "lib"] pub struct TestUnion { val: u64 } #[link(name = "test", kind = "static")] extern { pub fn give_back(tu: TestUnion) -> u64; } </ins>

Discussion:
Spidermonkey's type is a union of size 64 bits. We represent this as in Rust. This works great on 64bit platforms. On 32bit platforms, the values get mangled when passed to the C library functions. This seems to be an ABI issue. We've encountered this before with which was about 32bit ARM. This gist contains sample programs and the generated IR for minimal test programs using rust-mozjs: Note that you will need my 32bit branch of rust-mozjs: You can put debugging printfs in in to see the value on the C side. The only notable thing I see in the IR is that the clang IR has when passing the . This seems like a Rust bug, but I'd also be interested if there is a workaround that will work on all platforms.
cc
cc me
Change:
#[allow(missing_copy_implementations)] pub enum OperandBundleDef_opaque {} pub type OperandBundleDefRef = *mut OperandBundleDef_opaque; <ins> #[allow(missing_copy_implementations)] pub enum Linker_opaque {} pub type LinkerRef = *mut Linker_opaque; </ins> pub type DiagnosticHandler = unsafe extern "C" fn(DiagnosticInfoRef, *mut c_void); pub type InlineAsmDiagHandler = unsafe extern "C" fn(SMDiagnosticRef, *const c_void, c_uint);

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:
// tidy-alphabetical-start #![allow(rustc::diagnostic_outside_of_impl)] #![allow(rustc::untranslatable_diagnostic)] <ins> #![feature(array_windows)] </ins> #![feature(box_patterns)] #![feature(control_flow_enum)] #![feature(if_let_guard)]

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'forcing query with already existing '', 'thread 'rustc' panicked at 'forcing query with already existing '' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [findfield] find the index of maybe nested field in [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to :thinking:
WG-prioritization assigning priority (). cc: + for label -I-prioritize +P-medium
I'm going to fix it in (still WIP), where the query will be removed.
Testing out on this issue:
I seems like does not have proper or impls, possibly due to the differing . Are you familiar with that part of spans?