jiebi/CodeConvo huggingface dataset:
Change:
$$(eval $$(call DEF_PREPARE,dir-$(1))) dist-install-dir-$(1): PREPARE_HOST=$(1) <del> dist-install-dir-$(1): PREPARE_TARGETS=$(1) </del> <ins> dist-install-dir-$(1): PREPARE_TARGETS=$(2) </ins> dist-install-dir-$(1): PREPARE_DEST_DIR=tmp/dist/$$(PKG_NAME)-$(1) dist-install-dir-$(1): PREPARE_DIR_CMD=$(DEFAULT_PREPARE_DIR_CMD) dist-install-dir-$(1): PREPARE_BIN_CMD=$(DEFAULT_PREPARE_BIN_CMD)

Discussion:
Currently, Servo uses snapshots generated from . This works great for self-targeting builds, but there's no support today for generating cross-compilation snapshots. This feature is required to support Servo Android test machines on Travis CI. I see that handles cross-compilation: It would be great if there were a different (?), too, to support this scenario.
If I went ahead and created such a target, is that something you would be open to?
Sounds reasonable to me!
I've started the patch to do this. There is some existing cruft from somebody making a similar half-fix previously that needs to be deleted. Doing it right I will involve switching the default behavior to package all targets, leaving the current behavior as a special case for our bots, which means we need to update the bots. It looks pretty easy though and I hope to have it done tomorrow.
Thanks! That explains the confusion I had - I kept getting halfway through it and then getting very confused because it looked like it should be doing what I wanted already.
Change:
generics, body.as_deref(), ); <ins> walk_list!(self, visit_attribute, &item.attrs); </ins> self.visit_fn(kind, item.span, item.id); } AssocItemKind::Type(_) => {

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' File: --snippet: Version 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: [hircrate] getting the crate HIR [hirattrs] getting HIR owner attributes in `` [entry_fn] looking up the entry function of a crate [analysis] running analysis passes on this crate --
Crashes since cc
For the record: helped expose a latent bug in AST validation, which will fix.
Also (probably the same cause):
This code now causes unbound memory growth after when trying to print the query stack. after
Change:
} // Normalize lifetimes away on both sides, then compare. <ins> let param_env = param_env.with_reveal_all_normalized(tcx); </ins> let normalize = |ty: Ty<'tcx>| { tcx.normalize_erasing_regions( param_env,

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. --I think all of these happen since <!-- 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</detailsThe following samples also did not crash with -Zvalidate-mir with but do crash with  `
cc
Change:
//! * [`SocketAddr`] represents socket addresses of either IPv4 or IPv6; [`SocketAddrV4`] //!   and [`SocketAddrV6`] are respectively IPv4 and IPv6 socket addresses <del> #![unstable(feature = "ip_in_core", issue = "108443")] </del> <ins> #![stable(feature = "ip_in_core", since = "CURRENT_RUSTC_VERSION")] </ins> #[stable(feature = "rust1", since = "1.0.0")] pub use self::ip_addr::{IpAddr, Ipv4Addr, Ipv6Addr, Ipv6MulticastScope};

Discussion:
Feature gate: This is a tracking issue for RFC , providing networking types in : , , , , , , and . [x] Implementation: [x] Final comment period (FCP)[^1] [x] Stabilization PR: [^1]: https://std-dev-
I guess there's nothing left to do. Can this feature now move to the the FCP?
Can this be stabilized before  ( implements )?
I believe so. Nothing in ipaddr points or uses core::error::Error: (master) The only impl Error is in Parser and I guess it needs to be featured gated:
You can't feature gate a trait implementation. The question would be if it's possible to refer to any of the methods on the error types without having to activate the feature. I believe not, since you would have to in order to bring the methods into scope.
Thanks for the explanation and yes, I agree that it can't be stabilised before Error then.
I disagree, this feature can be specialized before . Nothing will change for users, and users will merely not be able to use the impl. This is just like all existing errors in , eg (which is arguably stable):
Ping could this go into FCP?
Yes, please.
nominate libs
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
maybe? Would like to get some confirmation that this is on some list somewhere for discussion.
I've the nomination label so it'll be discussed in a libs-api meeting, though it's possible a libs-api member may decide to remove the label and just fcp it. It'd likely be helpful if someone could provide a summary of the current state of things and why this is ready for stabilization.
I'm not claiming this bears enough weight to stabilize but I just allowed in a small library that used address types and it went completely smooth.
Starting FCP for stabilization. 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] [ ] 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. This will be merged soon.
I pushed a stabilization PR:
Change:
Some(ty) => { let fn_sig = tcx.typeck(def_id).liberated_fn_sigs()[hir_id]; // Typeck doesn't expect erased regions to be returned from `type_of`. <ins> // This is a heuristic approach. If the scope has region paramters, // we should change fn_sig's lifetime from `ReErased` to `ReError`, // otherwise to `ReStatic`. let has_region_params = generics.params.iter().any(|param| match param.kind { GenericParamKind::Lifetime { .. } => true, _ => false, }); </ins> let fn_sig = tcx.fold_regions(fn_sig, |r, _| match *r { <del> ty::ReErased => tcx.lifetimes.re_static, </del> <ins> ty::ReErased => { if has_region_params { ty::Region::new_error_with_message( tcx, DUMMY_SP, "erased region is not allowed here in return type", ) } else { tcx.lifetimes.re_static } } </ins> _ => r, });

Discussion:
The code Emits this diagnostic, which is wrong in this case. It should say cc: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Cannot reproduce: the code snippet as given produces on stable 1.78.0
Did you mean to write this code snippet instead?
Ooops yes :sweat_smile:, edited
claim
Change:
/// /// ### Example of drop reorder /// <del> /// ```rust,compile_fail </del> <ins> /// ```rust,edition2018,compile_fail </ins> /// #![deny(rust_2021_incompatible_closure_captures)] /// # #![allow(unused)] ///

Discussion:
Given the following code: The current output is: Ideally the output should look like: The code is already being compiled for the 2021 edition, there's no need to issue any warnings about behaviour that was different in 2018. The compiler should assume that the code is working as expected. This might affect other warnings in the same category, I'm not sure. Tested in 1.63, beta and nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
So, it seems that there are 3 warnings in this category and the issue only affects the closure one: is not affected because it checks that auto-ref happens, which doesn't in rust 2021 is not affected because the linted code simply doesn't compile in rust 2021 is affected
seems to be needed, because is marked with and the lint wants a significant impl MRE:
Change:
<ins> error[E0391]: cycle detected when const-evaluating `FOO` --> $DIR/recursive-zst-static.rs:7:18 | LL | static FOO: () = FOO; |                  ^^^ | note: ...which requires const-evaluating `FOO`... --> $DIR/recursive-zst-static.rs:7:1 | LL | static FOO: () = FOO; | ^^^^^^^^^^^^^^^^^^^^^ = note: ...which again requires const-evaluating `FOO`, completing the cycle note: cycle used when const-evaluating + checking `FOO` --> $DIR/recursive-zst-static.rs:7:1 | LL | static FOO: () = FOO; | ^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0391`. </ins>

Discussion:
I tried this code: I expected the code to fail to compile with a cycle error. Instead, it compiled and ran,printing the value of . I was able to verify that this bug happens for the 1.42.0 stable, 1.43-beta.5, and 1.44.0-nightly(2020-04-11 ) versions. Trying this code in it errors up to 1.36.0,and doesn't error anymore from 1.37.0 onwards.
cc
narrowed to the following: Auto merge of - petrochenkov:builtout, r=eddyb Auto merge of - luca-barbieri:optimize-refcell-borrow, r=RalfJung Auto merge of - Centril:rollup-, r=Centril Auto merge of - petrochenkov:rpass, r=Centril Possibly ?
Weaponized soundness hole (using as a foundation): ==
cc
oopsie yeah... is probably where this started. But that is crucial to fix The problem is that "reading from a ZST" isn't actually doing anything. Here's the MIR for : So there actually is a that loads from this static (I didn't expect that). But in Miri, a ZST load just checks that the address is in-bounds; no actual access to the underlying memory happens so there is no cycle error.
Assigning as and removing .
Change:
// between the same trait with different args. If we, for // some reason, were to relax the `Unsize` trait, it could become // unsound, so let's assert here that the trait refs are *equal*. <del> // // We can use `assert_eq` because the binders should have been anonymized, // and because higher-ranked equality now requires the binders are equal. debug_assert_eq!( data_a.principal(), data_b.principal(), </del> <ins> debug_assert!( validate_trivial_unsize(cx.tcx(), data_a, data_b), </ins> "NOP unsize vtable changed principal trait ref: {data_a} -> {data_b}" );

Discussion:
I believe this is caused by . Does that look like anything to you? This doesn't seem to happen with the dist artifacts, only the settings used when testing in CI. The config used in CI is: EDIT: Almost certainly since it comes from . This is causing the reference test suite to fail. Using which is currently unreleased.
Yeah, it's a debug assertion after all. I'll look into it and relax the assertion
Change:
} #[stable(feature = "rust1", since = "1.0.0")] <del> impl<W> error::Error for IntoInnerError<W> { </del> <ins> impl<W: Send + fmt::Debug> error::Error for IntoInnerError<W> { </ins> fn description(&self) -> &str { error::Error::description(self.error()) }

Discussion:
currently requires , while requires . I'm unsure of what each should require, but I think they should agree so that it is possible to have code which returns (which is useful to allow try! across functions returning different types of error codes), and be able to the results.
There was a lengthy discussion about this towards the bottom of the RFC:
/cc , I vaguely remember this might change? If not, then this should be in the RFCs repo.
Nominating for 1.0-beta P-backcompat-libs. (The trait isn't yet, but it probably will be for 1.0).
0 beta, P-backcompat-libs, I-needs-decision.
Change:
<del> Subproject commit cafbe7f2d9bdf9e94946e3f6f62b781b05b7d556 </del> <ins> Subproject commit d420589e1a8208c85368d07c1644c6725367650b </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. 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 the PR reviewer, and -- nominating for prioritization.
Change:
// https://llvm.org/docs/HowToCrossCompileLLVM.html if target != builder.config.build { <del> builder.ensure(Llvm { target: builder.config.build }); // FIXME: if the llvm root for the build triple is overridden then we //        should use llvm-tblgen from there, also should verify that it //        actually exists most of the time in normal installs of LLVM. let host_bin = builder.llvm_out(builder.config.build).join("bin"); cfg.define("LLVM_TABLEGEN", host_bin.join("llvm-tblgen").with_extension(EXE_EXTENSION)); // LLVM_NM is required for cross compiling using MSVC cfg.define("LLVM_NM", host_bin.join("llvm-nm").with_extension(EXE_EXTENSION)); cfg.define( "LLVM_CONFIG_PATH", host_bin.join("llvm-config").with_extension(EXE_EXTENSION), ); </del> <ins> let llvm_config = builder.ensure(Llvm { target: builder.config.build }); if !builder.config.dry_run { let llvm_bindir = output(Command::new(&llvm_config).arg("--bindir")); let host_bin = Path::new(llvm_bindir.trim()); cfg.define( "LLVM_TABLEGEN", host_bin.join("llvm-tblgen").with_extension(EXE_EXTENSION), ); // LLVM_NM is required for cross compiling using MSVC cfg.define("LLVM_NM", host_bin.join("llvm-nm").with_extension(EXE_EXTENSION)); } cfg.define("LLVM_CONFIG_PATH", llvm_config); </ins> if builder.config.llvm_clang { let build_bin = builder.llvm_out(builder.config.build).join("build").join("bin"); let clang_tblgen = build_bin.join("clang-tblgen").with_extension(EXE_EXTENSION);

Discussion:
In particular, this means you have to rebuild llvm for the host when cross-compiling. I tried this code: . I expected to see this happen: The compiler builds successfully. Instead, this happened: I think there's a secondary bug which is that x.py hard-codes instead of . But that seems easier to fix. <!-- 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<summaryBacktrace</summary<p</p</details
Mentoring instructions: where in it generates the component (I think I might be in ) llvm-tblgen to the binaries that are copied a PR and ask someone to run , which will generate CI artifacts. the merge commit from the build locally and confirm that works successfully (or if you're not on Linux, some other platform that's binary compatible).
label: +E-mentor
Make sure to only copy it if it exists. It doesn't get build if the llvm backend isn't enabled.
It looks like unconditionally copies llvm binaries right now, so I think should be no different.
Change:
// but there's already an item with the same namespace and same name. Rust gives // priority to the not-imported one, so we should, too. items.extend(doc.items.values().flat_map(|(item, renamed, import_id)| { <del> // First, lower everything other than imports. </del> <ins> // First, lower everything other than glob imports. </ins> if matches!(item.kind, hir::ItemKind::Use(_, hir::UseKind::Glob)) { return Vec::new(); }

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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage
Change:
) }); <ins> // Don't report overlap errors if the header references error if let Err(err) = (overlap.trait_ref, overlap.self_ty).error_reported() { return Err(err); } </ins> match used_to_be_allowed { None => { let reported = if overlap.with_impl.is_local()

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'downgradetodelayedbug: cannot downgrade Warning to DelayedBug: not an error'', 'thread 'rustc' panicked at 'downgradetodelayedbug: cannot downgrade Warning to DelayedBug: not an error'' File: --auto-reduced (treereduce-rust): original: Version 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: [specializationgraphof] building specialization graph of trait [coherent_trait] coherence checking all impls of trait [analysis] running analysis passes on this crate --
Regression in nightly-2023-03-22 commit[0] 2023-03-20: Auto merge of - euclio:windows-rs, r=ChrisDenton commit[1] 2023-03-20: Auto merge of - Zoxc:split-execute-job, r=cjgillot,michaelwoerister commit[2] 2023-03-21: Auto merge of - ChrisDenton:libntdll, r=Mark-Simulacrum commit[3] 2023-03-21: Auto merge of - TDecki:dec2flt-inline, r=thomcc commit[4] 2023-03-21: Auto merge of - saethlin:remove-vec-as-ptr-assume, r=thomcc commit[5] 2023-03-21: Auto merge of - Nilstrieb:rollup-seb5xsa, r=Nilstrieb commit[6] 2023-03-21: Auto merge of - ferrocene:pa-test-metrics, r=Mark-Simulacrum commit[7] 2023-03-21: Auto merge of - compiler-errors:local-key, r=cjgillot commit[8] 2023-03-21: Auto merge of - matthiaskrgr:rollup-odn02wu, r=matthiaskrgr ERROR: no CI builds available between and within last 167 days
oh nevermind, still crashes with next-solver-coherence :cryingcatface:
Change:
($dst:expr $(,)?) => { $crate::write!($dst, "n") }; <del> ($dst:expr, $($arg:tt)*) => { $dst.write_fmt($crate::format_args_nl!($($arg)*)) }; </del> <ins> ($dst:expr, $($arg:tt)*) => {{ let result = $dst.write_fmt($crate::format_args_nl!($($arg)*)); result }}; </ins> } /// Indicates unreachable code.

Discussion:
https://crater- https://crater- https://crater- https://crater- https://crater- https://crater- is likely cause (cc
I'll fix this.
Fixed on beta with and on master. will be a more complete change and will likely land in 1.63 (or later).
Change:
// ambiguous. if let Some(bad_ty) = &steps.opt_bad_ty { if is_suggestion.0 { <del> // Ambiguity was encountered during a suggestion. Just keep going. debug!("ProbeContext: encountered ambiguity in suggestion"); </del> <ins> // Ambiguity was encountered during a suggestion. There's really // not much use in suggesting methods in this case. return Err(MethodError::NoMatch(NoMatchData { static_candidates: Vec::new(), unsatisfied_predicates: Vec::new(), out_of_scope_traits: Vec::new(), similar_candidate: None, mode, })); </ins> } else if bad_ty.reached_raw_pointer && !self.tcx.features().arbitrary_self_types && !self.tcx.sess.at_least_rust_2018()

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</details
Maybe but probably easier to debug from scratch.
Change:
<ins> #![crate_type = "lib"] #![feature(transmutability)] mod assert { use std::mem::BikeshedIntrinsicFrom; struct Context; pub fn is_maybe_transmutable<Src, Dst>() where Dst: BikeshedIntrinsicFrom<Src, Context>, { } } fn main() { pub union Uninit { a: [u8; usize::MAX], } #[repr(C)] struct ExplicitlyPadded(Uninit); assert::is_maybe_transmutable::<(), ExplicitlyPadded>(); //~^ ERROR `()` cannot be safely transmuted into `ExplicitlyPadded` assert::is_maybe_transmutable::<ExplicitlyPadded, ()>(); //~^ ERROR `ExplicitlyPadded` cannot be safely transmuted into `()` } </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</details
Crashes since 1.65.0.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
Ok(InferOk { obligations, value: () }) => { self.register_predicates(obligations); } <del> Err(_) => { span_bug!( self.span, "{} was a subtype of {} but now is not?", self_ty, method_self_ty ); </del> <ins> Err(terr) => { // FIXME(arbitrary_self_types): We probably should limit the // situations where this can occur by adding additional restrictions // to the feature, like the self type can't reference method substs. if self.tcx.features().arbitrary_self_types { self.err_ctxt() .report_mismatched_types(&cause, method_self_ty, self_ty, terr) .emit(); } else { span_bug!( self.span, "{} was a subtype of {} but now is not?", self_ty, method_self_ty ); } </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</details
label +F-arbitraryselftypes
Change:
} missing_idxs => { let first_idx = *missing_idxs.first().unwrap(); <del> let second_idx = *missing_idxs.last().unwrap(); </del> <ins> let last_idx = *missing_idxs.last().unwrap(); </ins> // NOTE: Because we might be re-arranging arguments, might have extra arguments, etc. // It's hard to *really* know where we should provide this error label, so this is a // decent heuristic <del> let span = if first_idx < provided_arg_count { </del> <ins> let span = if last_idx < provided_arg_count { </ins> let first_arg_span = provided_args[first_idx].span; <del> let second_arg_span = provided_args[second_idx].span; </del> <ins> let last_arg_span = provided_args[last_idx].span; </ins> Span::new( first_arg_span.lo(), <del> second_arg_span.hi(), </del> <ins> last_arg_span.hi(), </ins> first_arg_span.ctxt(), None, )

Discussion:
: <!-- 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 --
Also ICEs on beta. Output on stable: label regression-from-stable-to-beta
searched nightlies: from nightly-2022-04-16 to nightly-2022-04-17 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium