jiebi/CodeConvo huggingface dataset:
Change:
pub mod rustdoc_css_themes; pub mod rustdoc_gui_tests; pub mod style; <ins> pub mod target_policy; </ins> pub mod target_specific_tests; pub mod tests_placement; pub mod ui_tests;

Discussion:
(wrapped by hand to make the problem clear) The function pointer alignment is the same as our powerpc64-unknown-linux-gnu target, so the discrepancy must be in LLVM. While this is a tier 3 target, we are completely unable to generate code for it, so at some point this part of the target tier policy will become relevant (emphasis mine): If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (there are none, not even for the Tier 2 -gnu variant) (and potentially other people who have previously worked on the target), to check potential interest in improving the situation. I have trawled the issue tracker and I cannot find any evidence that this target is in use; all issues seem related to or the targets.
Does this also impact ppc64le? That's supported by Alpine, which uses musl. It looks like is the maintainer with musl. Not knowing anything about ppc, or very much about LLVM's data layouts, it looks like may be what broke this.
powerpc64le is not affected. Unfortunately looking at that diff I still can't figure out which of the targets is correct.
So I'm running into this in , the relevant code in LLVM is: () () We get rather than because of the musl-ness of the target. As far as I can tell, this would have been the case since , and the definition of hasn't changed . I think we just got this value wrong in .
Just as a side note – I am using it and I've hit this bug while building the current stable branch. Thank you for maintaining it.
Change:
<del> //run-pass </del> <ins> // run-pass // revisions: opt noopt //[noopt] compile-flags: -Copt-level=0 //[opt] compile-flags: -O </ins> #![feature(repr_simd, platform_intrinsics)] <ins> #![allow(incomplete_features)] #![feature(adt_const_params)] </ins> extern "platform-intrinsic" { fn simd_shuffle<T, I, U>(a: T, b: T, i: I) -> U; <ins> fn simd_shuffle16<T, U>(x: T, y: T, idx: [u32; 16]) -> U; </ins> } #[derive(Copy, Clone)] #[repr(simd)] struct Simd<T, const N: usize>([T; N]); <ins> pub unsafe fn __shuffle_vector16<const IDX: [u32; 16], T, U>(x: T, y: T) -> U { simd_shuffle16(x, y, IDX) } </ins> fn main() { const I1: [u32; 4] = [0, 2, 4, 6]; const I2: [u32; 2] = [1, 5];

Discussion:
: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This might be related to cc
Reverting from to (before was merged) fixes the issue for me.
Change:
# i686-unknown-linux-gnu configuration CC_i686-unknown-linux-gnu=$(CC) <del> LINK_i686-unknown-linux-gnu=cc </del> CXX_i686-unknown-linux-gnu=$(CXX) CPP_i686-unknown-linux-gnu=$(CPP) AR_i686-unknown-linux-gnu=$(AR)

Discussion:
Appears like: Essentially, 'LINK_foo' is empty. Heres a list:
I think this is your issue. (I ran into it myself while doing a build)
Dup of , apparently.
I believe this will be fixed by
Closing as a duplicate.
Change:
<ins> error: `extern` block uses type `impl Baz`, which is not FFI-safe --> $DIR/lint-ctypes-73251-1.rs:21:25 | LL |     pub fn lint_me() -> <u32 as Foo>::Assoc; |                         ^^^^^^^^^^^^^^^^^^^ not FFI-safe | note: the lint level is defined here --> $DIR/lint-ctypes-73251-1.rs:2:9 | LL | #![deny(improper_ctypes)] |         ^^^^^^^^^^^^^^^ = note: opaque types have no C equivalent error: aborting due to previous error </ins>

Discussion:
cc Gives the following incorrect warning:
I'm not sure if this is incorrect - I think this is what I'd expect. In the declaration of , we don't know what concrete type is - if it were , then we could normalize to - but we don't know? Maybe I'm missing something.
Hmm, that might be true. I definitely think that the following should not lint here (with bound to u32)
I agree that seems like it should be fine. So, this happens because of this call: It makes sense that we want to lint on opaque types on extern declarations, it's unclear whether we would want to allow projections which contain opaque types - this would solve the case you've shown here, but could be used to "sneak" opaque types by the lint (in , the projection normalizes to an opaque type; it's hard to detect because the normalization goes further and resolves it to so we can't tell that it was an opaque type) - I have a build with this locally. Any thoughts on whether we should change the behavior here? cc
Hm, I think it might be worth it to normalize using here, which should not normalize the first case and your example while fixing the second one if I am not mistaken.
Long ago I filed where we also concluded Reveal::UserFacing is the right behavior for normalization in this lint. The current behavior comes from cc
I'll put up a PR with my experiments from last night later in that case.
Change:
#[rustc_const_unstable(feature = "const_ascii_ctype_on_intrinsics", issue = "68983")] #[inline] pub const fn is_ascii_uppercase(&self) -> bool { <del> self.is_ascii() && (*self as u8).is_ascii_uppercase() </del> <ins> match *self { 'A'..='Z' => true, _ => false, } </ins> } /// Checks if the value is an ASCII lowercase character:

Discussion:
I noticed this check: and wondered why it's there. Then someone told me it's there because of the . If you pass a non-ASCII char, the would corrupt that char. That's why the check is there before it. But then I wondered: why isn't this just cast to a bigger data type that includes all Unicode code points? This method (and others) are slower than they have to be. Also see this discussion in Discord with more valuable information:
(I can’t seem to find the relevant part in the middle of this discord stream…) I’m not sure what you mean by “corrupt”. is well defined: it takes the numerical value of the code point (same as ), then truncates to keep the lower 8 bits. equals 0x41, but so does . We want to reject the latter since U+1F041 is not an ASCII upper-case letter. If is implemented in terms of , the ASCII range check is necessary. (It could be a range check to, for example with .) But maybe doesn’t need to be implemented in terms of . Maybe it could duplicate the logic instead. Once upon a time was implemented with a lookup table of 256 entries. A flat lookup table for all of Unicode would be way too big. But these days it’s based on matching a range pattern. Doing the same with a range pattern could also work. That said, would it actually be faster? Maybe the optimizer already does its job well. If you want to work on this, consider adding some benchmark to show that code duplication is worth it.
Oh it seems the Discord link is a bit buggy. Try searching for in the search bar on the Discord server. Then you should get to my message with the discussion below it. One guy also posted this comparison of the instructions generated:
I think the minimal standard here should be a benchmark before we change the implementation. Can you provide that?
I'm not that experienced with Rust yet, sorry. I just wanted to point out this possible performance regression. Shouldn't the instruction amount difference as shown on Godbolt suffice to know that it's slower? vs.
Looking at the assembly, it seems that the problem is the check. These three functions produce : So, it seems that the check is unnecessary. I could make a PR for this.

Here are some benchmarks: So it seems that removing the check has a measurable performance difference.
is incorrect. The conversion should happen not for the ASCII check but for the , and the pattern use byte literals like . (Though I expect this won’t affect results much.)
Change:
feature(slice_index_methods, coerce_unsized, sgx_platform) )] #![deny(rustc::existing_doc_keyword)] <del> #![cfg_attr(all(test, target_vendor = "fortanix", target_env = "sgx"), feature(fixed_size_array))] </del> // std is implemented with unstable features, many of which are internal // compiler details that will never be stable // NB: the following list is sorted to minimize merge conflicts.

Discussion:
This is a tracking issue for the unstable feature in the standard library. This is likely to be deprecated and removed in favor of generic integers one day, and in the meantime there are not many consumers of it.
Note that the feature specifically covers the trait. There's some other code in core::array, but it's all implicitly stable.
The FixedSizeArray trait would be great, except for many uses the ranges of sizes it's implemented for simply isn't what you need, and there is no way to expand it. Thus it is mostly useless in the current form.
Could the compiler magically have an "infinite" (generated on demand) number of impls of ? If that happens and the type parameter is made into an associated type (and maybe an associated const for the size is ), then most of the other impls that currently only go up to N=32 could be made generic .
If/when the issue of using associated consts like consts is resolved, that is, allow to compile; then an infinite number of FixedSizeArray impls would give us the same thing as generic integer parameters. This suggests to me that completing associated constants is basically the same problem as allowing generic integer parameters.
for now could be moved to a crate since it doesn't use any compiler magic anyway
has a similar trait, called :
Triage: no changes
Something did change in this trait is now implemented for all sizes: The trait is also unstable:
I wrote about extending and stabilizing this trait.
This trait isn't used anywhere and doesn't seem to be needed any more now that we have const generics. fcp close
Team member has proposed to close this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to close, 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.
Change:
<del> #![cfg_attr(feature = "optimize_for_size", allow(dead_code))] </del> <ins> #![cfg_attr(any(feature = "optimize_for_size", target_pointer_width = "16"), allow(dead_code))] </ins> use crate::marker::Freeze;

Discussion:
Run Or And you'll get this diagnostic (cargo miri setup makes it a warning, lol): I don't know what effect this has at runtime but it can't be good.
It's worse than one might think, because many AVR microarchitectures, including the atmega328 we nominally support, have only 2KiB of SRAM, which means that this line is literally impossible:
these targets should probably use some of the code in with perhaps a few more tweaks.
Good to know, 16-bit wasn't something we had in mind during development, in terms of less standard targets, we did test big endian with miri. I agree with the code in would be a better fit for such targets. What kind of tweaks did you have in mind?
There are other places in driftsort and ipnsort that use stack arrays, e.g: They are all size bound to <= 4KiB through various means, but still a poor fit for tiny chips.
I think that's necessary, I don't believe driftsort could ever meaningfully run on machines this small.
You already figured it out: dropping all the stack arrays to the absolute minimum. Note that you are not obligated to fix these targets, as usual.
I think it should be a single additional in the impl, so I don't mind doing it.
Yeah, we'd get CI failures way too often if we errored on warnings for tier 3 targets.
Related:
Who is using Tier 3 targets in CI?
Miri is, by running a test with . We should probably change that.
Thinking a bit more about it, is there any scenario where you'd compile Rust for 16-bit targets and don't want to use ? Independent of sort. I'd think that such targets are always binary-size limited and welcome any reduction of it.
Change:
<ins> // > Suggest `return`ing tail expressions that match return type // > // > Some newcomers are confused by the behavior of tail expressions, // > interpreting that "leaving out the `;` makes it the return value". // > To help them go in the right direction, suggest using `return` instead // > when applicable. // (original commit description for this test) // // This test was amended to also serve as a regression test for #92308, where // this suggestion would not trigger with async functions. // // edition:2018 </ins> fn main() { let _ = foo(true); }

Discussion:
Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like it does for the : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-async-await +D-papercut
I'm gonna try and take a shot at this. claim
Thanks for putting up a PR so quickly, label +AsyncAwait-Triaged +AsyncAwait-Polish
Change:
} } <ins> fn expand_noop_attribute(_cx: &mut ExtCtxt, _sp: Span, _attr: &MetaItem, it: Annotatable) -> Annotatable { it } </ins> // Create a duplicate of the annotatable, based on the MetaItem fn expand_duplicate(cx: &mut ExtCtxt, _sp: Span,

Discussion:
Hi! I'm trying to compile my Rocket/Diesel/R2d2 task management project, which has previously successfully compiled, and when I add the newest piece which relies on macros in some new/different way (sorry for vague, I'm new to rust) it starts failing to compile. Looking at the backtrace, the error seems to be in MacroExpander::expandinvoc. I expect it to have the same behavior as the simpler version of the route: which warns about unused query result on compile but successfully runs, builds the NewTask struct from url components, and inserts it into the database. it fails to compile during cargo run, and the same exact error shows during cargo check. I've pasted the whole command with outputs here: Check out my project's for the exact code where I get the bug. Check out my project's master branch at commit to see the functional version (requires a local postgresql instance and a DATABASEURL env variable in a env file).
I minimized down to nothing but 14 looping macros in order to squarely place the blame on a single culprit once and for all: A function that just loops surely cannot be responsible for dropping a , so the must be a bug in rustc. (I still rather doubt it is in though, but rather, in a function that gets inlined into it)
So... I mentioned in the other issue how terrifying of a concept I thought was. For the uninitiated, is a type alias for a with a in its variant, which acts like a ticking timebomb; it explodes if the error is ever dropped. Simply put, has some methods that you must never call on a . Do you see it? :wink:
Ha! Thank you for the digging That stray is really cheeky, ain't it?
I'll probably submit a PR; I'm just browsing around the existing test cases for plugins trying to glean "best practices." (I'm also trying to see if there's any test case that causes the other in the branch to blow up. I don't think there is since it appears that the full attribute gets parsed before it tries to expand .)
Change:
MIRI_TEST_TARGET=i686-pc-windows-gnu run_tests MIRI_TEST_TARGET=x86_64-unknown-freebsd run_tests_minimal hello integer vec panic/panic concurrency/simple atomic data_race env/var MIRI_TEST_TARGET=aarch64-linux-android run_tests_minimal hello integer vec panic/panic <del> MIRI_TEST_TARGET=wasm32-wasi run_tests_minimal no_std integer strings MIRI_TEST_TARGET=wasm32-unknown-unknown run_tests_minimal no_std integer strings </del> <ins> MIRI_TEST_TARGET=wasm32-wasi run_tests_minimal no_std integer strings wasm MIRI_TEST_TARGET=wasm32-unknown-unknown run_tests_minimal no_std integer strings wasm </ins> MIRI_TEST_TARGET=thumbv7em-none-eabihf run_tests_minimal no_std # no_std embedded architecture MIRI_TEST_TARGET=tests/avr.json MIRI_NO_STD=1 run_tests_minimal no_std # JSON target file ;;

Discussion:
I tried this code on 1.73: Compiled it with , I expected it to compile fine as on previous 1.72.1, but it gave me these errors: It most recently worked on: 1.72.1 Output: : I read release notes for 1.73 and couldn't find anything that could be related to this, also tried to search for an existing issue about this - no luck. This issue also broke compilation of crate and transitively, Fyrox game engine.
Bisected to . cc
And then this was fixed by (or at least it started compiling since)
Hm, why does it think that the function requires that target feature? That function doesn't have any attribute... Cc
Ah, that's what changed in -- that from a bunch of functions. This was changed in Cc
That was changed in stdarch specifically in response to , to avoid breaking users who were using the already.
In principle we could probably silence this check on wasm, since we document wasm to be a target where calling functions with unsupported target features is safe.
What happens in wasm when you call a function that requires an unavailable target feature?
I am told that the wasm runtime will refuse to even load a module that contains invalid operations, so there are two options: the generated code makes no use of the target feature, and so everything just works the generated code makes use of the target feature, and we don't even ever get to the function call since loading the wasm module already failed
can you check on of the latest nightlies to verify if it works for you? (ref. )
We have a special exception for wasm that allows targetfeature functions to not be marked unsafe: We should probably have the same exception in the target-feature check in the interpreter. do you have the time for a follow-up PR implementing that?
I re-checked on latest nightly and seems to work fine:
I will do that
WG-prioritization assigning priority (). Issue is fixed on nightly+beta, leaving open to follow PR fixing label -I-prioritize +P-medium
In which version this fix will be included?
Should land in stable 1.74 (around mid November), iiuc. See or an
Change:
} if check_implied_wf == CheckImpliedWfMode::Check && !(impl_sig, trait_sig).references_error() { <ins> // Select obligations to make progress on inference before processing // the wf obligation below. // FIXME(-Ztrait-solver=next): Not needed when the hack below is removed. let errors = ocx.select_where_possible(); if !errors.is_empty() { let reported = infcx.err_ctxt().report_fulfillment_errors(&errors); return Err(reported); } </ins> // See #108544. Annoying, we can end up in cases where, because of winnowing, // we pick param env candidates over a more general impl, leading to more // stricter lifetime requirements than we would otherwise need. This can

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. --This code compiles on the and channels, but crashes with an ICE on the channel. : (Backtrace omitted) .. And so on for , , etc. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized (from the chumsky crate) to: or (from the above) to: Bisected with v0.6.6 to , which is and that PR does look like it's in the right area to have caused this.
Change:
/// Creates a new iterator that produces an infinite sequence of /// repeated applications of the given function `f`. #[allow(visible_private_types)] <del> pub fn iterate<'a, T: Clone>(f: |T|: 'a -> T, seed: T) -> Iterate<'a, T> { </del> <ins> pub fn iterate<'a, T: Clone>(seed: T, f: |T|: 'a -> T) -> Iterate<'a, T> { </ins> Unfold::new((f, Some(seed), true), |st| { let &(ref mut f, ref mut val, ref mut first) = st; if *first {

Discussion:
It's currently but the convention is (and it is more readable) to have the closure last, i.e. .
Change:
return true; } // Normalize projections and things like that. <del> let src = self.tcx.normalize_erasing_regions(self.param_env, src); let dest = self.tcx.normalize_erasing_regions(self.param_env, dest); </del> <ins> // FIXME: We need to reveal_all, as some optimizations change types in ways // that require unfolding opaque types. let param_env = self.param_env.with_reveal_all_normalized(self.tcx); let src = self.tcx.normalize_erasing_regions(param_env, src); let dest = self.tcx.normalize_erasing_regions(param_env, dest); </ins> // Type-changing assignments can happen when subtyping is used. While // all normal lifetimes are erased, higher-ranked types with their // late-bound lifetimes are still around and can lead to type // differences. So we compare ignoring lifetimes. <del> equal_up_to_regions(self.tcx, self.param_env, src, dest) </del> <ins> equal_up_to_regions(self.tcx, param_env, src, dest) </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. --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> // Same as rustc's `tests/ui/async-await/async-closures/captures.rs`, keep in sync #![feature(async_closure, noop_waker)] use std::future::Future; use std::pin::pin; use std::task::*; pub fn block_on<T>(fut: impl Future<Output = T>) -> T { let mut fut = pin!(fut); let ctx = &mut Context::from_waker(Waker::noop()); loop { match fut.as_mut().poll(ctx) { Poll::Pending => {} Poll::Ready(t) => break t, } } } fn main() { block_on(async_main()); } async fn call<T>(f: &impl async Fn() -> T) -> T { f().await } async fn call_once<T>(f: impl async FnOnce() -> T) -> T { f().await } #[derive(Debug)] #[allow(unused)] struct Hello(i32); async fn async_main() { // Capture something by-ref { let x = Hello(0); let c = async || { println!("{x:?}"); }; call(&c).await; call_once(c).await; let x = &Hello(1); let c = async || { println!("{x:?}"); }; call(&c).await; call_once(c).await; } // Capture something and consume it (force to `AsyncFnOnce`) { let x = Hello(2); let c = async || { println!("{x:?}"); drop(x); }; call_once(c).await; } // Capture something with `move`, don't consume it { let x = Hello(3); let c = async move || { println!("{x:?}"); }; call(&c).await; call_once(c).await; let x = &Hello(4); let c = async move || { println!("{x:?}"); }; call(&c).await; call_once(c).await; } // Capture something with `move`, also consume it (so `AsyncFnOnce`) { let x = Hello(5); let c = async move || { println!("{x:?}"); drop(x); }; call_once(c).await; } } </ins>

Discussion:
Something is still wrong w/ async call shims. I think I'm not doing the transform correctly or something. Putting this up so I don't forget about it, but I'll fix it.
ohhhhh lol it's drop glue. Huh.
Oh hell yes this is actually totally wrong wtf: