jiebi/CodeConvo huggingface dataset:
Change:
pub(crate) struct InvalidTargetFeaturePrefix<'a> { pub feature: &'a str, } <ins> #[derive(Diagnostic)] #[diag(codegen_llvm_fixed_x18_invalid_arch)] pub(crate) struct FixedX18InvalidArch<'a> { pub arch: &'a str, } </ins>

Discussion:
On the target, specifying the target feature using the flag results in the following warning: The desired effect of this flag is to reserve the x18 register so that LLVM does not use it during codegen. Note that despite the warning, the flag still works fine today since it is passed on to LLVM. This feature is necessary for Rust to work when using the Linux Kernel's dynamic shadow call stack feature on aarch64 (). The shadow call stack feature requires that the x18 register is reserved, since it is used to store the shadow stack. In C code, the dynamic version of shadow call stack requires you to pass but not (which is only used for non-dynamic SCS). Clang has a collection of flags for reserving other registers than x18 as well. I think it would make sense to add those as well, even if they are less useful than x18. Related to . Related to .
This affects the ABI, right? I think adding a target spec option makes the most sense (or actually you can already set it as target feature in the target spec without giving a warning). That way you can't enable or disable it for individual functions or crates, which would break the ABI.
Yeah, it would be nice to have a flag for this (or having something like "global target features", i.e. like , but that it ensures it is set the same way for all compilation units).
There could be ABI concerns with this in general. AAPCS64 defines x18 as a platform register if required, or temporary if a platform register isn't needed. For x18 it's probably unlikely for it to have ABI concerns as it's already reserved for use on some platforms, the ones where it's not already reserved, it's only supposed to be a temporary register so not using it should be OK as it is not used for any fixed purpose. That's obviously assuming a platform defines its ABI based on the Arm standards. LLVM does support reserve on other registers, most notably for ABI reasons, x1 through x7 which would have ABI problems. LLVM does have test cases to ensure that a function call doesn't occur if any of the argument registers have been reserved. I'm not sure what other codegen backends do in that case though, or if they even support reserving those registers.

The analysis that LLVM does, doesn't seem to care if it would need to use that register for ABI reasons, even a function such as can't be called in a quick test. Using target features for this feels strange to me though, I'm wondering if a codegen option to reserve certain registers would be a better approach here. While this issue is specifically about reserving a register on AArch64, LLVM does support this for multiple other architectures and multiple registers, which we should maybe consider for the future.
Change:
If this is your first time contributing, the [walkthrough] chapter of the guide can give you a good example of how a typical contribution would go. <del> [pound-rust-internals]: https://chat.mibbit.com/?server=irc.mozilla.org&channel=%23rust-internals </del> [internals]: https://internals.rust-lang.org [rust-discord]: http://discord.gg/rust-lang [rust-zulip]: https://rust-lang.zulipchat.com

Discussion:
There are still of IRC in the repo. Removing them is not a priority but it will avoid confusion for newcomers.
Should these places be replaced with references to the rust discord server, or just be removed outright?
Probably replaced. Gonna update title.
Opened to address this.
This is horrible. Replacing IRC with Discord.. :/
If you haven't read about it yet, is the post from April.
Yeah I read already. I'd remove the mention of any particular discussion channel, instead of putting Discord in. I can't wait for Matrix to become more mature so the Rust project can use it. Falling back to Discord is quite bad for a FOSS project.
IMO we should just mirror subreddit solution and point to Discord.
Change:
TokenTree::Sequence(span, ref seq) => { if seq.separator.is_none() && seq.tts.iter().all(|seq_tt| { match *seq_tt { <ins> TokenTree::MetaVarDecl(_, _, id) => id.name == "vis", </ins> TokenTree::Sequence(_, ref sub_seq) => sub_seq.op == quoted::KleeneOp::ZeroOrMore, _ => false,

Discussion:
Test case: Compiling this stuck forever in the "expansion" pass. cc ( tracking issue). Since can match "nothing", the macro should error with "repetition matches empty token tree".
Change:
} let module = self.tcx.hir.get_module_parent(scrut.id); <del> MatchCheckCtxt::create_and_enter(self.tcx, module, |ref mut cx| { </del> <ins> MatchCheckCtxt::create_and_enter(self.tcx, self.param_env, module, |ref mut cx| { </ins> let mut have_errors = false; let inlined_arms : Vec<(Vec<_>, _)> = arms.iter().map(|arm| (

Discussion:
Attempting to pattern match a slice with a constant value and THEN a slice literal causes an ICE. Simple test case: However simply changing the order to test the slice literal and then the const slice compiles fine: Error message: rustc version:
So... I do have a fix for byte slices, but that just exposed that we have the same ICE for other slices: This can be fixed, too, but I need to wait for to be merged before being able to do this in a reasonable way.
Change:
| LL |         K: Borrow<Q>, |            ^^^^^^^^^ required by this bound in `HashMap::<K, V, S>::get` <del> help: consider specifying the generic argument | LL |         .get::<Q>(&"key".into()) |             +++++ </del> help: consider specifying the type argument in the function call | LL |         .get::<Q>(&"key".into())

Discussion:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
<ins> //! I missed a `cfg_attr` match in #128581, it should have had the same treatment as `cfg`. If //! an invalid attribute starting with `cfg_attr` is passed, then it would trigger an ICE because //! it was not considered "checked" (e.g. `#[cfg_attr::skip]` or `#[cfg_attr::no_such_thing]`). //! //! This test is not exhaustive, there's too many possible positions to check, instead it just does //! a basic smoke test in a few select positions to make sure we don't ICE for e.g. //! `#[cfg_attr::no_such_thing]`. //! //! issue: rust-lang/rust#128716 #![crate_type = "lib"] #[cfg_attr::no_such_thing] //~^ ERROR failed to resolve mod we_are_no_strangers_to_love {} #[cfg_attr::no_such_thing] //~^ ERROR failed to resolve struct YouKnowTheRules { #[cfg_attr::no_such_thing] //~^ ERROR failed to resolve and_so_do_i: u8, } #[cfg_attr::no_such_thing] //~^ ERROR failed to resolve fn a_full_commitment() { #[cfg_attr::no_such_thing] //~^ ERROR failed to resolve let is_what_i_am_thinking_of = (); } #[cfg_attr::no_such_thing] //~^ ERROR failed to resolve union AnyOtherGuy { owo: () } struct This; #[cfg_attr(FALSE, doc = "you wouldn't get this")] impl From<AnyOtherGuy> for This { #[cfg_attr::no_such_thing] //~^ ERROR failed to resolve fn from(#[cfg_attr::no_such_thing] any_other_guy: AnyOtherGuy) -> This { //~^ ERROR failed to resolve #[cfg_attr::no_such_thing] //~^ ERROR attributes on expressions are experimental //~| ERROR failed to resolve unreachable!() } } #[cfg_attr::no_such_thing] //~^ ERROR failed to resolve enum NeverGonna { #[cfg_attr::no_such_thing] //~^ ERROR failed to resolve GiveYouUp(#[cfg_attr::no_such_thing] u8), //~^ ERROR failed to resolve LetYouDown { #![cfg_attr::no_such_thing] //~^ ERROR an inner attribute is not permitted in this context never_gonna: (), round_around: (), #[cfg_attr::no_such_thing] //~^ ERROR failed to resolve and_desert_you: (), }, } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: builtin attribute "cfgattr" not handled by ', 'error: internal compiler error: builtin attribute "cfgattr" not handled by ' 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: [checkmodattrs] checking attributes in top-level module [analysis] running analysis passes on this crate --
Change:
<ins> // build-fail #![feature(const_fn)] #![feature(const_unreachable_unchecked)] const unsafe fn foo(x: bool) -> bool { match x { true => true, false => std::hint::unreachable_unchecked(), } } #[warn(const_err)] const BAR: bool = unsafe { foo(false) }; fn main() { assert_eq!(BAR, true); //~^ ERROR E0080 //~| ERROR erroneous constant } </ins>

Discussion:
Currently one cannot call in constant functions, so one cannot add hints of the form: These types of hints can heavily influence code generation, which can substantially change the performance of when they are invoked at run-time. It would be a shame to have to write and call and because the code generated for is sub-par. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
One cannot do any sort of conditional control flow, so would currently be less than useless. Any test you can write would be undefined behaviour
the RFC for / in const was merged and is pending an implementation right? When that's implemented, will still be useless?
No it makes sense after we have conditional control flow.
As I understand / in const functions is now implemented. Can be made into a now?
yes. Basically you just need to add the attribute to the intrinsic and wrapper function. This is documented at https://rustc-dev- Let me know if anything is unclear (in which case we should update the guide)
Hi, It looks like previous PR is not being worked on currently. I'm working on this and will create a PR soon. claim
As mentioned in , this issue should be reopened (to track stablization)
cc ^
After a short discussion on Zulip, it was decided that it's best to wait for to stabilize to avoid a potential footgun wherein users use this instead of , leading to UB at runtime. I'm subscribed to the issue and intend to file a PR to stabilize this once the aforementioned happens.
Change:
<del> // Regression test for various issues related to normalization & inlining. // * #68347, #77306, #77668 - missed normalization during inlining. // * #78442 - missed normalization in validator after inlining. // // build-pass </del> <ins> // run-pass </ins> // compile-flags:-Zmir-opt-level=2 <ins> // Previously ICEd because we did not normalize during inlining, // see https://github.com/rust-lang/rust/pull/77306 for more discussion. </ins> pub fn write() { create()() } <del> pub fn write_generic<T>(_t: T) { hide()(); } </del> pub fn create() -> impl FnOnce() { || () } <del> pub fn hide() -> impl Fn() { write } </del> fn main() { write(); <del> write_generic(()); </del> }

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:
<ins> error[E0207]: the lifetime parameter `'a` is not constrained by the impl trait, self type, or predicates --> $DIR/unconstrained-impl-region.rs:13:6 | LL | impl<'a> Actor for () { |      ^^ unconstrained lifetime parameter error: aborting due to previous error For more information about this error, try `rustc --explain E0207`. </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 +E-needs-mcve
Minimized to:
might be similar to , cc who self-assigned and probably knows more about this stuff ^^
in case we need more code snippets, here are 60 of them that that can trigger the ice in some way or another :upsidedownface:
I'm pretty sure all (or at least most) of these examples are not related. This issue is specifically the case where the code used to emit: and now ICEs. is unrelated except for the ICE message.
Ah so this () is a new one? Need to put some though into automatic ice distinction (perhaps based on query stack?)
Yeah, there's a class of ICEs that have the same name and often very different root causes (i.e. ICEs in snapshot-vec) and this is one of them.
Change:
#[derive(Copy="bad")] //~ ERROR expected one of `)`, `,`, or `::`, found `=` struct Test2; <del> #[derive()] //~ WARNING empty trait list struct Test3; </del> #[derive] //~ ERROR malformed `derive` attribute input struct Test4;

Discussion:
The following code emits an unsquelchable warning. This warning should be a part of .
empty trait list in should have a lint name ... and that name is .
Does not appear to squelch the warning for me...
It seems eminently reasonable to me to include in since it is an attribute applied with no effect; so let's kick off fcp for that. merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), 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.
Implementing this as part of the existing would be complicated by , but it might also be possible to implement where the existing "empty trait list" warning is issued (possibly as a ).
I need to make a buffered early lint for the same thing with .
Seems reasonable. And a macro that might end up with an empty derive list should have no problem turning off locally.
reviewed I certainly agree with moving warnings to lints.
: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.
Change:
} } else { let attrs = self.parse_outer_attributes()?; // For recovery. <ins> let maybe_fatarrow = self.token.clone(); </ins> let block = if self.check(&token::OpenDelim(Delimiter::Brace)) { self.parse_block()? } else {

Discussion:
When encountering code like , we currently emit But it should be closer to <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hi! I'd like to try working on this issue if nobody else is currently. claim
Change:
let fat_addr: usize = std::intrinsics::transmute(fat as *const ()); } <ins> #[custom_mir(dialect = "analysis")] fn remove_casts_must_change_both_sides(mut_a: &*mut u8, mut_b: *mut u8) -> bool { // CHECK-LABEL: fn remove_casts_must_change_both_sides( mir! { // We'd like to remove these casts, but we can't change *both* of them // to be locals, so make sure we don't change one without the other, as // that would be a type error. { // CHECK: [[A:_.+]] = (*_1) as *const u8 (PtrToPtr); let a = *mut_a as *const u8; // CHECK: [[B:_.+]] = _2 as *const u8 (PtrToPtr); let b = mut_b as *const u8; // CHECK: _0 = Eq([[A]], [[B]]); RET = a == b; Return() } } } </ins> fn main() { subexpression_elimination(2, 4, 5); wrap_unwrap(5);

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:
|lint| lint.build("missing code example in this documentation").emit(), ); } <del> } else if rustc_feature::UnstableFeatures::from_environment().is_nightly_build() && tests.found_tests > 0 && !cx.renderinfo.borrow().access_levels.is_public(item.def_id) </del> <ins> } else if tests.found_tests > 0 && !cx.renderinfo.borrow().access_levels.is_public(item.def_id) </ins> { cx.tcx.struct_span_lint_hir( lint::builtin::PRIVATE_DOC_TESTS,

Discussion:
As of , the lint is no longer working. /// let x = 1; /// I expected to see this happen: should issue Instead, this happened: No warnings emitted. This appears to have changed in . I don't see any discussion there about this, so I'm guessing it was unintentional. cc
This was definitely unintentional. I thought I a test for this ...
Hmm, it tests with but not with . Maybe the name_ of the lint wasn't registered?
The issue is . Compiletest runs with RUSTC_BOOTSTRAP set. I don't recall off the top of my head how to force a test to be stable.
Wait now I'm confused. I thought the point of this lint was that it only runs on nightly, because we're not sure if we want to stabilize it. cc
are you sure this used to work?
The lint has been on stable since 1.32. It is documented .
Got it, I mixed it up with . Yeah this is a bug then - the two lints should be treated differently.
Actually it looks like I introduced the opposite bug for - it now runs on beta when it shouldn't.
Assigning as and removing .
Change:
#![feature(const_size_of_val)] #![feature(const_align_of_val)] #![feature(const_ptr_read)] <ins> #![feature(const_maybe_uninit_zeroed)] </ins> #![feature(const_maybe_uninit_write)] #![feature(const_maybe_uninit_as_mut_ptr)] #![feature(const_refs_to_cell)]

Discussion:
I want to initialize a large with . Compiling with Rust 1.66 generates instructions. However, after initializing with the code gets vectorized as expected: The generated assembly contains instructions. Now, the weird thing is that if I have both functions in the same file, both get vectorized. See this . As long as is commented out, is not vectorized. As soon as you remove the comment, both functions are vectorized.
Easiest fix for specifically would be to update , I think. We don't guarantee a layout for it, but internally for optimizations I think we'd be safe doing this. (We can put some tests like in non-public stuff to help double-check it.)
When is , couldn't the part of the memory layout be anything since it shouldn't be accessed? Couldn't we use that for optimization? So for example, if sets the discriminator bit to 0, couldn't we always zero out the entire memory no matter what is? Or if the discriminator is represented with a non-zero value, couldn't the whole data structure be filled up with that value (or just left unitialized depending on which is faster)?
Unfortunately not, because there can be other niches than 0. For instance, has the value 0xffff_ffff on Unix platforms.
Can we at least assume that two -s will always have the same bytes in memory for any fixed ? If so, couldn't we vectorize filling up the with those bytes?
I think similar to . iirc the main issue is that LLVM's InstCombine removes the instructions before reaching the passes that could use this information to optimize - at this point, it generally becomes a series of stores with gaps between which LLVM no longer knows can be written to freely.
No, because something like is half , where "the same" isn't a meaningful question. That's exactly what I mention for -- you can use that to check that it's a value where it would be legal to zero out the whole thing, and if that function returns then uses a zeroing allocator instead of the needing initialize the memory.
Change:
if adt_kind != ty::AdtKind::Enum { tcx.check_stability(v_field.did, expr_id, field.span); } <ins> self.field_ty(field.span, v_field, substs) </ins> } else { error_happened = true; <del> final_field_type = tcx.types.err; field_type_hint = tcx.types.err; </del> if let Some(_) = variant.find_field_named(field.name.node) { let mut err = struct_span_err!(self.tcx.sess, field.name.span,

Discussion:
fails to type check, while succeeds.
This coercion is important when using byte string literals.
The tuple struct case is actually the function call "expected type" propagation, which would have to be adapted to struct literals as well.
Yes.
Coercion already happens in non-generic struct literals:
Yes, but the field types are taken from the struct and not combined with the overall expected type for the struct literal.
I just discovered this bug/unexpected behavior today (). I would like to see some movement on it because it's surprising that these two don't work the same way. Here's a workaround I found; it's ugly as hell but I'm using it in a generated file that no human would want to look through anyway: I tried type ascription but it seems to not cue coercion, it just moves the type error: It seems that forcing a concrete type on the struct literal works as well (I didn't expect this syntax to work, honestly): Unfortunately this won't work for me because I'm using too and I can't add this extra syntax myself.
Any news on this?
Is anyone working on it?
It seems like implemented a partial fix in but suggests that there are backwards incompatibility issues to be considered that preventing him from going further. I'm not quite sure what he had in mind there, perhaps he can elaborate.
Making sure we remember to look at this.
What I did is I computed a "light hint" (which becomes "strong hint", i.e. forcing coercion, if it reaches a block, and it's enough to help integer inference for ). This is a common problem with coercion hints, in that unless there's enough type information to prevent them from triggering, they will trigger early even if that breaks later on. The thing to try here is to replace with the simpler: doesn't even need to be computed if that works, since is at least as specific - AFAICT, we already have that "specificity" with function calls, but since it hasn't been used with struct literals before, crater/cargobomb might reveal regressions.
ok, I was mostly wondering if you encountered actual regressions in practice, or just theorize that this might lead to problems.
I don't think I got the chance to do a crater run and then I lost track of it.
will open a PR and we can try a crater run at least.

There is still a similar problem with the type inference of temporaries when you have an array that should be interpreted as a slice buried in a tuple inside an outer slice.