jiebi/CodeConvo huggingface dataset:
Change:
/// # Examples /// Consume a number if it's equal to 0. /// ``` <del> /// #![feature(peekable_next_if)] </del> /// let mut iter = (0..5).peekable(); /// // The first item of the iterator is 0; consume it. /// assert_eq!(iter.next_if(|&x| x == 0), Some(0));

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for the feature (). The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implement the RFC [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --- Should be named or ? Should be named or ?
modify labels: T-libs
I don't think the methods should be renamed to something else, becuase also has a method, and should use the same name but with the component. Also, if these questions are resolved and there are no other blockers, I would like to go ahead and stabilize this feature.
Change:
ast::Path { span, segments, tokens: None } } <ins> pub fn macro_call( &self, span: Span, path: ast::Path, delim: ast::token::Delimiter, tokens: ast::tokenstream::TokenStream, ) -> P<ast::MacCall> { P(ast::MacCall { path, args: P(ast::DelimArgs { dspan: ast::tokenstream::DelimSpan { open: span, close: span }, delim, tokens, }), }) } </ins> pub fn ty_mt(&self, ty: P<ast::Ty>, mutbl: ast::Mutability) -> ast::MutTy { ast::MutTy { ty, mutbl } }

Discussion:
In chrono we have support for behind a feature flag. As a workaround for I the line: It now gives a new error: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The derived implementation for an enum is using . Manually implementing and using is a workaround.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
cc
I'm actually not sure this is a T-libs issue. I suspect it's related to , but I haven't had a chance to look into it yet.
I have confirmed this is an issue with the expansion of on s and aim to have a PR up tonight. As is a built-in macro, it is technically in T-compiler land, I believe. claim
PR is up, including a regression test:
Change:
pub fn parallel_guard<R>(f: impl FnOnce(&ParallelGuard) -> R) -> R { let guard = ParallelGuard { panic: Mutex::new(None) }; let ret = f(&guard); <del> if let Some(panic) = guard.panic.into_inner() { </del> <ins> if let Some(IntoDynSyncSend(panic)) = guard.panic.into_inner() { </ins> resume_unwind(panic); } ret

Discussion:
found while checking with When you run the snipped above with , rustc panics, but the exit status is as if there was just a normal compiler error, instead of a . This tripped up automatic ice-reduction that relies on a somewhat familiar exit code when the program crashes :sweat_smile:
is the problematic line here that turns ICEs into "normal" fatal errors that call exit(1) though actually at least with the non parallel compiler i'm very surprised that we're ending up in a query in the first place after panicking.
It seems that current stable does correctly exit with here... I bisected the exit code 101 -exit code 1 change with a crashing file ( ) and got to Regression in nightly-2023-08-31 Regression in cc /
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
ast::ExprVstore(_, ast::ExprVstoreSlice) => { visit::walk_expr(self, e, is_const); } <ins> ast::ExprVstore(_, ast::ExprVstoreMutSlice) => { self.tcx.sess.span_err(e.span, "static items are not allowed to have mutable slices"); }, </ins> ast::ExprUnary(ast::UnBox, _) => { self.tcx.sess.span_err(e.span, "static items are not allowed to have managed pointers");

Discussion:
This line in my project currently causes an unimplemented expression error, told me to submit an issue
Change:
// closely. The idea is that all reachable symbols are live, codes called // from live codes are live, and everything else is dead. <ins> use middle::lint::{allow, contains_lint, DeadCode}; use middle::privacy; </ins> use middle::ty; use middle::typeck; <del> use middle::privacy; use middle::lint::DeadCode; </del> use std::hashmap::HashSet; use syntax::ast; use syntax::ast_map; use syntax::ast_util::{local_def, def_id_of_def, is_local}; <ins> use syntax::attr; </ins> use syntax::codemap; use syntax::parse::token; use syntax::visit::Visitor; use syntax::visit; <ins> pub static DEAD_CODE_LINT_STR: &'static str = "dead_code"; </ins> // Any local node that may call something in its body block should be // explored. For example, if it's a live NodeItem that is a // function, then we should explore its block to check for codes that

Discussion:
Currently if you have some dead_code and you want to preserve it, you have to annotate every function you want to preserve and all the dead code that function calls. I think we should consider annotated code to be alive, and then all the code that touches to be alive as well.
cc sounds like a cool idea to me.
By "annotate", do you mean putting an attribute above the function you want to preserve?
yes.
Change:
self.channel = value.to_string(); } "CFG_PREFIX" => { <del> self.prefix = Some(value.to_string()); </del> <ins> self.prefix = Some(PathBuf::from(value)); </ins> } "CFG_DOCDIR" => { <del> self.docdir = Some(value.to_string()); </del> <ins> self.docdir = Some(PathBuf::from(value)); </ins> } "CFG_LIBDIR" => { <del> self.libdir = Some(value.to_string()); </del> <ins> self.libdir = Some(PathBuf::from(value)); </ins> } "CFG_MANDIR" => { <del> self.mandir = Some(value.to_string()); </del> <ins> self.mandir = Some(PathBuf::from(value)); </ins> } "CFG_LLVM_ROOT" if value.len() > 0 => { let target = self.target_config.entry(self.build.clone())

Discussion:
No destdir is passed to in
That causes fail in Gentoo build
As far as I understand, we need to to pass to function and add value of to prefix here
Change:
Some(Vec<String>), } <del> impl LangString { fn all_false() -> LangString { LangString { </del> <ins> impl Default for LangString { fn default() -> Self { Self { </ins> original: String::new(), should_panic: false, no_run: false, ignore: Ignore::None, <del> rust: true, // NB This used to be `notrust = false` </del> <ins> rust: true, </ins> test_harness: false, compile_fail: false, error_codes: Vec::new(),

Discussion:
is not actually allfalse - will return . It would be nice to rename it to at some point (and maybe add while we're at it). cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I'll either get to it before next week is over or when is merged, whichever comes first
Change:
<ins> // run-rustfix // edition:2018 // Regression test for issue 79694 fn main() { let _ = move async { }; //~ ERROR 7:13: 7:23: the order of `move` and `async` is incorrect } </ins>

Discussion:
I tried this code: This should give a suggestion to reorder the keywords to , something like: Right now it gives this error, which is not very helpful: Tested on 1.48.0 and 1.50.0-nightly (2020-12-03 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Releasing assignment as I'm not really sure how to fix this at the moment. release-assignment
This could be handled directly in the parser code which generates the above diagnostic.
claim
Change:
means that you're calling a macro instead of a normal function. Rust implements `println!` as a macro rather than a function for good reasons, but that's a very advanced topic. You'll learn more when we talk about macros later. One <del> last thing to mention: Rust's macros are significantly different than C macros, </del> <ins> last thing to mention: Rust's macros are significantly different from C macros, </ins> if you've used those. Don't be scared of using macros. We'll get to the details eventually, you'll just have to trust us for now.

Discussion:
There are a number of small typos in the guide, and some of the prose could be tightened up or clarified. In general the tone of the guide comes across as trying too hard to be chatty. Keeping things casual is probably a good idea for Rust's introductory document, but we can probably remove most (all?) of the chatty prose without becoming stodgy or boring.
The guide is inconsistent with its use of certain conventions. These don't really have a correct form, but a single style should be enforced. Single-quotes () versus double-quotes () in prose. Example: Periods and commas within quotes versus without. Example: "different from" versus "different than". Example: "filename" versus "file name"
If you find any obvious errors, or think you can write a section in a better way, please don't hesitate to submit a PR with a fix. You don't need to compile a compiler or download the source to edit the guide. You can do it all in github's ui, for the most part.
thanks for being specific. And for your earlier pull request. As for these... They should be double quotes. Ideally, they'd even be actual curlies rather than . Periods and commas go within in almost all cases. In both of the cases you show, they should go inside. "Different from" vs. "Different than" isn't something that's generally settled. Some styles choose it in different situations, others say "from" is the only correct way to say this. "file name" is my preferred way, though there's no specific actual guidance.
Change:
let (all_types, ret_types) = get_all_types(&generics, &decl, cx); let mut t = TyMethod { header: sig.header, decl, generics, all_types, ret_types }; if t.header.constness == hir::Constness::Const <del> && !is_min_const_fn(cx.tcx, local_did.to_def_id()) </del> <ins> && is_unstable_const_fn(cx.tcx, local_did.to_def_id()).is_some() </ins> { t.header.constness = hir::Constness::NotConst; }

Discussion:
This is a follow-up on I opened earlier, with the requested minimal reproduction in the form of a simple .
Looks like this is either or cc - do you know what those are doing/why they exist?
It's because of the feature. As long as it's not stable, they don't want the keyword to be displayed, even if the function description is describing a const fn. This is a bit strange.
Yeah, that makes no sense to me at all. I have a crate that is very much nightly-only containing a rather large number of s, and at the moment literally none of them are displayed as such in my documentation because of this, despite the fact that they've never not been and will never not be in the future. I of course cannot disable the flag either as then the crate won't compile, as much of what I'm doing does not fit into the stabilized set of functionality. At the very least, surely there must be some way to make it possible to specifically tell rustdoc to "please always document s as exactly what they are no matter what" without changing this default behaviour if that's not desired?
I think the metric should be 'does this have , not 'is this a function'.
I wonder if this isn't an artifact of the switch when adding support... But in any case, it should be a check over , you're absolutely right.
I wonder if this ever worked ... do you mind trying this with an old version of rustdoc? Preferably before was implemented: cc
I'll try that on my crate later today.
After testing both the example I gave here and my own crate with various nightlies from before was implemented, I can confirm that this problem definitely pre-dates it. There's no difference in how rustdoc behaved.
(apologies to lcnr for the ping)
If this helps at all, whichever version of rustdoc was using on August 1st did document my crate properly, it seems. Only the very latest version, uploaded on September 5th, was documented with the keyword missing. So it's a fairly recent bug, overall.
Ok, so I think I was reading the dates on the PRs a bit wrong when I tested yesterday as far as the timeframe for when was merged.

I just did a whole bunch more one-by-one testing of nightlies from August, and in fact the problem doesn't quite predate which was merged on August 7th. Specifically, the very last nightly to have a rustdoc that documents correctly is . Switching directly from that to from the next day makes the problem appear.
consider using instead which will do it automatically
Well, I already know it's a commit from between the 10th and 11th of August now, at least. Also, doesn't really seem to be designed for scenarios where identifying the problem specifically requires running on a crate and then visually inspecting the generated HTML files...
Change:
warning: skipping const checks <del> --> $DIR/mutable_references_ice.rs:26:9 </del> <ins> --> $DIR/mutable_references_ice.rs:27:9 </ins> | LL |         *MUH.x.get() = 99; |         ^^^^^^^^^^^^^^^^^ thread 'rustc' panicked at 'assertion failed: `(left != right)` left: `Const`, <del> right: `Const`: UnsafeCells are not allowed behind references in constants. This should have been prevented statically by const qualification. If this were allowed one would be able to change a constant at one use site and other use sites may arbitrarily decide to change, too.', src/librustc_mir/interpret/intern.rs:127:17 </del> <ins> right: `Const`: UnsafeCells are not allowed behind references in constants. This should have been prevented statically by const qualification. If this were allowed one would be able to change a constant at one use site and other use sites may arbitrarily decide to change, too.', src/librustc_mir/interpret/intern.rs:LL:CC </ins> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. error: internal compiler error: unexpected panic

Discussion:
The build of smoltcp on nightly started failing recently with an ICE: https://travis- ~I suspect this might be caused by E0713, but it shouldn't be an ICE in any case.~
I believe the fundamental cause of the error is that the code looks like the following: That's pretty obviously unsound.
Correction for earlier comment: E0713 is completely unrelated. I've eliminated the problematic code that caused it in m-labs/smoltcp but the crash is still there.
cc (also, such an ICE should say "const checking" or similar - we should maybe even rename the pass itself in the compiler - the "qualify" part isn't as primary for MIR as it is for the AST side).
<details<summaryFull backtrace</summary</details<details<summaryfunction </summary</details
MCVE: : ok : ICE I'm bisecting it now.
Bisected to / .
Oh, I forgot about the ZST trickery, sorry, will have a fix tomorrow
What's the ZST here? in ?
Yes. That's a that gets unsized to .
Change:
} else { self.parse_path(PathStyle::Type)? }; <ins> if self.may_recover() && self.token == TokenKind::OpenDelim(Delimiter::Parenthesis) { self.recover_fn_trait_with_lifetime_params(&mut path, &mut lifetime_defs)?; } </ins> if has_parens { if self.token.is_like_plus() { // Someone has written something like `&dyn (Trait + Other)`. The correct code

Discussion:
The following code: currently produces a heap of semi-helpful diagnostics: <details<summary<bstderr (7 errors)</b</summary</detailswhen instead we could special-case this and emit a single (or at least fewer) diagnostic that suggests the following: If the bound in not inside , like in: we currently emit the following: which is less verbose for sure but still, we should provide the same suggestion I propose above. Related issue: . label A-parser A-suggestion-diagnostics D-newcomer-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Error: Parsing ping command in failed: ...'stbot ping' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I'd like to take a look. claim
I'm wondering if taking an approach that suggests using higher-rank trait bounds () for an Fn-family trait with a lifetime parameter. Is it appropriate? I'm concerned that it may not a comprehensive solution because HRTB can be used outside of the Fn-family traits (as I understand). Or is it okay only for the Fn-family traits for now?
I am not sure I fully understand what you mean. As you probably know, none of , , take a lifetime parameter and probably never will. Of course, you could define such a trait with unstable features but there is no way to use them, so it's not relevant: Yes, I'd say so. I wouldn't look for names however (like , , …) but just look for an opening parenthesis after a generic parameter list. This way, we can emit the same suggestion for the following case (where the name is ):
Ah, definitely. Thank you!
Change:
clean::TyMethodItem(clean::TyMethod { unsafety, decl, self_, generics, abi }) => { <ins> let constness = if csearch::is_const_fn(&tcx.sess.cstore, did) { hir::Constness::Const } else { hir::Constness::NotConst }; </ins> clean::MethodItem(clean::Method { unsafety: unsafety, <del> constness: hir::Constness::NotConst, </del> <ins> constness: constness, </ins> decl: decl, self_: self_, generics: generics,

Discussion:
Doc inclusion / doc reexport does not show properly (example: std::cell::Cell::new). Reexport metabug: rustdoc: Pain points of reexports const fn tracker:
Change:
<ins> const _: () = { #[macro_export] macro_rules! first_macro { () => {} } mod foo { #[macro_export] macro_rules! second_macro { () => {} } } }; </ins>

Discussion:
Found in the crater run: ICEs: ` This ICE happens on: but only shows a compiler error.
Assigning as and removing .
This is because an integration gets checked, which relies on the feature to be enabled. Once it is enabled, does not fail anymore, and yet the ICE persists . I'll thus kindly ask for this to be "re-prioritized", if possible, thanks. modify labels: +I-prioritize
Assigning and removing as in the prioritization working group.
ping cleanup This needs mcve and bisection
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched nightlies: from nightly-2020-07-20 to nightly-2020-08-25 regressed nightly: nightly-2020-07-28 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summary
Minimized:
Change:
// No longer a type mismatch - the `_` can be fully resolved by type inference. let p1: *const u8 = &x1.y as *const _; <ins> let p1: *mut u8 = &x1.y as *mut _; //~^ ERROR: casting `&[u8; 2]` as `*mut u8` is invalid </ins> let t1: *const [u8; 2] = &x1.y as *const _; <ins> let t1: *mut [u8; 2] = &x1.y as *mut _; //~^ ERROR: casting `&[u8; 2]` as `*mut [u8; 2]` is invalid </ins> let h1: *const [u8; 2] = &x1.y as *const [u8; 2]; <ins> let t1: *mut [u8; 2] = &x1.y as *mut [u8; 2]; //~^ ERROR: casting `&[u8; 2]` as `*mut [u8; 2]` is invalid </ins> let mut x1 = X { y: [0, 0] }; <del> // This is still an error since we don't allow casts from &mut [T; n] to *mut T. let p1: *mut u8 = &mut x1.y as *mut _;  //~ ERROR casting </del> <ins> let p1: *mut u8 = &mut x1.y as *mut _; let p2: *const u8 = &mut x1.y as *const _; </ins> let t1: *mut [u8; 2] = &mut x1.y as *mut _; let h1: *mut [u8; 2] = &mut x1.y as *mut [u8; 2]; }

Discussion:
cc is this a coercion that's expected to work?
triage: I-nominated
The first cast is from to , the second is from to . I'm not actually sure if this is meant to work, I guess it should. The intention here is to give a way to treat arrays like C-arrays and get a pointer to the start of the array. It seems that if the array is mutable, then the pointer should be too. I recommend this is P-low - it is backwards compatible, rare, and just a bug by omission, really. The fix should be pretty easy though.
Ah I wasn't sure if this was intended, if it's actually intended then I don't mind removing the nomination as well!
I'm not sure how intended this is, but it doesn't seem too harmful. ;)
P-low, (perhaps "just a bug", perhaps a minor feature.)
Triage: no change
This still happens today (with ), but the error message is slightly different: is another -related issue.
Change:
<del> Subproject commit d77fe6c63ca4c50b207a1161def90c9e57368d5b </del> <ins> Subproject commit 69268fb75fdb452296caa9bc4aaeff1674279de2 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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! cc the PR reviewer, and -- nominating for prioritization.
Needs a xargo fix, which is on its way at
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-44023.rs:15:42 | 15 |   fn საჭმელად_გემრიელი_სადილი ( ) -> isize { |  __________________________________________^ 16 | | } | |_^ expected isize, found () | = note: expected type `isize` found type `()` error: aborting due to previous error </ins>

Discussion:
has saying that the column info is provided in characters, not in bytes. However, the error emitter doesn't care about that at all and uses these like byte offsets all over the place. This leads to bugs like and . As an example, look how span printing varies with varying characters used: Correct case: Now add an emoji character: Note how its off by one char now. This can stack up: If I didn't use any spaces at all, I'd run into . Now this can be fixed by going through the emitter code and looking for all places where the pos is used in a byte position fashion. A much more proper fix instead is to stop trusting that people read comments and encode this via the type system. There is already a mechanism for that inside the compiler, its ! Just convert the types of , members of the and structs to , or maybe to if that's preferred.
cc