jiebi/CodeConvo huggingface dataset:
Code change:
/// println!("{:?}", Foo(vec![("A".to_string(), 10), ("B".to_string(), 11)])); /// ``` #[stable(feature = "debug_builders", since = "1.2.0")] <del> #[inline] </del> pub fn debug_map<'b>(&'b mut self) -> DebugMap<'b, 'a> { builders::debug_map_new(self) }

Related discussion:
text: gives: <pre1865 ZN4core3ptr13dropinplace17hffb7ed55089717f8E inlined into 917 ZN50Tascore..convert..FromTGT$4from17h99c56b7d2123957eE inlined into <b677 ZN4core3fmt9Arguments6newv117h0a32116e8ade096aE inlined into</b549 ZN4core3ptr13dropinplace17h8905708a4bea3261E inlined into <b517 ZN4core3fmt9Formatter11debugtuple17h312acfb009988478E inlined into</b484 ZN50Tascore..convert..FromTGT$4from17hf6536c6dc214691bE inlined into 438 ZN5alloc9allocator6Layout4size17h278602cb6317171dE inlined into 402 ZN63alloc..allocator..LayoutasGT$5clone17hba86f6db001903cdE inlined into 381 ZN61u20u20GT$7dealloc17h3db9762b4fdfd21eE inlined into 344 ZN5alloc4heap15exchangemalloc17he9800f033a6330e4E inlined into 341 ZN4core3ptr13dropinplace17hb5325e51b98a161aE inlined into ... <b82 ZN4core3fmt9Formatter12debug_struct17h5cfb920e90696799E inlined into</b... </pre</details<details<summaryrustc --version</summary</details
We should just drop the from those functions - debug printing is something we want to be optimizing on code size/compile time rather than perf.
Yup, that's a good point. EDIT: Actually since they're just generic over lifetimes it looks like that's not an issue.
Code change:
<ins> use std::convert::TryInto; struct S; fn main() { let _: u32 = 5i32.try_into::<32>().unwrap(); //~ ERROR wrong number of const arguments S.f::<0>(); //~ ERROR no method named `f` S::<0>; //~ ERROR  wrong number of const arguments } </ins>

Related discussion:
text: Following code sample causes a compiler panic. should be .
Also happens on nightly. Likely due to const generics changes (cc
Minimal reproduction:
Another case:
Code change:
); } <ins> let is_fn_trait = [ self.tcx.lang_items().fn_trait(), self.tcx.lang_items().fn_mut_trait(), self.tcx.lang_items().fn_once_trait(), ] .contains(&Some(trait_ref.def_id())); let is_target_feature_fn = if let ty::FnDef(def_id, _) = trait_ref.skip_binder().self_ty().kind { !self.tcx.codegen_fn_attrs(def_id).target_features.is_empty() } else { false }; if is_fn_trait && is_target_feature_fn { err.note( "`#[target_feature]` functions do not implement the `Fn` traits", ); } </ins> // Try to report a help message if !trait_ref.has_infer_types_or_consts() && self.predicate_can_apply(obligation.param_env, trait_ref)

Related discussion:
text: (Moved from with an PoC.) The following program () demonstrates how current implementation of allows using a targetfeature from safe code without ensuring it's actually available: This is unsound because it allows executing (e.g.) AVX instructions on CPUs that do not implement them, which is UB. It only works because "safe fns with targetfeatures" are erroneously considered to implement the FnOnce/FnMut/Fn traits.
Proposed resolution: It would probably be better to add the to functions implicitly during lowering to HIR. Implicit is already to functions in blocks in the same way. That would make the unsafety checker the only place (besides AST lowering) where they would be treated specially. Like, "yes, the function is unsafe, but we know that it's safe to call in this specific context, so the unsafe block can be omitted". The special coercion checks would no longer be necessary in that case.
Or perhaps the RFC should be revised to still require writing and only unsafety checker need to be enhanced to allow calling unsafe functions without unsafe blocks in the situations known to be safe. That would be even less magic, which is good, IMO. The ergonomic regression would be minor because would still be not required at call sites.
Good catch. Another option is that referencing, not calling, a target-feature function is unsafe, but I guess that is a bit inconsistent given that this already compiles (): In other words, accessing a safe target feature 1.1 function would be unsafe (unless the target feature is in scope), not just calling it. I think that this is what I would expect somehow, but I would expect it to apply uniformly to both safe and unsafe target feature functions (and that's not an option). The downside of this approach is that we don't know why the function was declared unsafe, not really -- was it only because of the target feature? Or were there additional requirements that would have made it unsafe?
For example, a whole bunch of functions take raw pointers and use them to access memory, so they need to be unsafe even if the respective target feature is enabled in the calling context.
The downside of this approach is that we don't know why the function was declared unsafe, not really -- was it only because of the target feature? Or were there additional requirements that would have made it unsafe? Ah, right, that's a good argument.
Code change:
); } <ins> let is_fn_trait = [ self.tcx.lang_items().fn_trait(), self.tcx.lang_items().fn_mut_trait(), self.tcx.lang_items().fn_once_trait(), ] .contains(&Some(trait_ref.def_id())); let is_target_feature_fn = if let ty::FnDef(def_id, _) = trait_ref.skip_binder().self_ty().kind { !self.tcx.codegen_fn_attrs(def_id).target_features.is_empty() } else { false }; if is_fn_trait && is_target_feature_fn { err.note( "`#[target_feature]` functions do not implement the `Fn` traits", ); } </ins> // Try to report a help message if !trait_ref.has_infer_types_or_consts() && self.predicate_can_apply(obligation.param_env, trait_ref)

Related discussion:
text: The "unsafety checker enhancement" should only affect unsafe functions that are made unsafe through , but not other means (explicit or block).
I'm new to the compiler, but it seemed non-trivial to change functions to unsafe when lowering to HIR. It looks to me like you'd end up with just as many exceptions (ignoring the unsafe in some scenarios), in addition tracking the origin of the . On the other hand it was pretty trivial to not implement the Fn traits instead. I'll open a PR with my fix, but please close it if the other method is preferred.
So there are sort of two questions here. One of them is what user-visible behavior is permitted, and the other is how precisely that is implemented in the compiler. I think the latter only concerns the team in-so-far as it represents the impact on the language spec and on the "mental model" that users must keep in mind. Nominating for the lang-team meeting to discuss solution, which is simply to make "target-feature" functions not implement the traits (just as functions do not implement the traits, along with functions with non-Rust ABIs etc).
I think I was tagged by mistake :wink:
Apologies! Fixed. Github autocompleted that for me. Here I was feeling so grateful to it.
We discussed this in . The conclusion was that the fix that proposed is good for right now. It's already the case that many items do not implement the function trait (e.g., those with custom ABIs or which are unsafe), so this would be "yet another" case (admittedly a somewhat different one in that this case doesn't show up in the type of function pointers, for better or worse). We uncovered a few other interesting observations: pointed out that their ideal preference would be to have something like " only implements " within an unsafe block, but of course the trait system has no precedent for that. It would be sort of like a attached to the impl block (i.e., the impl is usable in some context where unsafe code is allowed). Another possibility might be " only implements within a fn that has a suitable target feature in scope". This is an interesting idea because, although the pointer could escape in the form of a , the idea is that once you enter , you've already demonstrated that you possess the target feature, so it's ok if the value escapes.
Code change:
); } <ins> let is_fn_trait = [ self.tcx.lang_items().fn_trait(), self.tcx.lang_items().fn_mut_trait(), self.tcx.lang_items().fn_once_trait(), ] .contains(&Some(trait_ref.def_id())); let is_target_feature_fn = if let ty::FnDef(def_id, _) = trait_ref.skip_binder().self_ty().kind { !self.tcx.codegen_fn_attrs(def_id).target_features.is_empty() } else { false }; if is_fn_trait && is_target_feature_fn { err.note( "`#[target_feature]` functions do not implement the `Fn` traits", ); } </ins> // Try to report a help message if !trait_ref.has_infer_types_or_consts() && self.predicate_can_apply(obligation.param_env, trait_ref)

Related discussion:
text: (This would be like a clause.) To that end, I was thinking that you could model this last point using closures, but I found that it doesn't work. In particular, gives an error, even if it appears inside of a function annotated with . This seems like something we should discuss, but it's a separate issue. We did discuss briefly whether target features should be part of the type of function pointers but I think the conclusion was 'well maybe but there is already stable code out there that lets you coerce, and it seems rather niche'. We also discussed whether we should permit one to annotate closures with target-feature annotations. In any case, those are things we can address separately from this issue, but the point is that adopting more accepting solutions can be done in the future.
I'm going to move the question of whether closures should "inherit" target features to the main tracking issue -- I'm not sure if that is something that was discussed as part of the original RFC discussion?
Opened to discuss closures.
Code change:
ty ); // Fast path: if this is a primitive simple `==` will work <del> let saw_impl = impl_type == ty; </del> <ins> // NOTE: the `match` is necessary; see #92662. // this allows us to ignore generics because the user input // may not include the generic placeholders // e.g. this allows us to match Foo (user comment) with Foo<T> (actual type) let saw_impl = impl_type == ty || match (impl_type.kind(), ty.kind()) { (ty::Adt(impl_def, _), ty::Adt(ty_def, _)) => { debug!("impl def_id: {:?}, ty def_id: {:?}", impl_def.did, ty_def.did); impl_def.did == ty_def.did } _ => false, }; </ins> if saw_impl { Some(trait_) } else { None } })

Related discussion:
text: <!-- 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. --Example code: docs build successfully on 1.57.0: docs fail to build on 1.59.0-nightly ( 2022-01-04): </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --The generics appear necessary for the bug. Removing them from either the type or the trait resolves the failure. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Probably . searched nightlies: from nightly-2022-01-06 to nightly-2022-01-07 regressed nightly: nightly-2022-01-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: aarch64-apple-darwin Reproduce with: </details
just saw this, I think might be caused by this change: I'm looking into it
claim
Code change:
#[derive(Clone)] enum Enum { <del> Variant1, //~ ERROR: variant is never used </del> <ins> Variant1, //~ ERROR: variant is never constructed </ins> Variant2, }

Related discussion:
text: I was changing some code from integer constants to a proper enum and was greeted by the following warning: The warning sounded weird to me because I was pattern-matching on that damn variant in various places of the code; but I was pointed out to the fact that I wasn't actually creating that value. Maybe the warning should be rewritten to explicitly mention value creation? Cc
cc that looks like your thing
duplicate of
Yup! Closing in favor of that.
Code change:
/// of the type. fn in_any_value_of_ty(_cx: &ConstCx<'_, 'tcx>, _ty: Ty<'tcx>) -> bool; <del> fn in_static(cx: &ConstCx<'_, 'tcx>, def_id: DefId) -> bool { // `mir_const_qualif` does return the qualifs in the final value of a `static`, so we could // use value-based qualification here, but we shouldn't do this without a good reason. Self::in_any_value_of_ty(cx, cx.tcx.type_of(def_id)) } </del> fn in_projection_structurally( cx: &ConstCx<'_, 'tcx>, per_local: &impl Fn(Local) -> bool,

Related discussion:
text: root: gb2260-0.1.1: v. root: imperative - 3 (1 gh, 2 ) detected crates which regressed due to this <detailscommitted-0.1.11: v. imperative-1.0.1: v. epage/committed: v. </detailscc (likely MIR borrowck related, though not the transition itself as that happened last cycle)
Probably a result of the soundness fixes in
This is a change in promotion. cc
Minimized:
Maybe ?
or . No, it's neither of these.
It's , likely .
Code change:
/// with this error. /// /// [`from_utf8_unchecked`]: struct.String.html#method.from_utf8_unchecked <del> /// [`&str`]: ../../std/primitive.str.html </del> <ins> /// [`String`]: struct.String.html </ins> /// [`u8`]: ../../std/primitive.u8.html /// [`Vec<u8>`]: ../../std/vec/struct.Vec.html /// [`str::from_utf8`]: ../../std/str/fn.from_utf8.html <del> /// [`as_bytes`]: struct.String.html#method.as_bytes </del> <ins> /// [`into_bytes`]: struct.String.html#method.into_bytes </ins> /// [`FromUtf8Error`]: struct.FromUtf8Error.html /// [`Err`]: ../../std/result/enum.Result.html#variant.Err #[inline]

Related discussion:
text: This chunk was supposedly copy-pasted as is from It should read A String ([]) is made of bytes
Hi there. Can I pick this up as first-timer task?
Code change:
self.lldb_git_commit_hash = self.git_commit_hash("lldb", "x86_64-unknown-linux-gnu"); self.miri_git_commit_hash = self.git_commit_hash("miri", "x86_64-unknown-linux-gnu"); <ins> self.check_toolstate(); </ins> self.digest_and_sign(); let manifest = self.build_manifest(); self.write_channel_files(&self.rust_release, &manifest);

Related discussion:
text: Looking at https://rust-, it seems like Miri is getting shipped as a rustup component even though the tests fail. Unfortunately, Miri is currently entirely usable, so it'd probably be better if it did not get shipped in this state. Is that something we can do? Cc
maybe we can make the miri toolstate always go to even if it technically is just
what would be the best place to change this? I think I'd prefer Miri not to be shipped at all when the tests fail; I'd rather people stick to an old-but-working Miri than to a new-but-broken one. I found but that does not seem to decide if a component gets built for distribution or not.
seems to suggest that it is supposed to work as you describe that it should be working. Since it obviously doesn't and I can't see how that comment could be true from looking at the source, I'm guessing this is some refactoring fallout. I'll dig a little into git blame
I found it. The comment was for rls in but then the code making the comment true was removed later
See for why this is hard to fix: the builders don't even run the tool tests, so they cannot know if the tests pass. :/ Also, that's probably for the better actually, as the "tools" builder sets --cfg miri to be more Miri-friendly and we don't want that in the release artifacts.
One (crazy?) thing we could so is have the dist builders query the toolstate repo to figure out if the tests are passing...
That will either retrieve an outdated toolstate or will need to block until the toolstate is uploaded ...
Without blocking it would lag behind by 1 merged PR, yes.
would it be possible to add some kind of build assert so Miri fails on builders when Rust internals change too much?
Well builders already know when Miri fails to build because internals change too much. The issue is things that make Miri still compile but break the test suite.
would it be possible to at least change the logic that opens issues such that for Miri, it opens an issue like when the tests fail? I could also try to implement that if you point me to the right place. So far we have had zero cases of Miri tests spuriously failing.
Code change:
self.lldb_git_commit_hash = self.git_commit_hash("lldb", "x86_64-unknown-linux-gnu"); self.miri_git_commit_hash = self.git_commit_hash("miri", "x86_64-unknown-linux-gnu"); <ins> self.check_toolstate(); </ins> self.digest_and_sign(); let manifest = self.build_manifest(); self.write_channel_files(&self.rust_release, &manifest);

Related discussion:
text: That should be easy to do:
Gave it a shot at
had an interesting idea: can't we do the "don't ship broken tools" as part of a post-processing step? We anyway do some little amount of work when a commit hits (as opposed to ), such as actually updating the toolstate repo. So maybe that could also either delete the broken components from the S3 bucket, or else generate a file to be put into the S3 bucket that says which of the components are really there so that the broken ones can be considered "not there"? do you think something like that would be possible?
Thinking about this again, probably the most natural place to do this is in the . That could "just" also check the toolstate database for the commit it is promoting, and then (possibly only for certain tools) not add them to the nightly if their toolstate is not green.
This is biting us again right now, where CI knows that Miri is broken but we ship the component anyway, leading to CI failures in downstream projects that have Miri in their CI.
For another case where this issue got quite painful, see
My PR is because I was incorrectly assuming that all commits have their toolstate recorded in the toolstate repo. Reopening.
FTR, for testing , I downloaded some artifacts: then I edited my : and finally I ran This produces stuff in .
So looks like we have logic in that specifically does not commit to the toolstate repo if nothing changed: Unfortunately, this means that we cannot easily fetch the toolstate of the to-be-produced release in build-manifest, which caused my to fail. Would it be okay for you to change this logic to record the toolstate of all commits in the toolstate repo? Or would you prefer if I try to find another approach for solving this issue? Right now I am somewhat out of ideas though if we cannot even use the toolstate repo to communicate this information.
Wouldn't it be simpler to save list of "good" components to something like and upload it alongside tarballs? Running would show what you need.
I guess we could upload the two JSON files from the two tool runners somehow? Not sure which would be the right places to hook for that, though.
Status: blocked on which is blocked on
This seems to be finally fixed!
Code change:
self.lldb_git_commit_hash = self.git_commit_hash("lldb", "x86_64-unknown-linux-gnu"); self.miri_git_commit_hash = self.git_commit_hash("miri", "x86_64-unknown-linux-gnu"); <ins> self.check_toolstate(); </ins> self.digest_and_sign(); let manifest = self.build_manifest(); self.write_channel_files(&self.rust_release, &manifest);

Related discussion:
text: Today nightly was shipped with , and everything looks normal :tada:
Miri is "test-fail" now, so with the next nightly we should be able to see if indeed it gets removed from rustup as it should.
Confirmed it's working! On miri is missing.
Code change:
} TokenTree::Token(t) => { <del> // Doc comments cannot appear in a matcher. debug_assert!(!matches!(t, Token { kind: DocComment(..), .. })); // If the token matches, we can just advance the parser. Otherwise, this // match hash failed, there is nothing to do, and hopefully another item in // `cur_items` will match. if token_name_eq(&t, token) { </del> <ins> // If it's a doc comment, we just ignore it and move on to the next tt in // the matcher. If the token matches, we can just advance the parser. // Otherwise, this match has failed, there is nothing to do, and hopefully // another item in `cur_items` will match. if matches!(t, Token { kind: DocComment(..), .. }) { item.idx += 1; self.cur_items.push(item); } else if token_name_eq(&t, token) { </ins> item.idx += 1; self.next_items.push(item); }

Related discussion:
text: Cross post from Works fine on stable Rust.
That post is written by me. I've opened a PR , and made some comments there. I'm not an expert on Rust, actually I'm an amateur programmer, and this is what I can do for now.
61.0-nightly ( 2022-03-22) works so this is a very recent nightly regression.
I see that too when compiling
same issue on ubuntu20
Maybe related to this issue. Here is a snippet of macro with on the match side: Pass with rustc 1.61.0-nightly ( 2022-03-22), you can try this snippet via Failed with rustc 1.61.0-nightly ( 2022-03-23), you can try this snippet via , the code can be expanded on playground with: Expand macros in code using the nightly compiler. 61.0-nightly (2022-03-19 )
The piece of code looks surprising, but bisection lead to
Ok, I found it :smile:
Thanks for the report. Should be an easy fix, I will get to it on Monday.
I think is right to some extent. Even in previous Rust version, stuff in the matcher is not so useful and will be ignored like normal comments : With rustc 1.61.0-nightly ( 2022-03-22) or other versions before, the result is: With rustc 1.61.0-nightly ( 2022-03-23), the result is:
Note that the playground's nightly is a few days old and cannot be upgraded because of how this issue affects ring ;-)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
That's an interesting observation! But I'm not a language expert and I never intended to change behaviour in , so I will fix this problem by going back to the old behaviour.
Code change:
}; use rustc_hir::def_id::DefId; use rustc_macros::{LintDiagnostic, Subdiagnostic}; <del> use rustc_middle::ty::{Predicate, Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{PolyExistentialTraitRef, Predicate, Ty, TyCtxt}; </ins> use rustc_session::parse::ParseSess; use rustc_span::{edition::Edition, sym, symbol::Ident, Span, Symbol};

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. --ICE with in I just noticed the error actually says openpgp-card at the bottom, perhaps compilation doesn't even get to the final crate. In any case, I'm no good at minimizing these things, so I'm handing this off to people who are good at that. <!-- 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
searched nightlies: from nightly-2023-01-01 to nightly-2023-01-15 regressed nightly: nightly-2023-01-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This fixes the ICE, although I'm not sure if that's the right approach
label -E-needs-mcve