jiebi/CodeConvo huggingface dataset:
Change:
pub trace_mac: bool, pub exported_macros: Vec<Gc<ast::Item>>, <del> pub syntax_env: SyntaxEnv, </del> <ins> pub syntax_env: SyntaxEnv, </ins> } impl<'a> ExtCtxt<'a> {

Discussion:
I believe this should output the string : But I get this error: Rust version:
Note that standard recursive macros work fine, e.g., And outputs . Maybe the bug here is that expanding macros within other macros is using an older environment that doesn't include the name ?
It's even worse than that. only uses the compiler built-in macros:
I think this might be a dupe of
Does fixing mean that also gets fixed? I wouldn't assume so, but it might be possible depending on the implementation. (Sorry I missed that issue. I searched for 'recursive macro' instead of 'nested macro'!)
both and use , which doesn't work with non-builtin macros.
Right. I'm referring to the recursive aspect. Wasn't sure if that would make a difference. (I just don't know enough about how macros are expanded to know. Pure guesswork on my part.)
Change:
} } <ins> #[derive(Clone, Debug, PartialEq, Eq, Hash, PartialOrd, Ord)] pub enum ObjectSafetyViolationSolution { None, AddSelfOrMakeSized { name: Symbol, add_self_sugg: (String, Span), make_sized_sugg: (String, Span), }, ChangeToRefSelf(Symbol, Span), MoveToAnotherTrait(Symbol), } impl ObjectSafetyViolationSolution { pub fn add_to(self, err: &mut Diagnostic) { match self { ObjectSafetyViolationSolution::None => {} ObjectSafetyViolationSolution::AddSelfOrMakeSized { name, add_self_sugg, make_sized_sugg, } => { err.span_suggestion( add_self_sugg.1, format!( "consider turning `{name}` into a method by giving it a `&self` argument" ), add_self_sugg.0, Applicability::MaybeIncorrect, ); err.span_suggestion( make_sized_sugg.1, format!( "alternatively, consider constraining `{name}` so it does not apply to  trait objects" ), make_sized_sugg.0, Applicability::MaybeIncorrect, ); } ObjectSafetyViolationSolution::ChangeToRefSelf(name, span) => { err.span_suggestion( span, format!("consider changing method `{name}`'s `self` parameter to be `&self`"), "&Self", Applicability::MachineApplicable, ); } ObjectSafetyViolationSolution::MoveToAnotherTrait(name) => { err.help(format!("consider moving `{name}` to another trait")); } } } } </ins> /// Reasons a method might not be object-safe. #[derive(Clone, Debug, PartialEq, Eq, Hash, HashStable, PartialOrd, Ord)] pub enum MethodViolationCode {

Discussion:
made it so that we report all object safety violations at the same time. However, it also results in a redundant note: We should not add the same note multiple times.
Can we add a debug assertion for duplicate identical help messages? (sorta like we do for "Span must not be empty and have no suggestion" or "Suggestion may not have overlapping parts" ?
I guess we could, but I think there are multiple diagnostics that currently do this, so we'll have to fix them first.
Did not find tooo much... inside :
Change:
<ins> // skip-filecheck //@ test-mir-pass: GVN //@ only-64bit //@ compile-flags: -Z mir-enable-passes=+Inline // Regression for <https://github.com/rust-lang/rust/issues/127089> #![feature(strict_provenance)] struct Foo<T>(std::marker::PhantomData<T>); impl<T> Foo<T> { const SENTINEL: *mut T = std::ptr::dangling_mut(); fn cmp_ptr(a: *mut T) -> bool { std::ptr::eq(a, Self::SENTINEL) } } // EMIT_MIR gvn_ptr_eq_with_constant.main.GVN.diff pub fn main() { Foo::<u8>::cmp_ptr(std::ptr::dangling_mut()); } </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. --Compiling the following code with results in ICE. Strangely, this code compiles fine without . Replace with plain comparison also works. : <!-- 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
This seems to bisect to cc
Thanks for the ping! I'll take a look. I thought I'd checked for this with , but clearly I missed something.
Change:
println!("nspurious failure, trying again"); } } <ins> if !help_on_error.is_empty() { eprintln!("{}", help_on_error); } </ins> std::process::exit(1); } }

Discussion:
I accidentally missed this when porting it to rustbuild: It would be nice to add it back. Mentoring instructions: Add a new parameter to and pass it down from : This code moved around in so you may want to base your changes off that PR until it lands. label +E-easy +E-mentor +A-rustbuild <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Please also remove the dead code from at the same time:
claim
Change:
pub use reexport::Reexported; <ins> pub struct Foo; pub enum Bar { X } </ins> pub mod foo { pub trait PubPub { fn method(&self) {}

Discussion:
E.g. (The repetition is .) However, all of these are useless: because one cannot implement them for anyway, it would be better to just filter them out, e.g. reject external traits when the self type itself is external. cc
Good point, although it's not always as simple as that -- with multidispatch it is plausible you COULD implement the trait for if another type parameter were local, though not with the current orphan rules. Nonetheless, it might be good to just screen them out anyway, as it is unlikely to be what you plan to do.
Change:
"serde 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)", "serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)", "serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)", <ins> "walkdir 2.2.7 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", ]

Discussion:
If I modify a file in the rustc source code (), is smart enough to rerun all tests. However, if I modify something in , then still ignores the tests that completed successfully in the previous run. Steps to reproduce: tests: . For example, replace the function in  with: tests again: Expected output: some tests fail. Actual output:
I would be interested in fixing this issue myself if someone could give me some guidance on how to do that. The main thing that I do not understand is how understands that was changed. It seems that it does not use files for this because they include only the hash of the configuration options which do not include version. cc
The most likely culprit (that ignores the test files) is in module. It is called from and will set the flag for the test depending on its output.
That being said, I find it hard to see how to adjust compiletest itself to take the dependencies into account. rustbuild should probably have some sort of dependency edge and delete the stamp files if/when stuff like compiletest changes.
Compiletest source code has only 9 files. Would it be acceptable to check that their timestamps are newer than the timestamp of the stamp file? PR:
Change:
if !target.contains("windows") { let needs_unstable_opts = target.contains("linux") <ins> || target.contains("solaris") </ins> || target.contains("windows") || target.contains("bsd") || target.contains("dragonfly")

Discussion:
While building Rust 1.62.0 on Solaris SPARC it fails with:
Looks like this was caused by (cc It looks like that also caused issues with openbsd (), I'm wondering if it would make sense to audit which platforms were affected to make sure they are all addressed? Passing seems like a somewhat blunt solution. I would expect it to not pass if the target does not support it and the user did not specify it. That is roughly what , though I suspect that might be not as easy to do in bootstrap.
I'm not sure there's a great way of solving this properly in bootstrap. It should be solved for good by but if you want to submit a PR in the meantime that adds a condition for Solaris then I can r+ it.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
/// Shortens the vector, keeping the first `len` elements and dropping /// the rest. /// <del> /// If `len` is greater than the vector's current length, this has no /// effect. </del> <ins> /// If `len` is greater or equal to the vector's current length, this has /// no effect. </ins> /// /// The [`drain`] method can emulate `truncate`, but causes the excess /// elements to be returned instead of dropped.

Discussion:
The documentation currently says But it also doesn't have an effect if the two lengths are equal, so I think it should say "greater or equal to the vector's current length". <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
yes, there is a trivial difference between and , but it's an internal implementation issue, I think we should update the doc since they are same from the user's view.
claim
Change:
use rustc_middle::middle::codegen_fn_attrs::CodegenFnAttrFlags; use rustc_middle::mir; use rustc_middle::ty; <ins> use rustc_middle::ty::layout::TyAndLayout; </ins> use rustc_middle::ty::layout::{HasTyCtxt, LayoutOf}; use rustc_session::config::DebugInfo; use rustc_span::symbol::{kw, Symbol}; use rustc_span::{BytePos, Span}; <del> use rustc_target::abi::Abi; use rustc_target::abi::Size; </del> <ins> use rustc_target::abi::{Abi, Size, VariantIdx}; </ins> use super::operand::{OperandRef, OperandValue}; use super::place::PlaceRef;

Discussion:
When generating a variable debuginfo, rustc emits an expression describing the address of a source variable. Since , rustc also evaluates this expression. The expression can contain indirections, and it is not always valid to evaluate it. Consider a source variable that is described indirectly in terms of a base local. The source variable will be introduced at the beginning of a function, but at this point the base local might be uninitialized. For example: Note that has and metadata but loaded value is uninitialized. (This leads to end-to-end miscompilation with -Cdebuginfo=2). cc
A variant that demonstrates complete end-to-end miscompilation can be found in
Even without the metadata, this load could violate constraints. So just removing the metadata is not a proper fix. EDIT: Or does this always load from an that doesn't have any other pointers to it yet? Then it should be fine in terms of aliasing.
Change:
} } <del> fn unsize_into( </del> <ins> crate fn unsize_into( </ins> &mut self, src: Value, src_layout: TyLayout<'tcx>,

Discussion:
inlined inside a , I get a warning: however, when I involve a variable there is no warning at all but looking at the generated code it is quite clear that this panics:
It warns on current stable, but not on beta and nightly. Might be miri fallout? cc Curiously, when you take a reference (to trigger promotion to static) you get a hard error on beta and nightly (stable is still a warning). Isn't that a regression?
triage: P-medium Still want to get those warnings, but no longer P-high
Hm, what is the status of this? The PR was merged, but with , I don't get a compiler warning for the first example. For the second one I get two though? :confused:
The PR was just for the compilation error. The missing warnings just need an impl for this branch: The warning duplication is unfortunate, but if we deduplicate it, we loose warnings in other edge cases. We could deduplicate it similar to the way the notes about where the lint level was set are deduplicated (note how the second warning has no message). That would probably be the cleanest solution.
Change:
fn process_collected_capture_information( &self, capture_clause: hir::CaptureBy, <del> capture_information: InferredCaptureInformation<'tcx>, </del> <ins> capture_information: &InferredCaptureInformation<'tcx>, </ins> ) -> (InferredCaptureInformation<'tcx>, ty::ClosureKind, Option<(Span, Place<'tcx>)>) { let mut closure_kind = ty::ClosureKind::LATTICE_BOTTOM; let mut origin: Option<(Span, Place<'tcx>)> = None; let processed = capture_information <del> .into_iter() </del> <ins> .iter() .cloned() </ins> .map(|(place, mut capture_info)| { // Apply rules for safety before inferring closure kind let (place, capture_kind) =

Discussion:
Rustc panicked when I attempted to use async in poll. I wanted to compose an async task inside my custom future :
I believe this is a duplicate of , which I have a local branch to fix but which needs a bit of cleanup first.

<!-- 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. --I tried this code (minimized): I expected to see this happen: Compiles Instead, this happened (): Instead, this happened (latest nightly): ICE Related: Mentioning :wink: Best guess: <details<summaryBacktrace</summary<p</p</details<!-- 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-nightly-to-nightly -regression-untriaged Thanks for investigating! -
Nightly-only features aren't typically regression triaged. I'll look into it soon.
Change:
<ins> warning: the feature `dyn_star` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/union.rs:1:12 | LL | #![feature(dyn_star)] |            ^^^^^^^^ | = note: see issue #102425 <https://github.com/rust-lang/rust/issues/102425> for more information = note: `#[warn(incomplete_features)]` on by default error[E0277]: `Union` needs to have the same ABI as a pointer --> $DIR/union.rs:14:9 | LL |     bar(Union { x: 0usize }); |         ^^^^^^^^^^^^^^^^^^^ `Union` needs to be a pointer-like type | = help: the trait `PointerLike` is not implemented for `Union` error: aborting due to 1 previous error; 1 warning emitted For more information about this error, try `rustc --explain E0277`. </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. -- In particular, this also happens with . <!-- 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-dyn_star requires-nightly
Regression in nightly-2022-10-16 found 7 bors merge commits in the specified range commit[0] 2022-10-14: Auto merge of - woppopo:const_location, r=scottmcm commit[1] 2022-10-14: Auto merge of - matthiaskrgr:rollup-xxsx6sk, r=matthiaskrgr commit[2] 2022-10-15: Auto merge of - joshtriplett:is-terminal-fd-handle, r=thomcc commit[3] 2022-10-15: Auto merge of - Aaron1011:stability-use-tree, r=cjgillot commit[4] 2022-10-15: Auto merge of - compiler-errors:dyn-star-plus, r=eholk commit[5] 2022-10-15: Auto merge of - Dylan-DPC:rollup-97cvwdv, r=Dylan-DPC commit[6] 2022-10-15: Auto merge of - Nilstrieb:query-cleanups, r=cjgillot ERROR: no CI builds available between and within last 167 days maybe ?
Change:
child_name_bindings.define_value(def, DUMMY_SP, is_exported); } } <ins> DefFn(ctor_id, _, true) => { child_name_bindings.define_value( csearch::get_tuple_struct_definition_if_ctor(&self.session.cstore, ctor_id) .map_or(def, |_| DefStruct(ctor_id)), DUMMY_SP, is_public); } </ins> DefFn(..) | DefStaticMethod(..) | DefStatic(..) => { debug!("(building reduced graph for external  crate) building value (fn/static) {}", final_ident);

Discussion:
compiles fine (other than the dead code warning for ), but is not:
I hit this as well, I would love a fix :+1:
Change:
method_name: ast::Name, error: MethodError) { <ins> // avoid suggestions when we don't know what's going on. if ty::type_is_error(rcvr_ty) { return } </ins> match error { MethodError::NoMatch(static_sources, out_of_scope_traits) => { let cx = fcx.tcx();

Discussion:
E.g. (The repetition is .) However, all of these are useless: because one cannot implement them for anyway, it would be better to just filter them out, e.g. reject external traits when the self type itself is external. cc
Good point, although it's not always as simple as that -- with multidispatch it is plausible you COULD implement the trait for if another type parameter were local, though not with the current orphan rules. Nonetheless, it might be good to just screen them out anyway, as it is unlikely to be what you plan to do.
Change:
Some(param_def) } GenericParamKind::Const { default, .. } => { <del> if !allow_defaults && default.is_some() { </del> <ins> if !matches!(allow_defaults, Defaults::Allowed) && default.is_some() { </ins> tcx.sess.span_err( param.span, "defaults for const parameters are only allowed in 

Discussion:
I tried this code: I expected to see this happen: It not work correctly as if you remove it shouts at you saying its unsupported and will be a hard error one day. Instead, this happened: defaults on GATs seem to function perfectly fine version from playground: cc this is probably should either be allowed or a hard error before stabilisation?
one issue is that we ignore defaults on the gat in impls
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
"rustc_span", "rustc_symbol_mangling", "rustc_target", <ins> "rustc_trait_selection", </ins> "rustc_type_ir", "serde_json", "smallvec",

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:
<ins> // Disabling on android for the time being // See https://github.com/rust-lang/rust/issues/73535#event-3477699747 #![cfg(not(target_os = "android"))] </ins> #![feature(btree_drain_filter)] #![feature(map_first_last)] #![feature(repr_simd)]

Discussion:
Recently enabled benchmarks () frequently fail on arm-android builder on GitHub Actions: The issue looks similar to previously reported .
I'm sorry, I noticed this during my local testing, but figured it was due to my hardware which had a very high parallel count, and it seemed to go away when I lowered the parallel test threads. I also had great difficulty running these tests at -j32 on android as well: They either seemed to hang, or took a very long time to finish. Would people prefer to just disable the bench tests on android, or should we do more investigation?
Again? cc
Looks like didn't fix the "died due to signal 11" errors either :(
hm, yeah if these keep coming back I guess that's reason enough for me to allocate time for it again.
will open a PR disabling collectionsbench on Android for the time being.
Change:
LL | static mut SM2 = "abc"; |            ^^^ help: provide a type for the item: `SM2: <type>` <del> error: aborting due to 6 previous errors </del> <ins> error: aborting due to 7 previous errors </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Report from : searched nightlies: from nightly-2020-03-09 to nightly-2020-03-31 regressed nightly: nightly-2020-03-20 searched commits: from to regressed commit:
This is presumably due to -- cc
This was . Tagging it as . Not removing nomination until we can assign this issue.
assign (assigning based on claim that this was injected by PR )
This is the feature where for a with a missing type will look at the body and get the type from there. We should replace all regions in that situation with , just so the code which ICEs here will continue to ICE for legitimate bugs.
Doesn't reproduce with ( ):
Hmmmm, I'm not sure I agree with that assessment, unless -- well -- I guess you're saying that the "correct static type" for any such expression would be anyway?
yes, this is recovery for a guaranteed error, after all. A slightly more aggressive example: Results in this query stack for the ICE: I have no idea why changing to changes anything but they should both ICE IMO (before we switch to replacing erased regions with ). I'm now worried there are other places in which is used to extract some type and "export" it outside of the context of the body, without the necessary precautions.
Change:
}); } else { debug_assert!(self.tcx.is_trait(trait_def_id)); <ins> if self.tcx.trait_is_auto(trait_def_id) { return; } </ins> for item in self.impl_or_trait_item(trait_def_id) { // Check whether `trait_def_id` defines a method with suitable name. if !self.has_applicable_self(&item) {

Discussion:
Given the following The current output is: The second error is not reasonable, since we don't allow associated items in auto trait. Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I spent some time to investigate it, I tried to filter the candidates from auto trait. But seems here have two predicates, and the message for the second error comes from the first : I'm still trying to understand the code.
claim
Change:
<ins> // We check the background color on the jump to definition links in the source code page. goto: file://|DOC_PATH|/src/link_to_definition/lib.rs.html // Set the theme to dark. local-storage: {"rustdoc-theme": "dark", "rustdoc-preferred-dark-theme": "dark", "rustdoc-use-system-theme": "false"} // We reload the page so the local storage settings are being used. reload: assert-css: ("body.source .example-wrap pre.rust a", {"background-color": "rgb(51, 51, 51)"}, ALL) // Set the theme to ayu. local-storage: {"rustdoc-theme": "ayu", "rustdoc-preferred-dark-theme": "ayu", "rustdoc-use-system-theme": "false"} // We reload the page so the local storage settings are being used. reload: assert-css: ("body.source .example-wrap pre.rust a", {"background-color": "rgb(51, 51, 51)"}, ALL) // Set the theme to light. local-storage: {"rustdoc-theme": "light", "rustdoc-use-system-theme": "false"} // We reload the page so the local storage settings are being used. reload: assert-css: ("body.source .example-wrap pre.rust a", {"background-color": "rgb(238, 238, 238)"}, ALL) </ins>

Discussion:
Interestingly, the dark theme works fine. Screenshot of Ayu: ! cc
Sending a fix in the next few hours.