jiebi/CodeConvo huggingface dataset:
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.
Working on it!
something odd happened with the notification here... the PR is by but the bot pinged .
I sent the PR from a repository under fusion-engineering-forks. Looks like it uses the owner of the repo the PR came from, instead of the user that opened the PR.
Reopening until the submodule is bumped.

Discussion:
<del> Subproject commit 266b75faecd11e6a0b63fb6526fac56cda22bebc </del> <ins> Subproject commit 3fafb835ea42e6e3af27f5dc8f26bda590cb49e9 </ins>
Change:
~ OK on 1.46: | fails on 1.47: In all cases, we are using gdb 9.2 and LLVM 10. The tests themselves haven't changed since ~1.38, so it must be an actual behavioural change in rustc. <details<summaryui/backtrace-</summary~ </details<details</summary~ </details<details<summaryui/std-</summary~ </details
could this be related to ?
Seems likely! If this is happening on big-endian platforms then there's likely an issue with endianness in (most likely) . It could also be in itself or , but it seems most likely to be in the integration in the crate itself.
Related:
Assigning and removing as in the prioritization working group.
I'll try to run gimli etc things on a sparc, but no promises of success.
I have an s390x machine at hand, so I tried a few things. Plain passes for , , and , but fails two tests: There are also warnings about FFI safety, but I don't know if they're relevant.
It may be easier to reproduce on a mac:
Mac may have a very different issue, since it's apparently a big-endian thing here. (Plus I don't have a mac at all. :wink: )
Well, this will do it: I think this should this be , unless there's support for backtracing other processes.
Side note: does this need to be updated?

Discussion:
[[package]] name = "backtrace" <del> version = "0.3.50" </del> <ins> version = "0.3.52" </ins> dependencies = [ "addr2line", "cfg-if",

<del> Subproject commit 4083a90168d605b682ba166a0c01f86b3384e474 </del> <ins> Subproject commit 8eee2e473e71e659cbd5d32ee78aaf42e8b75752 </ins>
Change:
MIR may contain debuginfo like this after inlining: Here, the field access is treated like a use of the local in MIR visitors (using ), even though it is not an actual use of . Instead, it should be using .
Can you describe where the change needs to be made? The visit method for debuginfo seems to be correct: It shells out to with , and then shells out through some other methods to . isn't getting the PlaceContext that was called with (I guess because the context of a projection is potentially different than that of the local it's projecting), but it seems to do nothing for field accesses: So what part should I change? Thanks!
Looks like the problem is here:
Okay, thank you!

Discussion:
let mut context = context; if !place.projection.is_empty() { <del> context = if context.is_mutating_use() { PlaceContext::MutatingUse(MutatingUseContext::Projection) } else { PlaceContext::NonMutatingUse(NonMutatingUseContext::Projection) }; </del> <ins> if context.is_use() { // ^ Only change the context if it is a real use, not a "use" in debuginfo. context = if context.is_mutating_use() { PlaceContext::MutatingUse(MutatingUseContext::Projection) } else { PlaceContext::NonMutatingUse(NonMutatingUseContext::Projection) }; } </ins> } self.visit_local(&place.local, context, location);

use rustc_middle::mir::visit::{PlaceContext, Visitor}; use rustc_middle::mir::{ AggregateKind, BasicBlock, Body, BorrowKind, Local, Location, MirPhase, Operand, PlaceRef, <del> Rvalue, SourceScope, Statement, StatementKind, Terminator, TerminatorKind, VarDebugInfo, </del> <ins> Rvalue, SourceScope, Statement, StatementKind, Terminator, TerminatorKind, </ins> }; use rustc_middle::ty::fold::BottomUpFolder; use rustc_middle::ty::{self, ParamEnv, Ty, TyCtxt, TypeFoldable};

} } <del> fn visit_var_debug_info(&mut self, var_debug_info: &VarDebugInfo<'tcx>) { // Debuginfo can contain field projections, which count as a use of the base local. Skip // debuginfo so that we avoid the storage liveness assertion in that case. self.visit_source_info(&var_debug_info.source_info); } </del> fn visit_operand(&mut self, operand: &Operand<'tcx>, location: Location) { // This check is somewhat expensive, so only run it when -Zvalidate-mir is passed. if self.tcx.sess.opts.debugging_opts.validate_mir {
Change:
<!-- 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. --This does not happen if the macro is private or . <!-- 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
The ice also occurs with .
This is now compiled fine with the latest nightly, I think fixed it. Marking as .
Still ICEs for me on playground
Note that its nightly isn't the latest (see for example).
Latest nightly compiles it fine
This should be open until the test is .

Discussion:
<ins> // check-pass // Regression test of #77475, this used to be ICE. #![feature(decl_macro)] use crate as _; pub macro ice(){} fn main() {} </ins>
Change:
UI tests regularly have long lines due to the annotations. So it is not very helpful for tidy to complain about overly long lines... every single time that happened, I ended up adding (the amount of time it took me to figure out the exact way to do this went down from 3-5min the first time to <20s by now). To make test maintenance even more annoying, when an error message changes to become shorter, tidy will complain about the ignore flag being unnecessary! And each time the flag is or removed, you need to re-bless the tests as line numbers change. This chore doesn't really seem worth it. We don't the test suite either. Can we just disable the line length checker in the test suite please? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We can add a check similar to to disable just the line length limits for UI tests.
Hey, first time contributor here happy to give this a shot! I think I get what's going on here, but do you have any pointers for where I should be looking exactly?
I would add a "intests" check similar to the the underrustfmt one here , and then add it to the conditional here to not run that lint in tests.
Is the plan suggested in still good?
yeah I'd say it is. actually did most of the work (adjusting tidy); someone just has to do the multi-stage landing process: in a first PR, land the tidy change with disabled "ignoring length unnecessarily" (and probably adjust no existing tests, to keep conflicts down) then in a second PR, remove the unnecessary ignore-line-length comments (probably still keeping "ignoring length unnecessarily" disabled as more tests will trickle in that still have the ignore-line-length flag) after 2 weeks or so, re-enable the "ignoring length unnecessarily" test Step 3 is assuming that we truly want to keep that check. I personally think it is somewhat silly, but I assume it was because people want it, so maybe we should keep it.
claim
thank you so much for pushing this through. :-)
Thanks to your quick advice and great preparatory work this was in fact pretty easy. I'm very impressed by the tooling and automation surrounding the contribution process! :muscle:

Discussion:
if let Directive::Ignore(false) = skip_tab { tidy_error!(bad, "{}: ignoring tab characters unnecessarily", file.display()); } <del> // FIXME: Temporarily disabled to simplify landing the ignore-rules for the line // length check (https://github.com/rust-lang/rust/issues/77548): //if let Directive::Ignore(false) = skip_line_length { //    tidy_error!(bad, "{}: ignoring line length unnecessarily", file.display()); //} </del> <ins> if let Directive::Ignore(false) = skip_line_length { tidy_error!(bad, "{}: ignoring line length unnecessarily", file.display()); } </ins> if let Directive::Ignore(false) = skip_file_length { tidy_error!(bad, "{}: ignoring file length unnecessarily", file.display()); }
Change:
New contributors haven't use before, so there's no reason for them to read the changelog: nothing has changed.
I can tackle this.
that would be great! To get started, take a look at . In addition to adding , also add . You'll have to move from to so you can access it in . You should also double check that the changelog warning isn't printed during the command itself. I'm not sure exactly how to do that without reading the code, but I expect it to be a simple or something like that.

Discussion:
use std::env; <del> use bootstrap::{Build, Config, Subcommand}; </del> <ins> use bootstrap::{Build, Config, Subcommand, VERSION}; </ins> fn main() { let args = env::args().skip(1).collect::<Vec<_>>(); let config = Config::parse(&args); <del> let changelog_suggestion = check_version(&config); </del> <ins> // check_version warnings are not printed during setup let changelog_suggestion = if matches!(config.cmd, Subcommand::Setup {..}) { None } else { check_version(&config) }; </ins> // NOTE: Since `./configure` generates a `config.toml`, distro maintainers will see the // changelog warning, not the `x.py setup` message.

} fn check_version(config: &Config) -> Option<String> { <del> const VERSION: usize = 2; </del> let mut msg = String::new(); let suggestion = if let Some(seen) = config.changelog_seen {

"llvm-ar", // used for creating and modifying archive files ]; <ins> pub const VERSION: usize = 2; </ins> /// A structure representing a Rust compiler. /// /// Each compiler has a `stage` that it is associated with and a `host` that

<del> use crate::t; </del> <ins> use crate::{t, VERSION}; </ins> use std::path::{Path, PathBuf}; use std::str::FromStr; use std::{

let path = cfg_file.unwrap_or_else(|| src_path.join("config.toml")); let settings = format!( "# Includes one of the default files in src/bootstrap/defaultsn <del> profile = "{}"n", profile </del> <ins> profile = "{}"n changelog-seen = {}n", profile, VERSION </ins> ); t!(fs::write(path, settings));
Change:
<!-- 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: assembly generated should be equivalent to: Instead, this happened: the generated assembly retains calls to Ipv4::octets and Ipv4::from, leaving the assembly poorly optimized I've played with different ways of implementing the safe version, but cannot find anyway get it to optimize further. Good assembly: Bad assembly: and (both include an IPv6 example as well) Adding '-Z mir-opt-level=2' (or higher) does optimize away the call to octets, but not the call to from. I get the same optimization behavior when building a binary, at least on my own platfom (x86-64 Windows MSVC) <!-- 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. --:
Maybe it's just missing s?
I will try to test with adding in the appropriate places in std
This is a trivial method on a concrete type, so yeah, probably just needs . Or you want to turn on LTO. (If it were generic it wouldn't be necessary, but for concrete things the bodies aren't in the meta.)
So I found when a crate exports a function with , it does get optimized where called (though I'm . On the other hand, the same logic inside function will not be inlined: this basic program, for instance, retains assembly calls to octets() and from(): Edit: copy the right "basic program" this time... With on the methods in libstd, the two calls are optimized away. Is this worth a PR to add to libstd? If so, is there anything that shouldn't have in the API? Seems to me like nearly everything would be better inlined, at least for IPv4, but I'm far from an expert.
Feel free to open a PR I guess, your reviewer will decide whether it should be merged or not.
Ping do you want to work on fixing this issue?

Discussion:
} impl IntoInner<c::in_addr> for Ipv4Addr { <ins> #[inline] </ins> fn into_inner(self) -> c::in_addr { self.inner }

} impl AsInner<c::in6_addr> for Ipv6Addr { <ins> #[inline] </ins> fn as_inner(&self) -> &c::in6_addr { &self.inner } } impl FromInner<c::in6_addr> for Ipv6Addr { <ins> #[inline] </ins> fn from_inner(addr: c::in6_addr) -> Ipv6Addr { Ipv6Addr { inner: addr } }
Change:
should always return . But it doesn't if you enable the lvi-cfi feature. The miscompilation only happens with opt-level=0. Compare: Here's a slightly reduced LLVM IR: Difference in output when adjusting the lvi-cfi feature attribute on : . I can't really see any obvious culprits. I want to file an LLVM bug as well but I don't have an account. cc
I think the Rust calling convention may be using whereas LVI-CFI assumes it's unused?
Actually you can see the issue in the assembly diff I posted, lines 45-51.
I've filed an LLVM bug now based on this reduced example:

Discussion:
<del> Subproject commit e8b556b6a8836147429abe391d6ed18806867b45 </del> <ins> Subproject commit 3adf16e0cb1a0d9d7216883ac47857a6d1ee6581 </ins>
Change:
<!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details
Related:
do you know what's going on here? The rustdoc code is
Yeah, that one's somewhat expected. adds predicates to , so we now have to deal with them in rustdoc, can fix this myself next week
I minimized the failure I'm seeing in rustdoc and it looks like it's this issue and not a separate one. Is there any workaround or is any expected to see this breakage w/rustdoc?
No, there's no workaround that I know of. I don't understand the implementation of const generics very well, nor does anyone else on the team.
Does anyone know what would be needed to fix this, or at least work around it enough to stop from crashing? (This is currently disabling for our project, which relies on some code.)

Discussion:
ty::PredicateKind::RegionOutlives(pred) => pred.clean(cx), ty::PredicateKind::TypeOutlives(pred) => pred.clean(cx), ty::PredicateKind::Projection(pred) => Some(pred.clean(cx)), <ins> ty::PredicateKind::ConstEvaluatable(..) => None, </ins> ty::PredicateKind::Subtype(..) | ty::PredicateKind::WellFormed(..) | ty::PredicateKind::ObjectSafe(..) | ty::PredicateKind::ClosureKind(..) <del> | ty::PredicateKind::ConstEvaluatable(..) </del> | ty::PredicateKind::ConstEquate(..) | ty::PredicateKind::TypeWellFormedFromEnv(..) => panic!("not user writable"), }

<ins> #![crate_name = "foo"] #![feature(const_evaluatable_checked, const_generics)] #![allow(incomplete_features)] // make sure that `ConstEvaluatable` predicates dont cause rustdoc to ICE #77647 // @has foo/struct.Ice.html '//pre[@class="rust struct"]'  //      'pub struct Ice<const N: usize> where [(); N + 1]: ;' pub struct Ice<const N: usize> where [(); N + 1]:; </ins>
Change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Seems it regressed in , cc
This occurs in regex_syntax as well.
I think that this is a missing normalize call here:
?
Yeah, just checked and it fixes the issue, cc
has merged now

Discussion:
<ins> // revisions: default miropt //[miropt]compile-flags: -Z mir-opt-level=2 // ~^ This flag is for #77668, it used to be ICE. </ins> #![crate_type = "lib"] pub fn bar<P>( // Error won't happen if "bar" is not generic
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
cc I saw you also mentioned that PR in
It looks like I set up the imports incorrectly in - they don't work when is built as part of . I'm working on a PR to fix it.
Indeed this will require another backtrace-rs bump to be fixed. Thanks!
Opened
Now we also have a build failure: But we cannot fix that while libbacktrace is broken.
The build failure still needs to be fixed.

Discussion:
<del> Subproject commit 3fafb835ea42e6e3af27f5dc8f26bda590cb49e9 </del> <ins> Subproject commit 8beccc4bef598e95e31536f996ea5771d8126d00 </ins>
Change:
Compiling with I get since two nightlies:
Triage: It's now compiled fine with the latest nightly, I think it's fixed by .
It works now, thank you.
This should be open until the test is .

Discussion:
<ins> // edition:2018 // compile-flags: -Z mir-opt-level=2 -Z unsound-mir-opts #[inline(always)] pub fn f(s: bool) -> String { let a = "Hello world!".to_string(); let b = a; let c = b; if s { c } else { String::new() } } </ins>

<ins> // compile-flags: -Z mir-opt-level=2 // edition:2018 // build-pass #![feature(async_closure)] use std::future::Future; fn async_closure() -> impl Future<Output = u8> { (async move || -> u8 { 42 })() } fn main() { let _fut = async_closure(); } </ins>

<ins> // compile-flags: -Z mir-opt-level=2 // build-pass #![feature(type_alias_impl_trait)] use std::marker::PhantomData; trait MyIndex<T> { type O; fn my_index(self) -> Self::O; } trait MyFrom<T>: Sized { type Error; fn my_from(value: T) -> Result<Self, Self::Error>; } trait F {} impl F for () {} type DummyT<T> = impl F; fn _dummy_t<T>() -> DummyT<T> {} struct Phantom1<T>(PhantomData<T>); struct Phantom2<T>(PhantomData<T>); struct Scope<T>(Phantom2<DummyT<T>>); impl<T> Scope<T> { fn new() -> Self { unimplemented!() } } impl<T> MyFrom<Phantom2<T>> for Phantom1<T> { type Error = (); fn my_from(_: Phantom2<T>) -> Result<Self, Self::Error> { unimplemented!() } } impl<T: MyFrom<Phantom2<DummyT<U>>>, U> MyIndex<Phantom1<T>> for Scope<U> { type O = T; fn my_index(self) -> Self::O { MyFrom::my_from(self.0).ok().unwrap() } } fn main() { let _pos: Phantom1<DummyT<()>> = Scope::new().my_index(); } </ins>

<ins> // edition:2018 // build-pass // compile-flags: -Z mir-opt-level=2 -L. // aux-build:issue_76375_aux.rs #![crate_type = "lib"] extern crate issue_76375_aux; pub async fn g() { issue_76375_aux::f(true); h().await; } pub async fn h() {} </ins>

<ins> // compile-flags: -Z mir-opt-level=2 // ignore-cloudabi no std::fs // build-pass use std::fs::File; use std::io::{BufRead, BufReader}; fn file_lines() -> impl Iterator<Item = String> { BufReader::new(File::open("").unwrap()) .lines() .map(Result::unwrap) } fn main() { for _ in file_lines() {} } </ins>
Change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Reduced:
This doesn't ICE on 1.46. modify labels: +regression-from-stable-to-stable
We decided to label this as it's unlikely to be hit, it used to be an error in a previous release. Also, it's very esoteric code.
Line triggered the ICE: Regressed in , cc fyi Note that the snippet doesn't have to contain : <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Will look into this in a few weeks so I am claiming this for now so I don't forget. claim If anyone else wants to work on this before that feel free to do so, don't have much time rn
The solution might be as simple as merging the linked match arm with the previous error one, making this a delayspanbug and ignoring it.
I just saw this issue and thought the same thing. I'm testing the fix now.

Discussion:
tcx.sess.delay_span_bug(tcx.def_span(def_id), "anon const with Res::Err"); return None; } <del> _ => span_bug!( DUMMY_SP, "unexpected anon const res {:?} in path: {:?}", res, path, ), </del> <ins> _ => { // If the user tries to specify generics on a type that does not take them, // e.g. `usize<T>`, we may hit this branch, in which case we treat it as if // no arguments have been passed. An error should already have been emitted. tcx.sess.delay_span_bug( tcx.def_span(def_id), &format!("unexpected anon const res {:?} in path: {:?}", res, path), ); return None; } </ins> }; generics

<ins> fn foo() { let x: usize<foo>; //~ ERROR const arguments are not allowed for this type } fn main() {} </ins>

<ins> error[E0109]: const arguments are not allowed for this type --> $DIR/usize-generic-argument-parent.rs:2:18 | LL |     let x: usize<foo>; |                  ^^^ const argument not allowed error: aborting due to previous error For more information about this error, try `rustc --explain E0109`. </ins>