jiebi/CodeConvo huggingface dataset:
Code change:
struct Wrapper<T>(T); struct Test<T: Copy> { <del> f1: extern "C-cmse-nonsecure-call" fn<U: Copy>(U, u32, u32, u32) -> u64, //~ ERROR cannot find type `U` in this scope //~^ ERROR function pointer types may not have generic parameters </del> <ins> f1: extern "C-cmse-nonsecure-call" fn<U: Copy>(U, u32, u32, u32) -> u64, //~^ ERROR cannot find type `U` in this scope //~| ERROR function pointer types may not have generic parameters </ins> f2: extern "C-cmse-nonsecure-call" fn(impl Copy, u32, u32, u32) -> u64, //~^ ERROR `impl Trait` is not allowed in `fn` pointer parameters f3: extern "C-cmse-nonsecure-call" fn(T, u32, u32, u32) -> u64, //~ ERROR [E0798] f4: extern "C-cmse-nonsecure-call" fn(Wrapper<T>, u32, u32, u32) -> u64, //~ ERROR [E0798] } <ins> type WithReference = extern "C-cmse-nonsecure-call" fn(&usize); trait Trait {} type WithTraitObject = extern "C-cmse-nonsecure-call" fn(&dyn Trait) -> &dyn Trait; //~^ ERROR return value of `"C-cmse-nonsecure-call"` function too large to pass via registers [E0798] type WithStaticTraitObject = extern "C-cmse-nonsecure-call" fn(&'static dyn Trait) -> &'static dyn Trait; //~^ ERROR return value of `"C-cmse-nonsecure-call"` function too large to pass via registers [E0798] #[repr(transparent)] struct WrapperTransparent<'a>(&'a dyn Trait); type WithTransparentTraitObject = extern "C-cmse-nonsecure-call" fn(WrapperTransparent) -> WrapperTransparent; //~^ ERROR return value of `"C-cmse-nonsecure-call"` function too large to pass via registers [E0798] type WithVarArgs = extern "C-cmse-nonsecure-call" fn(u32, ...); //~^ ERROR C-variadic function must have a compatible calling convention, like `C` or `cdecl` [E0045] </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ' has escaping bound vars, so it cannot be wrapped in a dummy binder.'', 'thread 'rustc' panicked at ' has escaping bound vars, so it cannot be wrapped in a dummy binder.'' 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: [issizedraw] computing whether is [layoutof] computing layout of -- label +F-impltraitinassoctype +F-inherentassociated_types
ah lol this regressed in cc
Code change:
Attribute::NoInline.apply_llfn(Function, val); } } <del> None if requires_inline => Attribute::InlineHint.apply_llfn(Function, val), </del> None => {} }; }

Related discussion:
text: Currently, the compiler is allowed to inline naked functions if it wants to. For a normal function, inlining is fine because the compiler can remove the function prologue/epilogue and the remaining will behave as expected. However for naked functions, the developer provides the prologue/epilogue and those aren't removed by the compiler. This almost surely will result in incorrect behavior. Accordingly I think it would make sense for the compiler to not inline naked functions unless the developer explicitly opted-in.
In the other thread, alistair23 found that
Yes, functions should imply .
Code change:
<ins> // Regression test for #89606. Used to ICE. // // check-pass // revisions: twenty_eighteen twenty_twentyone // [twenty_eighteen]compile-flags: --edition 2018 // [twenty_twentyone]compile-flags: --edition 2021 struct S<'a>(Option<&'a mut i32>); fn by_ref(s: &mut S<'_>) { (|| { let S(_o) = s; s.0 = None; })(); } fn by_value(s: S<'_>) { (|| { let S(ref _o) = s; let _g = s.0; })(); } struct V<'a>((Option<&'a mut i32>,)); fn nested(v: &mut V<'_>) { (|| { let V((_o,)) = v; v.0 = (None, ); })(); } fn main() { let mut s = S(None); by_ref(&mut s); by_value(s); let mut v = V((None, )); nested(&mut v); } </ins>

Related discussion:
text: <!-- 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. --This bug popped up in CI on a project of ours. This does not reproduce on stable, but does reproduce on nightly and the latest beta (). Bisection shows that was the first build with the regression. Further bisection points to being the commit that introduced the regression. If I had to guess from the PRs in the rollup I'd say seems the most likely, since it touched the code around the error source. <!-- 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: +regression-from-stable-to-beta
Reduced:
This assertion is indeed introduced in . The two captures have the same place but different CaptureInfo. cc
Interesting. It's a bit hard to imagine how could have introduced this, since that just sorts a list. Fascinating! Maybe somebody from has a clue?
Actually, it's not at all hard to imagine, because introduced the following: The projections are actually the same, but the types differ in regions, which probably means that this comment is wrong:
Yeah, I just checked and the region of the match is an inferenced variable and gives an concrete ReFree instead.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Did some analysis: We cannot just replace the with . This will create two mutable references in edition 2021 and fail borrowck. Pre-2018 the places do get merged later so the issue isn't exposed. None of the upvar code makes use of the region info, and writeback will erase it anyway. So I think the fix should just be have the region erased when inserting/looking up from capture_information. I can submit a PR if you haven't started
I just started looking at it but if you have a solution, go for it!
Code change:
<ins> // Regression test for #89606. Used to ICE. // // check-pass // revisions: twenty_eighteen twenty_twentyone // [twenty_eighteen]compile-flags: --edition 2018 // [twenty_twentyone]compile-flags: --edition 2021 struct S<'a>(Option<&'a mut i32>); fn by_ref(s: &mut S<'_>) { (|| { let S(_o) = s; s.0 = None; })(); } fn by_value(s: S<'_>) { (|| { let S(ref _o) = s; let _g = s.0; })(); } struct V<'a>((Option<&'a mut i32>,)); fn nested(v: &mut V<'_>) { (|| { let V((_o,)) = v; v.0 = (None, ); })(); } fn main() { let mut s = S(None); by_ref(&mut s); by_value(s); let mut v = V((None, )); nested(&mut v); } </ins>

Related discussion:
text: Happy to review your PR
I'm not sure about region code that much but regionchk uses the regions created: I think at one point mentioned getting rid of the region field entirely in UpvarBorrow, but since it wasn't required the discussion didn't proceed. Also it's more like this is a bug of the capture analysis than the sorting. We should never have two same places going into min capture in the list.
I was thinking about erasing the region from s (i.e. the key of captureinformation). But it turns out that's used later to create upvar tuple... So I switched captureinformation from HashMap to a linear vec looked up with custom eq fn instead.
Code change:
use rustc_span::edition::Edition; use rustc_span::lev_distance::find_best_match_for_name; use rustc_span::symbol::{kw, Ident, Symbol}; <del> use rustc_span::{Span, DUMMY_SP}; </del> <ins> use rustc_span::Span; </ins> use rustc_target::spec::abi; use rustc_trait_selection::traits; use rustc_trait_selection::traits::astconv_object_safety_violations;

Related discussion:
text: <!-- 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
This was likely introduced in (CC rustc 1.65 nightly 2022-08-12 emits the following:
Code change:
"anyhow", "cargo", "cargo-util", <del> "cargo_metadata 0.12.0", </del> <ins> "cargo_metadata 0.14.0", </ins> "clippy_lints", "crossbeam-channel", "difference", <del> "env_logger 0.7.1", </del> <ins> "env_logger 0.9.0", </ins> "futures 0.3.12", "heck", "home", <del> "itertools 0.9.0", </del> <ins> "itertools 0.10.1", </ins> "jsonrpc-core", "lazy_static", "log",

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
This might be due to no longer builds: ` We need a new version I think. The last published version of is 5 months old already :thinking: Can you please check why there are no new versions being published?
TIL scheduled GitHub Action Workflows apparently require regular activity in the repository to keep going :eyes:
I didn't realize anyone was still using those crates so I disabled the action, I believe it was broken anyway. Does rustfmt and/or other crates still use those packages? If so I can try to find time to restart the action.
Racer those crates. And RLS . So without those crates compiling racer with the latest nightly isn't possible, which makes compiling RLS impossible and therefore blocks the sync of RLS back to rust-lang/rust.
Would it maybe be an option to make racer depend on to compile instead of publishing AP crates?
We stopped using them in rustfmt a while ago and I can't imagine a scenario where we'd switch back. Agreed on racer, which AIUI is the last true direct consumer of those crates. However, it's also in and those crates only get bumped in racer when a racer consumer needs them to be bumped.
Ah ok. In that case if this is purely for something in maintenance mode I think my own personal tenure in maintaining these crates is over with, so I would prefer to hand over the reins to someone else. Would someone be willing to volunteer to take over these crates?
let's sync up on #t-infra on Zulip -- I think it makes sense to move these crates into infra control/publication.
Let's wait if Racer can move over to rustc-dev racer-rust/racer. If so, there shouldn't be a need to keep maintaining rustc-ap crates at all. Looking at the dependents on , there really is only , the crates themselves and (which by now uses ).
has some relevant considerations as well.
Code change:
"anyhow", "cargo", "cargo-util", <del> "cargo_metadata 0.12.0", </del> <ins> "cargo_metadata 0.14.0", </ins> "clippy_lints", "crossbeam-channel", "difference", <del> "env_logger 0.7.1", </del> <ins> "env_logger 0.9.0", </ins> "futures 0.3.12", "heck", "home", <del> "itertools 0.9.0", </del> <ins> "itertools 0.10.1", </ins> "jsonrpc-core", "lazy_static", "log",

Related discussion:
text: One way or another I think the AP crates need to be accounted for as per the accepted RFC, though it certainly would be a simpler story if they no longer need to be updated/published
Happy to coordinate as necessary, just let me know!
Over a month now. Is this gonna be fixed?
it's blocked on
Code change:
<del> // ignore-tidy-filelength </del> //! Error Reporting Code for the inference engine //! //! Because of the way inference, and in particular region inference,

Related discussion:
text: This issue is a proposal for the deprecation of error code . I opened a PR () as part of an effort to add long error explanations for error codes that didn't have one (). I chose and for my erroneous code example, I used the example from . I quickly realized, through running the example and other code that would also raise and through the CI failure message, that was not being raised. I went back to consult the issue I received the original code example from and noticed comments about not occurring anymore with . The issue was eventually labeled with . But, looking at the current contents of the file, can still be emitted even while it isn't: also doesn't have any UI tests as it is part of the error codes in . Since , is no longer actually emitted (although it is in code that it could) thanks to , I believe it should be deprecated. I would be happy to help deprecate the error code, if it is decided that it should happen. I would just need to know the proper steps to take to deprecate an error code. If there are reasons for why it is still an error code, I would love to be enlightened. claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If is not emitted anymore then it can be removed immediately. A crater run can also be done to ensure that this is the case. I'm also happy to do this if you want.
Sure, that sounds good.
Sorry just for clarification, do you want me to do the PR or you?
Code change:
LLVM_BUILD_DIR= LLVM_INST_DIR=$CFG_LLVM_ROOT do_reconfigure=0 <ins> # Check that LLVm FileCheck is available. Needed for the tests need_cmd $LLVM_INST_DIR/bin/FileCheck </ins> fi if [ ${do_reconfigure} -ne 0 ] then # because git is hilarious, it might have put the module index

Related discussion:
text: Trying to package rust 1.2 into Debian & Ubuntu, I get the following test failures: I am using Debian LLVM 3.6.1 packages (version 3.6.1-1)
is in the package. I wonder whether we want a check in that makes a requirement or one that disables the respective tests if it is not available.
That was indeed the issue. I installed it and I have issue now.
Addressed in
These test should be optional until LLVM has a way to install FileCheck
Code change:
use rustc_infer::infer::{self, InferOk, TyCtxtInferExt}; use rustc_middle::ty; use rustc_middle::ty::error::{ExpectedFound, TypeError}; <del> use rustc_middle::ty::subst::{InternalSubsts, Subst, SubstsRef}; </del> <ins> use rustc_middle::ty::subst::{InternalSubsts, Subst}; </ins> use rustc_middle::ty::util::ExplicitSelf; <del> use rustc_middle::ty::{GenericParamDefKind, ToPredicate, TyCtxt, WithConstness}; </del> <ins> use rustc_middle::ty::{GenericParamDefKind, ToPredicate, TyCtxt}; </ins> use rustc_span::Span; use rustc_trait_selection::traits::error_reporting::InferCtxtExt; use rustc_trait_selection::traits::{self, ObligationCause, ObligationCauseCode, Reveal}; use super::{potentially_plural_count, FnCtxt, Inherited}; <del> use std::iter; </del> /// Checks that a method from an impl conforms to the signature of /// the same method as declared in the trait.

Related discussion:
text: So I had a trait system in my (nightly) code for a while now that utilized specialization, but it no longer seems to be working after a recent update: Now, I haven't been following the development of the specialization feature too closely, so it is possible that this is somehow actually intended and I am missing something. However, given that this previously compiled and ran just fine a couple weeks ago and given that the specialization incomplete warning was only recently, I am inclined to think that it is probably a regression of some sort. compiler version:
Another MVCE (): Regressed in , looks like
cc as far as I can tell this wasn't an intended outcome of the change?
It wasn't really, it was just slightly more complex to have this still work after that PR.
Would you mind describing at a high level what needs to be done?
It looks like the problem stems from the bound predicate not being fully normalized when checking the defaulted associated type. From my reproducer above: which should instead be . I'm not certain yet how this ought to be implemented. Perhaps a pass after normalization that looks for occurrences of the defaulted type ( in this case) and replaces it with the defaulted type. Seems simple enough, in theory :) But maybe there are cases I'm not thinking of.
Code change:
} tcx.sess.track_errors(|| { <del> tcx.sess.time("impl_wf_inference", || { tcx.hir().for_each_module(|module| tcx.ensure().check_mod_impl_wf(module)) }); })?; tcx.sess.track_errors(|| { </del> tcx.sess.time("coherence_checking", || { <ins> // Check impls constrain their parameters tcx.hir().for_each_module(|module| tcx.ensure().check_mod_impl_wf(module)); </ins> for &trait_def_id in tcx.all_local_trait_impls(()).keys() { tcx.ensure().coherent_trait(trait_def_id); }

Related discussion:
text: No response No response No response
(for compiler people:) We could fix this by merging the impl WF and coherence checks into one compiler stage. I'll put up a PR and see what T-types thinks.
labels +AsyncAwait-Triaged We discussed this in a WG-async meeting and are deferring to the resolution suggested above. He noted that this is a fix to the diagnostics only. That fact that this is an error is correct.
Code change:
/// assert!(ptr::eq(ptr, inner.as_ptr())); /// ``` #[inline] <del> #[unstable(feature = "arc_unwrap_or_clone", issue = "93610")] </del> <ins> #[stable(feature = "arc_unwrap_or_clone", since = "CURRENT_RUSTC_VERSION")] </ins> pub fn unwrap_or_clone(this: Self) -> T { Arc::try_unwrap(this).unwrap_or_else(|arc| (*arc).clone()) }

Related discussion:
text: Feature gate: This is a tracking issue for . This feature adds methods to / to gain access to the contained value, by unwrapping if there is exactly one reference, or cloning otherwise. It is equivalent to cloning the inner value, but saves the clone operation if the caller has the only reference to the rc'd value. [x] Implementation: [ ] Final comment period (FCP) [ ] Stabilization PRThere seems to be consensus that the current name is good.
Apologies if this is the wrong place for this comment, feel free to delete. Is there a technical reason why is an associated function and not a method? If I have , I cannot call , but have to resort to which feels unwieldy.
it's because / are 'wrapper types' that implement . A lot of the methods are implemented as associated functions so they don't clash with method names on the . This makes it easier to change between different wrapper types like / etc without suddenly getting a name clash. Apologies if I'm using the wrong terminology but that's the gist of it.
That makes sense. Thanks for the explanation :)
sounds like a bad name to me: has a connotation of potentially panicking code in Rust. The other suggested names in all sound better to me. (Couldn't comment on the thread in IRLO as it has been closed.)
There is precedence for this pattern: for example.
True, I overlooked it.
I think this name is good, and it's easy for me to understand what it means. I'm really looking forward for this to be fcped and stabilized.
At $work we've been using the exact same implementation as the one used in nightly (), it works perfectly well
While I like the proposal very much (for it's convenience), I feel like I want to point out something that might be interesting as well in the future and is related: It's not possible to use where . In this case we have an , which is . However this is a conversion that is also very useful. It would be intersting to go from to . The other way is already possible, but this way is currently not possible, however there are sometimes cases where the count is known and converting back to a Box would be very useful. Consider wanting to remove an element from an for example.
Code change:
/// assert!(ptr::eq(ptr, inner.as_ptr())); /// ``` #[inline] <del> #[unstable(feature = "arc_unwrap_or_clone", issue = "93610")] </del> <ins> #[stable(feature = "arc_unwrap_or_clone", since = "CURRENT_RUSTC_VERSION")] </ins> pub fn unwrap_or_clone(this: Self) -> T { Arc::try_unwrap(this).unwrap_or_else(|arc| (*arc).clone()) }

Related discussion:
text: The current way to do this is to clone the vec, remove an element and make a new Rc, even when an Rc is empty. I understand that there would need to be something like a first, but I just wanted to bring it up, so it's clear that there's potentially more things that could "unwrap" from an Rc.
Try this: The code above will copy vector if needed. (I didn't test the code)
Yes, good point, thanks for bringing it up. However a Vec is unfortunately another layer of indirection. Typically I have something like .
Is there something that still needs to be done before this can go to FCP? I just came across the need for this and noticed that the comments seem positive with confirmation that it works at $work for at least one commenter above, so am wondering what if anything is preventing it moving forward?
Pinging here for input. There seems to be consensus on stabilizing this. Can anyone start an FCP? I'd be happy to work on a stabilization PR (with some guidance)
fcp merge Both of these are already expressible on stable using the following incantation, which is exactly the standard library's implementation too: . The rationale for a dedicated method is that "I need a " is a common enough use case that it's worthwhile to have one easy function prominently available in the type's API doing the thing you most likely want to do in that scenario.
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [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.
and others: is related
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
I believe that can check off the stabilization?
And update the documentation as this seems to have been stabilized.
Code change:
/// assert!(ptr::eq(ptr, inner.as_ptr())); /// ``` #[inline] <del> #[unstable(feature = "arc_unwrap_or_clone", issue = "93610")] </del> <ins> #[stable(feature = "arc_unwrap_or_clone", since = "CURRENT_RUSTC_VERSION")] </ins> pub fn unwrap_or_clone(this: Self) -> T { Arc::try_unwrap(this).unwrap_or_else(|arc| (*arc).clone()) }

Related discussion:
text: I am getting this:
Arc<strstores the string inline on the heap together with the strongcount and weak_count of the Arc. This means it has a different in-memory representation than Box<strand thus can't be converted into a Box<strwithout copying the contents. A Box<strto Arc<strconversion also copies the string contents into the Arc allocation.
I understand that. But moving elements from an Rc to a Vec is different from cloning. The opposite direction is already possible. This means that you can write , but not . I understand that moving is different from . This would probably need to be named something like Vec::frommovedrcorclone`.
GitHub deleted all my angle brackets. I was specifically talking about converting between string types because there's no difference between moving and cloning characters.