jiebi/CodeConvo huggingface dataset:
Change:
<del> // NO-RUSTC-WRAPPER #![deny(warnings, rust_2018_idioms, unused_lifetimes)] </del> use std::fs::File; use std::path::{Path, PathBuf}; use std::process::{Command, Stdio};

Discussion:
When using 1.38 beta to bootstrap itself, I get:
This is expected and not a supported bootstrapping configuration; if you want to not see these errors you'll want to either bootstrap with N-1 compiler (so, in this case, 1.37) or I believe remove from bootstrap and some other libraries, as well as set deny-warnings in to false. Note that only the 1.37 bootstrap method is officially supported as "guaranteed to work", the deny warnings fix is more of a hack. Closing as won't fix.
Huh? In the past this was always fixed as it's a very common practice for distribution packaging (I don't know of a single packager not doing that). See e.g. or (in which you sort of acknowledged that yourself) deny-warnings is already set to false in , so I guess it somehow doesn't apply to building bootstrap itself.
I hope is an acceptable compromise wrt this. Thanks for pointing out the deny-warnings option which I forgot (since it has been set to false forever for us and never had any effect on the build of bootstrap itself)
Yeah is great; in this case the unsafe block is needed for 1.37 but not on 1.38; if there was an easy way to support both use cases then I'd be happy to accept a PR targeting beta but I'm not personally aware of one -- it looks like we don't seem to have an or similar? We try to support distros and such where possible in this configuration, it's just that this specific case I'm not sure how much we can do. deny-warnings=false is always my recommendation when using a different bootstrap compiler, or manual patches to the code.
Change:
| = note: required for `Option<Bar>` to implement `Copy` = note: the `Copy` trait is required because this value will be copied for each element of the array <del> = help: consider creating a new `const` item and initializing it with the result of the function call to be used in the repeat position, like `const VAL: Type = const_fn();` and `let x = [VAL; 42];` </del> = help: create an inline `const` block, see RFC #2920 <https://github.com/rust-lang/rfcs/pull/2920> for more information help: consider annotating `Bar` with `#[derive(Copy)]` | LL + #[derive(Copy)] LL | struct Bar; | <ins> help: consider creating a new `const` item and initializing it with the result of the function call to be used in the repeat position | LL ~     const ARRAY_REPEAT_VALUE: Option<Bar> = no_copy(); LL ~     let _: [Option<Bar>; 2] = [ARRAY_REPEAT_VALUE; 2]; | </ins> error: aborting due to previous error

Discussion:
I'm basing this suggestion on two things. One, that if you follow it, the code compiles: and two, that the diagnostic help you get when you try to use a in the repeat position suggests something very similar, see "other cases." It would require the compiler to know that a value that is attempted to be repeated is able though, which I don't know whether it can, but I figured I'd suggest this, and you can reject it if it isn't possible to do. Alternatively, the help text could say something like "if the value can be made , consider creating [...]" I was inspired to make this issue based on the output you get when you try to use a as an array initializer. For instance, the code produces the output No response
hey why im getting this error message all over my github repository ! whenever i commit some changes, The first changes i able to create pull request but after some other changes im not able to do that why im getting these error ! Please help
I don't think your comment is related to this issue? If this is a problem you've encountered while trying to fix this issue, please reach out on instead.
Change:
pub use self::adapters::StepBy; #[stable(feature = "iterator_flatten", since = "1.29.0")] pub use self::adapters::Flatten; <del> #[unstable(feature = "iter_copied", issue = "57127")] </del> <ins> #[stable(feature = "iter_copied", since = "1.36.0")] </ins> pub use self::adapters::Copied; pub(crate) use self::adapters::TrustedRandomAccess;

Discussion:
This is a tracking issue for Iterator::copied. Added in . Feature gate: . Related feature: in .
do you feel your comment in is still an objection to the state of this feature, given the response in
So ultimately, was closed meaning that we are comfortable with the specialization. If that specialization is always in place then is a redundant type (and the impls that come with it are also redundant). However, keeping the cost and the type also has less of a risk attached to it so there's a trade-off here. I don't know what the right choice is, but those are the facts as I see them.
Fixed :).
For reference, pattern is quite common according to (%5Cs%5C%7C%5Cs(%3F%3A%26%5Cs%5Cw%2B%5Cs%5C%7C%5Cs%5C%7B%3F%5Cs%5Cw%2B%7C%5Cw%2B%5Cs%5C%7C%5Cs%5C%7B%3F%5Cs%5C%5Cs%5Cw%2B)%5Cs%5C%7D%3F%5Cs*%5C)&insensitive=off&space=off&precise=off&sources=on This includes both Iterators and Options, because a regex match cannot separate those.
Is there anything blocking stabilization here? We'd like to suggest this in Clippy, see (The crux is that is clearer than , but gives off the wrong impression)
That's not my call... =D Picking random libs member... is there anything blocking stabilization here?
Doesn't seem like it. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the .

:bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Change:
<ins> fn server() -> impl { //~^ ERROR at least one trait must be specified ().map2(|| "") } trait FilterBase2 { fn map2<F>(self, F) -> Map2<F> {} //~^ ERROR mismatched types //~^^ ERROR the size for values of type `Self` cannot be known at compilation time } struct Map2<Segment2> { _func: F, //~^ ERROR cannot find type `F` in this scope } impl<F> FilterBase2 for F {} 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. --<!-- 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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
does this still panic after ? That only merged a couple days ago so you'll need to update your version of nightly.
Hmm I checked and it does, and it also panics before. So probably unrelated? cc just in case
Note that this works fine on .
Sorry, I accidentally closed the issue. Yes, you are right. It still crashes on the latest nightly version. I have a cron job to update my rust version everyday.
I think we ended up (incorrectly) removing a check in We shouldn't be calling upvarsty if is . This is a separate issue than that was fixed in
claim
Change:
- [Macro attributes may follow `#[derive]` and will see the original (pre-`cfg`) input.][87220] - [Accept curly-brace macros in expressions, like `m!{ .. }.method()` and `m!{ .. }?`.][88690] - [Allow panicking in constant evaluation.][89508] <ins> - [Ignore derived `Clone` and `Debug` implementations during dead code analysis.][85200] </ins> Compiler --------

Discussion:
landed in 1.57, causing derived and implementations to be ignored during dead code analysis. The for 1.57 don't mention this change anywhere. There's discussion in the original PR about including it in the release notes, but looks like nobody got around to it. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this is also worth a mention in the compatibility notes for 1.57, given that it can break builds where is set.
label +D-incorrect +D-invalid-suggestion
label -D-incorrect -D-invalid-suggestion
My bad there, had two different issues open.
I'd be happy to approve a PR adding a line to the release notes about this.
claim
Change:
} } ``` <ins> Instead of defining an inherent implementation on a reference, you could also move the reference inside the implementation: ```compile_fail,E0118 struct Foo; impl &Foo { // error: no nominal type found for inherent implementation fn bar(self, other: Self) {} } ``` becomes ``` struct Foo; impl Foo { fn bar(&self, other: &Self) {} } ``` </ins>

Discussion:
] To : This should probably use the covered/local terminology from instead of "base type" to avoid the problematic overlap with subtyping/inheritance terminology.
] ] ] (Not really [C-bug], but it was the closest of the template options.)
Just fyi, you can do modify labels to -C-bug +A-diagnostics +C-enhancement +D-newcomer-roadblock which will let you apply most labels yourself. .
Error: Label D-newcomer-roadblock can only be set by Rust team members Please let know if you're having trouble with this bot.
... Oh, unless that happens.
A second attempt :stuckouttongue: modify labels to -C-bug +A-diagnostics +C-enhancement
In the reference, we use the term "nominal type". The error code explanation should also mention unions and trait objects ( is valid). If the person use or , it should also hint at removing the reference and putting them on in the associated items. Not sure if I should open a new issue for that one or not though.
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. pub trait Foo for Sized? { fn foo<T>(&self, ext_thing: &T); } pub trait Bar for Sized?: Foo { } impl<T: Foo> Bar for T { } pub struct Thing; impl Foo for Thing { fn foo<T>(&self, _: &T) {} } #[inline(never)] fn foo(b: &Bar) { b.foo(&0u) } fn main() { let mut thing = Thing; let test: &Bar = &mut thing; //~ ERROR cannot convert to a trait object because trait `Foo` foo(test); } </ins>

Discussion:
The following code either aborts or segfaults for me, depending on if I'm in gdb or not, on Linux: With optimizations, becomes Which means we're doing something very bad when translating this code.
Still reducing...
FWIW, I can confirm that behaviour on Windows.
cc me
Reduced: And that makes it clear the issue is not broken codegen, but rather that is mistakenly treated as object-safe (while it inherits from the non-object-safe ).
nice. cc
P-backcompat-lang, 1.0.
Hint: iterate with
takes/creates s but needs a . I'm not sure how to make these agree.
checkobjectsafety should use to enumerate the trait_ref, I think. Annoyingly this does require a right now (harder to fix than you might think).
On I get , which is an unwrap in in the supertraits iterator.
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. // compile-pass #![feature(nll)] pub fn main() { let y: &'static mut [u8; 0] = &mut []; } </ins>

Discussion:
Error: This only happens after cc The code that triggered this is .
cc seems like we need to report an error instead of panicking as originally written
Oh it's probably because we do promote
created a fix in , but I have no minimal repro and no time today
To clarify: you're making this an error? I don't see why we can't allow to be promoted.
good point
This ICE is currently causing errors in the , and crates in
I have tried building and it does not reproduce the issue for me on master or nightly :confused: trying a stage2 build now still can't repro on regex, but can repro on OPs file now.
ok, fix exists now
It looks like we've fixed the ICE here but there's still a change in behavior here, as well as a faulty diagnostic; this is while compiling cargo-registry from (at least the version in rustc-perf).
Change:
} pub fn iter_impls_of_trait(&self, trait_def_id: DefId, f: |@Impl|) { <ins> self.iter_impls_of_trait_local(trait_def_id, |x| f(x)); if trait_def_id.crate == LOCAL_CRATE { return; } let crate_store = self.crate_context.tcx.sess.cstore; csearch::each_implementation_for_trait(crate_store, trait_def_id, |impl_def_id| { let implementation = @csearch::get_impl(self.crate_context.tcx, impl_def_id); let _ = lookup_item_type(self.crate_context.tcx, implementation.did); f(implementation); }); } pub fn iter_impls_of_trait_local(&self, trait_def_id: DefId, f: |@Impl|) { </ins> let trait_impls = self.crate_context.tcx.trait_impls.borrow(); match trait_impls.get().find(&trait_def_id) { Some(impls) => {

Discussion:
Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.
Change:
<del> Subproject commit d274fcf862b89264fa2c6b917b15230705257317 </del> <ins> Subproject commit a3c2627fbc2f5391c65ba45ab53b81bf71fa323c </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. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .
Change:
<ins> // check-pass // Regression test for #112832. pub trait QueryDb { type Db; } pub struct QueryTable<Q, DB> { db: DB, storage: Q, } // We normalize `<Q as QueryDb>::Db` to `<Q as AsyncQueryFunction<'d>>::SendDb` // using the where-bound. 'd is an unconstrained region variable which previously // triggered an assert. impl<Q> QueryTable<Q, <Q as QueryDb>::Db> where Q: for<'d> AsyncQueryFunction<'d> {} pub trait AsyncQueryFunction<'d>: QueryDb<Db = <Self as AsyncQueryFunction<'d>>::SendDb> { type SendDb: 'd; } pub trait QueryStorageOpsAsync<Q> where Q: for<'d> AsyncQueryFunction<'d>, { } fn main() {} </ins>

Discussion:
I tried this code: (minimized) I expected to see this happen: It should compile as it does on rust 1.69 and earlier (or at least not ICE). Instead, this happened: The program fails to compile with an ICE (see backtrace). <!-- 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. --: cc gluon issue that reported this (the error is coming from , a fork of ) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
searched nightlies: from nightly-2023-01-01 to nightly-2023-06-19 regressed nightly: nightly-2023-03-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
probably or
has a try build and it does reproduce the issue.
The issue still persists on rust 1.72. I have tried to compile example that was provided by author of issue: <details<summaryError log</summary</detailsI have tried to fix compilation issue in gluon_salsa by explicitly specifying lifetimes, but I have ran into ICE.
<a href=""<img src="" /</aI enjoy using gluon and would really like for this to be solved to enable using it with the current compiler. Hopefully this helps
Change:
use build_helper::util::fail; use filetime::FileTime; use once_cell::sync::OnceCell; <ins> use sha2::digest::Digest; </ins> use termcolor::{ColorChoice, StandardStream, WriteColor}; use utils::channel::GitInfo;

Discussion:
I tried this code: I expected to see this happen: bootstrap rebuilds LLVM, since it's changed. Instead, this happened: bootstrap does nothing. The problem is that we 're using a stamp file and assume that if the commit hasn't changed then none of the files have changed either: I am not sure why we do that? Are we assuming that CMake rebuilds too frequently? That seems like something we should fix upstream ... cc I think this would make your lives easier. HEAD is branched from .
hmm, looks related. I am not sure why that would be the correct behavior? If CFLAGS has changed we should rebuild; I would expect distros to make sure CFLAGS matches between invocations of bootstrap.
The stamp checking for the "normal" case, when not building from a source tarball, has been there since the initial commit of bootstrap:
Are you trying to address the git "dirty" case, or the non-git case, or both?
Both, but primarily the git case since that's how most people are developing I think.
Ok, I agree the git case is where folks may actually be making changes, and I still think it's ok not to automatically "notice" changes in the non-git case. LLVM is big enough that checking for dirty git may not be cheap though. On my Linux system with NVME, it takes ~0.5s after dropping page caches, and ~0.15s cached. On systems with slower disks, virus scanners, etc., it may be a lot worse.
Yeah, I don't think this is particularly important. The main issue with making changes to LLVM is , which prevents the change from being picked up even if you do commit it.
Change:
// Since the destructor is insignificant, we just want to make sure all of // the passed in type parameters are also insignificant. // Eg: Vec<T> dtor is insignificant when T=i32 but significant when T=Mutex. <del> with_query_cache(tcx, substs.types(), only_significant) </del> <ins> Ok(substs.types().collect()) </ins> } } } else if adt_def.is_union() { debug!("drop_tys_helper: `{:?}` is a union", adt_def); Ok(Vec::new()) } else { <del> with_query_cache( tcx, adt_def.all_fields().map(|field| { let r = tcx.type_of(field.did).subst(tcx, substs); debug!( "drop_tys_helper: Subst into {:?} with {:?} gettng {:?}", field, substs, r ); r }), only_significant, ) </del> <ins> let field_tys = adt_def.all_fields().map(|field| { let r = tcx.type_of(field.did).subst(tcx, substs); debug!("drop_tys_helper: Subst into {:?} with {:?} gettng {:?}", field, substs, r); r }); if only_significant { // We can't recurse through the query system here because we might induce a cycle Ok(field_tys.collect()) } else { // We can use the query system if we consider all drops significant. In that case, // ADTs are `needs_drop` exactly if they `impl Drop` or if any of their "transitive" // fields do. There can be no cycles here, because ADTs cannot contain themselves as // fields. with_query_cache(tcx, field_tys) } </ins> } .map(|v| v.into_iter()) };

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Error <codeerror[E0391] cycle detected when computing when has a significant destructor</codeoccurs when warn/deny lint on rust beta and nightly with a certain code snippet. On rust stable, it compiles without any issues. Looks like an issue of rustc (). I tried this code: It compiles successfully on stable or with : But with this lint warned (or denied) it does not compile on rust beta and on rust nightly with error: : <!-- Provide the version you are using that has the regression. --: <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bisects to , CC Although this is a regression from stable to beta, there's not enough time for it to get fixed before release.
Oops. Yeah, i read the error message and immediately knew what was going on. I can hopefully get a patch up for this tomorrow. claim
label regression-from-stable-to-stable, -regression-from-stable-to-beta
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
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 $$< $$@

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:
pub only_modified: bool, pub target_cfg: LazyCell<TargetCfg>, <ins> pub nocapture: bool, </ins> } impl Config {

Discussion:
passes fails On recent master (commit ), with to avoid building LLVM: Extra spin/Side note: Contrary to the above, with , both and pass well: and . All the same when invoking with instead of . Also discussed at https://rust- <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think is not actually passing through to libtest, it's just acting as a filter on the tests (like would). looks like today the only way to configure this is through an env variable: changing that to accept seems useful
claim
Wow. Thank you.