jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0658]: const closures are experimental --> $DIR/ice-112822-expected-type-for-param.rs:4:5 | LL |     const move || { |     ^^^^^ | = note: see issue #106003 <https://github.com/rust-lang/rust/issues/106003> for more information = help: add `#![feature(const_closures)]` to the crate attributes to enable error: ~const can only be applied to `#[const_trait]` traits --> $DIR/ice-112822-expected-type-for-param.rs:3:32 | LL | const fn test() -> impl ~const Fn() { |                                ^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0658`. </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
Regression in nightly-2023-02-05 Regression in cc
Fixed on the latest nightly, marking as E-needs-test labels: +E-needs-test
I don't think this is actually fixed, just that the ICE cannot be triggered currently, but might resurface when the effects feature is fully implemented.
Change:
extern_prelude.insert(Ident::with_dummy_span(sym::core), Default::default()); if !session.contains_name(&krate.attrs, sym::no_std) { extern_prelude.insert(Ident::with_dummy_span(sym::std), Default::default()); <del> if session.rust_2018() { extern_prelude.insert(Ident::with_dummy_span(sym::meta), Default::default()); } </del> } }

Discussion:
Taken from this internals thread: A module named is shadowed leading to misleading error messages. was reserved as a built-in crate name in 2018 edition, but the error message does not indicate this. I tried this code: Above code compiled with This is expected to indicated that is a reserved crate name. Instead, the following error is reported: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Error: Parsing assign command in failed: ...'tbot claim' ' ?'... Please let know if you're having trouble with this bot.
claim
It's not forbidden as a module name, this obviously works: I think the confusion arises from that fact that this works without : But those are uniform imports (or at least I think that's what they're called), and only resolve to the surrounding scope if unambiguous (which it is for due to the. I'm guessing the right fix here is to add more information to the error suggesting that if the intention wasn't to refer to a crate, or etc. should/can be used explicitly. (EDIT: I went to the internals thread to reply, and it's from March 2019 apparently, and also was mentioned there, but I guess the fact that the name is perfectly fine outside of wasn't brought up) cc
I believe the "fix" was mentioned in a reddit thread linking to the internals thread, but I forgot to mention it. I will reword the issue as it is misworded, as you pointed out. Lastly, what you suggested for a fix lines up with what I was expecting. Also, now you know how deep my backlog of todo items is.
Change:
let mut opaque_types = self.opaque_types.borrow_mut(); for (ty, decl) in opaque_type_map { <del> let old_value = opaque_types.insert(ty, decl); assert!(old_value.is_none(), "instantiated twice: {:?}/{:?}", ty, decl); </del> <ins> let _ = opaque_types.insert(ty, decl); </ins> } value

Discussion:
Version: The second function call is necessary. It will compile and run just fine with only one call. Output:
This may be irrelevant to async-await, as we can replace with any trait and still reproduces:
Change:
// SAFETY: the check above ensured that the count used to be non-zero, // so element hasn't been dropped yet, and we just lowered the count to // zero so it won't be dropped later, and thus it's okay to take it here. <del> unsafe { ManuallyDrop::take(&mut self.element) } </del> <ins> unsafe { mem::replace(&mut self.element, MaybeUninit::uninit()).assume_init() } </ins> } else { <del> A::clone(&self.element) </del> <ins> // SAFETY: the count is non-zero, so it must have not been dropped yet. let element = unsafe { self.element.assume_init_ref() }; A::clone(element) </ins> } } }

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --This is technically different from as there's no UAF. However, using with has undefined behavior if you use the last/original element after moving the iterator, since the field has noalias properties. <details<summaryMiri Backtrace</summary<p</p</detailsWrapping the element using (or once we have that) should make this sound.
See also:
The minimal example is actually this: Because eagerly calls drop for . This basically boils down to Which is indeed I quite strongly think that this is a bug in miri and/or ( should use inside of itself probably?). That being said this is not yet decided (again, see the UCG issue) :/
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Yeah, it should -- someone just has to implement first. ;) See
I tweaked the title because while there is an experimental Miri flag to make Unique magical, codegen only has special treatment for Box.

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --currently unconditionally derives . However, it will also drop its inner object if is 0, which can cause a UAF if it's cloned afterwards. Running the above program segfaults: Edit: Made the segfault quicker/more reliable.
same issue with its implementation
cc I think you implemented this. ^^
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
--> $DIR/simple-defaults.rs:8:40 | LL | struct FixedOutput<'a, const N: usize, T=u32> { <del> |                   ---------------------^----- help: reorder the parameters: lifetimes, then types, then consts: `<'a, T, const N: usize>` </del> <ins> |                   ---------------------^----- help: reorder the parameters: lifetimes, then types, then consts: `<'a, T = u32, const N: usize>` </ins> error: aborting due to previous error

Discussion:
results in: when it should be: This should be easy to fix: just replace in the following line with an appropriate format string. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
For the record, it's not quite this simple, as doing so results in incorrect output when the parameter also has bounds. For example, it would render as because bounds are printed after the
Change:
<ins> //@ aux-build:block-on.rs //@ edition: 2021 //@ build-pass //@ compile-flags: -Cdebuginfo=2 #![feature(async_closure)] extern crate block_on; async fn call_once(f: impl async FnOnce()) { f().await; } pub fn main() { block_on::block_on(async { let async_closure = async move || {}; call_once(async_closure).await; }); } </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
Change:
<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // no-prefer-dynamic // check that having extern "C" functions in a proc macro doesn't crash. #![crate_type="proc-macro"] #![allow(non_snake_case)] extern crate proc_macro; macro_rules! proc_macro_tokenstream { () => { ::proc_macro::TokenStream }; } macro_rules! proc_macro_expr_impl { ($( $( #[$attr:meta] )* pub fn $func:ident($input:ident: &str) -> String $body:block )+) => { $( // Parses an input that looks like: // // ``` // #[allow(unused)] // enum ProcMacroHack { //     Input = (stringify!(ARGS), 0).1, // } // ``` $( #[$attr] )* #[proc_macro_derive($func)] pub fn $func(input: proc_macro_tokenstream!()) -> proc_macro_tokenstream!() { unsafe { rust_dbg_extern_identity_u64(0); } panic!() } )+ }; } proc_macro_expr_impl! { pub fn base2_impl(input: &str) -> String { panic!() } } #[link(name="rust_test_helpers")] extern "C" { pub fn rust_dbg_extern_identity_u64(v: u64) -> u64; } </ins>

Discussion:
: : Steps to reproduce: This is failing when the crate attempts to import the crate (which is a crate). That is, if I modify 's file to only contain: rustc will ICE. <details<summaryBacktrace:</summary</details
I suspect this is a duplicate of , but I only count 2 #[procmacro] and 1 #[procmacro_attribute] in the repository.
The crate only has 1 and 1 . If I comment both of them out, the compiler still ICEs. The crate used to compile a couple weeks ago, so this was a fairly recent change.
To give some bounds on this: the crate compiles with . It fails with . I would bisect this with rustup to determine which nightly the issue started with, but .
Derp, I just remembered I could remove the component. Okay, doing that, I was able to bisect the nightlies: Last working version: First failing version:
I just did a git bisect, and it looks like commit (from PR ) is the source of the breakage. cc
visited for triage. Going to try to followup with . Assigning to self to keep myself honest about that claim.
also, P-high
Am looking at this.
Minified: // #[allow(unused)] // enum ProcMacroHack { // Input = (stringify!(ARGS), 0).1, // } // The problem is caused by containing "host" defids and being used in [trans]. I don't think that this field has any business containing host libraries when compiling a proc macro, but I'll ask for confirmation. [trans]:
visited for triage. Seems like PR handles this. Leaving as P-high
Change:
<ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash pub struct Tuple; pub trait Trait<const I: usize> { type Input: From<<Self as Trait<I>>::Input>; } fn main() {} </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 was writing some generic code over vectors using the under-construction feature of const generics, and had a circular chain of super-traits that required me to cast the Self type to the trait as can be seen in the supertrait requirement. I believe that is causing the MIR error. I think this may be related to but it is subtly different so I'm putting the issue up regardless. <!-- 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. --: I updated my rust version on nightly right before I ran this so hopefully it is up to date: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimized: claim
Looks like maybe constants in trait paths don't get their type correctly? cc
Initially I thought this was about bounds but no, this also fails: ()
I believe this code is responsible: And the problem is that this doesn't handle associated types which need the same treatment:
Alternatively, instead of using to get the , maybe we could use the olution from the segment we found the const parameter in? I believe nowadays we have per-segment resolutions, which would avoid breaking GATs in the future. Actually, I expect is also broken, let's try it... Yupp: () EDIT: took a second look and that is in a , which has to be resolved by the body of , which means it's as bad as the method call form (which I just ). Maybe we should disallow passing explicit generic args to methods for now? Since I have no idea how one would figure out the expected type.
If you look at this later btw, my comment above () still isn't addressed, but I haven't made an issue yet about it.
Change:
// https://github.com/llvm-mirror/libcxx/blob/release_35/src/condition_variable.cpp#L46 // https://github.com/llvm-mirror/libcxx/blob/release_35/include/__mutex_base#L367 #[cfg(any(target_os = "macos", target_os = "ios", target_os = "android"))] <del> pub unsafe fn wait_timeout(&self, mutex: &Mutex, dur: Duration) -> bool { </del> <ins> pub unsafe fn wait_timeout(&self, mutex: &Mutex, mut dur: Duration) -> bool { </ins> use ptr; use time::Instant; <ins> // 1000 years let max_dur = Duration::from_secs(1000 * 365 * 86400); if dur > max_dur { // OSX implementation of `pthread_cond_timedwait` is buggy // with super long durations. When duration is greater than // 0x100_0000_0000_0000 seconds, `pthread_cond_timedwait` // in macOS Sierra return error 316. // // This program demonstrates the issue: // https://gist.github.com/stepancheg/198db4623a20aad2ad7cddb8fda4a63c // // To work around this issue, and possible bugs of other OSes, timeout // is clamped to 1000 years, which is allowable per the API of `wait_timeout` // because of spurious wakeups. dur = max_dur; } </ins> // First, figure out what time it currently is, in both system and // stable time.  pthread_cond_timedwait uses system time, but we want to // report timeout based on stable time.

Discussion:
I have encountered what I think is unexpected behavior from on OSX: when called with "large" values the call will return immediately, instead of waiting for an call. What constitutes "large" is variable, and appears to correspond to the current value in the system monotonic clock source. The following code reproduces the issue: If you run the code above with the "small" value uncommented the internal loop only runs once, waiting for the 1-second sleep to expire before is called. But if you run with the "large" value uncommented, the internal loop runs a very large number of times as each call to returns almost immediately. As noted above, the actual value of "large" decreases over time, I believe based on . I unfortunately couldn't come up with a way to prove this is the case. I've seen this behavior on OSX Yosemite and Sierra. Edit: this happens on 1.11, 1.12, beta, and nightly.
This is likely related to the implementation using unchecked arithmetic and something overflowing. I'll tweak it to much Linux and test out to make sure it works.
Hm no that's correctly handling overflow... Hmm...
Fixed by
Change:
// for the current implementation of the standard library. let mut group_end = None; let mut group_start = None; <del> let mut end_with = FxHashSet::default(); </del> <ins> // Crates available for linking thus far. let mut available = FxHashSet::default(); // Crates required to satisfy dependencies discovered so far. let mut required = FxHashSet::default(); </ins> let info = &codegen_results.crate_info; for &(cnum, _) in deps.iter().rev() { if let Some(missing) = info.missing_lang_items.get(&cnum) { <del> end_with.extend(missing.iter().cloned()); if !end_with.is_empty() && group_end.is_none() { group_end = Some(cnum); } </del> <ins> let missing_crates = missing.iter().map(|i| info.lang_item_to_crate.get(i).copied()); required.extend(missing_crates); } required.insert(Some(cnum)); available.insert(Some(cnum)); if required.len() > available.len() && group_end.is_none() { group_end = Some(cnum); </ins> } <del> end_with.retain(|item| info.lang_item_to_crate.get(item) != Some(&cnum)); if end_with.is_empty() && group_end.is_some() { </del> <ins> if required.len() == available.len() && group_end.is_some() { </ins> group_start = Some(cnum); break; }

Discussion:
Compiling following under some circumstances result in undefined references to : This linking issue occurs only under for some codegen partitioning but not the others. Reproducing it requires controlling the options that influence the number of codegen units. I can reproduce it with either , or combined with . The weak lang items introduce cyclic dependencies between crates. For example, the alloc crate depends on oom lang item which is defined in std. When linking the std comes first, and it may so happen that object file that contains definition is not used and omitted (this suggest why large number of codegen units is necessary to reproduce the issue), and subsequently alloc crate will fail to link. The [linking code][0] tries to account for cyclic dependencies using start-group and end-group, but as far as I can see it based on assumption that weak lang items dependencies are always reversed, which no longer holds true. [0]:
Change:
<ins> // check-pass const _: () = core::mem::forget(Box::<u32>::default); const _: () = core::mem::forget(|| Box::<u32>::default()); fn main() {} </ins>

Discussion:
<!-- 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: () I expected to see this happen: Successful compilation Instead, this happened: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.65.0 <!-- Provide the version you are using that has the regression. --: modify labels: +regression-from-stable-to-beta -regression-untriaged
This became an error due to ( <details<summaryBisect info</summarysearched nightlies: from nightly-2022-09-18 to nightly-2022-11-07 regressed nightly: nightly-2022-09-23 searched commit range: regressed commit: bisected with <a href=''cargo-bisect-rustc</av0.6.4 Host triple: I used on the following file </details
Assigning priority as by the Prioritization Working Group.
awaiting beta backport
Can this be closed now that beta backport () is complete?
Change:
); write_sidebar_links(out, blanket_format); } <del> if let Some(impl_) = v .iter() .filter(|i| i.inner_impl().trait_.is_some()) .find(|i| i.inner_impl().trait_.def_id_full(cache) == cx.cache.deref_trait_did) { sidebar_deref_methods(cx, out, impl_, v); } </del> } } }

Discussion:
Steps to reproduce: down the sidebar looking for "Methods from Deref&lt;...&gt;" Expected result: Methods from Deref section comes immediately after Methods. Actual result: Methods from Deref section comes below Trait Implementations, Auto Trait Implementations, and Blanket Implementations. Compare vs , which has the correct ordering.
Ah, looks like this was intentional in , after conversation in . Removing C-bug and regression-from-stable-to-beta. Keeping this open as a discussion issue: I think putting "Methods from Deref" further down than trait implementations is wrong for String, because so many of its important methods are on . I'd like to either reconsider or find some way to make this work nicely for String. Vec is probably in the same boat, with its .
I'd like to voice that I also think this is a kind of regression. 99% of the time I go to a type's page, I'm looking for methods, not traits; I've gotten used to seeing 's methods directly under s, and it feels like a mistake moving away from this.
what do you think of reverting while we look for a better solution. From : The problem with this is sometimes the "Methods from Deref" section refers to a type in the crate. Particularly for and , about half of the most useful methods are on and , respectively. Those are types that are a critical part of the new user learning path, and it's a good user experience for those to be right next to the other methods, both in the sidebar and in the doc. I suspect there are other ways to solve the need expressed in without affecting the page layout of Vec and String in this way.
that's fine - was a response to , which has since been reverted.
FWIW, I originally opened that issue with something more like a directly configurable way of specifying the page layout order for your own crate in mind. I still think that would ultimately be the best solution here. Unsure what the best approach would be, though, as far as top level attribute vs. command-line flag vs. any other way of doing it. Other stuff like what is and isn't "collapsed" by default should probably be configurable also, I'd say.
Change:
.arg("-split-all-cold") // Move jump tables to a separate section .arg("-jump-tables=move") <del> // Use GNU_STACK program header for new segment (workaround for issues with strip/objcopy) .arg("-use-gnu-stack") </del> // Fold functions with identical code .arg("-icf=1") // Update DWARF debug info in the final binary

Discussion:
rustc 1.66.0 requires an executable stack, which is frowned upon for security reasons and for example generally forbidden by SELinux. System: Debian sid (amd64) Execstack allowed: Execstack forbidden: Maybe this is related to PGO or BOLT being enabled? Stack trace:
Can you bisect this using
Clearing the executable stack flag: execstack -c libLLVM-15-rust-1.66.0- seems to work (at least is working correctly as before for the project I'm working on...)
Ran into this today on OpenSuse MicroOS. that workaround works, though I don't understand the ramifications of it.
Probably the library was build on a non-GNU platform (Windows?), so the linker did not add a GNU_STACK program header. (The absence of that header is treated the same as explicitly specifying an executable stack.)
Unfortunately, applying the same workaround on didn't do the trick... The entry in looks like this: Curiously, this works: EDIT: Never mind, I forgot to do a ... :rofl:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
There is no need for reproducing, one can analyze the shared library: should return
The presence of tells the loader to not_ set the stack as executable on legacy systems, so this is an indication of the absence of this bug.
Still seeing this on gentoo/SELinux And no, I don't want to switch off SELinux or enable executable stack system wide. Any ideas? This is a regression as things used to work just fine with older versions of the package...
Since you're on such a system, are you able to use cargo-bisect-rustc to bisect the change? That would be hugely valuable and help actually figuring out what's going on.
Unfortunately no as the system is too resource constraint and I don't have enough RAM to build LLVM from source, hence I'm using the package, and I've tried all currently available versions of it starting from 1.66.1-stable breaks...
You don't need to build anything from source if you have access to rustup. downloads CI artifacts (so it does need internet access). If you can't use it, then it would at least be nice if you could bisect nightlies instead of stables, which are a lot more coarse.

Fedora reproducer: Procedure: Result: Probably cause: Maybe in should include .
cc for that last comment
I don't think that this is caused by missing LLVM linker flags, rather it is caused by BOLT. I used on a BOLT optimized library. When I used the option when optimizing the binary with BOLT, the state of the binary changed from (doesn't require executable stack) to (unknown whether it requires executable stack). Maybe the GNUSTACK attribute confuses SELinux somehow? Perhaps counterintuitively, when is used, the GNUSTACK attribute disappears from the executable.