jiebi/CodeConvo huggingface dataset:
Change:
pub use self::sources::{from_fn, FromFn}; #[stable(feature = "iter_once", since = "1.2.0")] pub use self::sources::{once, Once}; <del> #[unstable(feature = "iter_once_with", issue = "57581")] </del> <ins> #[stable(feature = "iter_once_with", since = "1.43.0")] </ins> pub use self::sources::{once_with, OnceWith}; #[stable(feature = "rust1", since = "1.0.0")] pub use self::sources::{repeat, Repeat};

Discussion:
This is the tracking issue for . Currently in nightly, PR = .
Is this function now ready for stabilization?
I don’t see why not. Tracked here: fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to 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. The RFC will be merged soon.
I noticed that this iterator has been stabilized a impl which I assume wasn't intentional so I've submitted to remove it.
Change:
true, |component| { path.push(component.to_string()); }); <del> Some(format!("{root}src/{krate}/{path}.html#{href}", root = self.cx.root_path, krate = self.cx.layout.krate, path = path.join("/"), href = href)) </del> <ins> // If the span points into an external macro the // source-file will be bogus, i.e `<foo macros>` if Path::new(&self.item.source.filename).is_file() { Some(format!("{root}src/{krate}/{path}.html#{href}", root = self.cx.root_path, krate = self.cx.layout.krate, path = path.join("/"), href = href)) } else { None } </ins> // If this item is not part of the local crate, then things get a little // trickier. We don't actually know the span of the external item, but

Discussion:
The "src" link at the top goes to the incorrect URL:
Can you please file this against instead? This tracker is just for Rust itself. Thanks!
This is a bug in rustdoc afaict.
Ah! Sorry about that
Might be related to
Change:
<ins> fn main() { bar::bar() } </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. --I tried this code: I expected to see this happen: generate Instead, this happened: <!-- 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<summaryBacktrace</summary<p</p</details
This is strange, Miri uses but statics seem to work fine for us?
Does the test case I gave work for Miri? I notice that produces much larger rmeta files than would, which are in turn larger than 's rmetas (as expected). It would be nice to have an option to make lone produce the same output as , and I was hoping that it would just be a matter of stabilizing , but they don't seem to be equivalent. Ideally they'd produce the same output, but I'd be happy with functionally interchangable - which is what this issue is about. Overall, I'm finding it hard to work out what controls what goes into a file. I audited all the places where either or both of and/or are checked, and unifying them does not produce an output where and together produce the same as . I guess I haven't confirmed that MIR is the only difference between the two cases.
Yes: when I set up a 2-crate workspace matching your 2 files and then do , it works as expected.
PR adds so that generates equivalent rmetas to .
Change:
); } } <ins> /// Adds an explanatory note if the move error occurs in a derive macro /// expansion of a packed struct. /// Such errors happen because derive macro expansions shy away from taking /// references to the struct's fields since doing so would be undefined behaviour fn add_note_for_packed_struct_derive(&self, err: &mut Diagnostic, local: Local) { let local_place: PlaceRef<'tcx> = local.into(); let local_ty = local_place.ty(self.body.local_decls(), self.infcx.tcx).ty.peel_refs(); if let Some(adt) = local_ty.ty_adt_def() && adt.repr().packed() && let ExpnKind::Macro(MacroKind::Derive, name) = self.body.span.ctxt().outer_expn_data().kind { err.note(format!("`#[derive({name})]` triggers a move because taking references to the fields of a packed struct is undefined behaviour")); } } </ins> }

Discussion:
The following code causes a compilation error. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is intended, it is an attempt to make derives and work in more cases. The derive cannot know whether the field is copy. It cannot take a reference to the field, since it's not aligned. So it tries to copy, which at least works for types.
Should, or can this be fixed?
It cannot. repr(packed) sucks.
Atleast, we should modify the error message to make it clearer? Something like error[E0507]: cannot move out of which is behind a shared reference -- | 3 | #[derive(Debug)] | ----- in this derive macro expansion 4 | struct B(String); | ^^^^^^ move occurs because has type , which does not implement the trait | = note: this error originates in the derive macro (in Nightly builds, run with -Z macro-backtrace for more info) = note: this struct is marked as , but unaligned field references are undefined behaviour. For more information about this error, try .
that's possible.
claim
I'll let others implement the diagnostic message.
Change:
(prog, line_offset, supports_color) } <del> // FIXME(aburka): use a real parser to deal with multiline attributes fn partition_source(s: &str) -> (String, String, String) { </del> <ins> fn check_if_attr_is_complete(source: &str, edition: Edition) -> bool { if source.is_empty() { // Empty content so nothing to check in here... return true; } rustc_span::create_session_if_not_set_then(edition, |_| { let filename = FileName::anon_source_code(source); let sess = ParseSess::with_silent_emitter(None); let mut parser = match maybe_new_parser_from_source_str(&sess, filename, source.to_owned()) { Ok(p) => p, Err(_) => { debug!("Cannot build a parser to check mod attr so skipping..."); return true; } }; // If a parsing error happened, it's very likely that the attribute is incomplete. if !parser.parse_attribute(InnerAttrPolicy::Permitted).is_ok() { return false; } // We now check if there is an unclosed delimiter for the attribute. To do so, we look at // the `unclosed_delims` and see if the opening square bracket was closed. parser .unclosed_delims() .get(0) .map(|unclosed| { unclosed.unclosed_span.map(|s| s.lo()).unwrap_or(BytePos(0)) != BytePos(2) }) .unwrap_or(true) }) } fn partition_source(s: &str, edition: Edition) -> (String, String, String) { </ins> #[derive(Copy, Clone, PartialEq)] enum PartitionState { Attrs,

Discussion:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:
Change:
panic!() } <ins> fn l<'a>(_: &'a str, _: &'a str) -> &str { "" } //~^ ERROR missing lifetime specifier // This is ok because both `'a` are for the same parameter. fn m<'a>(_: &'a Foo<'a>) -> &str { "" } </ins> fn main() {}

Discussion:
Instead, this happened: Successful compilation Tested on the playground, all versions and editions. Stable channel: 1.64.0 Beta channel: 1.65.0-beta.3 (2022-10-10 ) Nightly channel: 1.66.0-nightly (2022-10-19 ) I'm labeling this as a regression as I believe it is severe enough of an unplanned change (at best an accidental stabilization?) that I should draw attention to it, even though I haven't found a way to cause miscompilation for example. I also have not tried to do so at all yet. label +T-compiler +A-lifetimes +regression-from-stable-to-stable <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2022-01-01 to nightly-2022-10-01 regressed nightly: nightly-2022-07-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
claim
Actually, this behavior is correct as : There is exactly one lifetime used in the parameters (), so assigning it to the output lifetime is as expected. release-assignment
That verbiage but it compiles on no stable version of rustc prior to 1.64, so I don't think it's actually relevant. (The reference is also explicitly non-normative.) mirrors in specifying input positions, not counts. Regardless of documentation, as something that has not compiled on Rust 1.0--1.63 but compiles today, this is clearly a change in language behavior without FCP which I believe to be unintentional. label +T-lang
Ok, so we will consider this for now a regression that should be backported to stable (we're ~2 weeks away from the new release). WG-prioritization assigning priority (). label -I-prioritize +P-critical
Filed
Nominating for lang team to figure out what we should do with this. Will also ping on zulip.

Discussed in lang, dropping nomination. Agreement that we want to revert the change in behavior and backport that to 1.65 (and 1.64, but that's not happening given short time window). Considering whether we want to make the behavior change can happen in a follow-up proposal.
Change:
<ins> error[E0428]: the name `b` is defined multiple times --> $DIR/issue-58490.rs:18:5 | LL |         macro_rules! b { () => () } |         -------------- previous definition of the macro `b` here ... LL |     macro_rules! b { () => () } |     ^^^^^^^^^^^^^^ `b` redefined here | = note: `b` must be defined only once in the macro namespace of this module error: aborting due to previous error For more information about this error, try `rustc --explain E0428`. </ins>

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd like to work on this. claim
Now ICE no longer occurs, I think it's fixed by . Marked as E-needstest.

When executed in the : <details<summaryCompiler output</summary</detailsEDIT: Here's the updated and the new stack trace as of Jan 7, 2020: <details<summaryCompiler output</summary</details
cc
I think this is another instance of However, we can leave this issue open to remember to add a test case when it's fixed.
The original issue no longer ICEs and instead errors with: which is essentially correct. However, providing the type annotations produces a new ICE:
In Source: <details<summaryStack trace</summary<p</p</details
Now ICE no longer occurs. I think it's fixed by .

This occurs on 1.34.1 and 1.34.0, is a regression from 1.33.0, and does.. not occur on nightly? Reproduction: compiled with Yields: I found this in building crates like and but pared it down to this
I think this is fixed in which might explain why it doesn't occur on nightly
triage: Probably fixed by . Normally an ICE would lead me to tag this as P-high, but the fact that this is only exposed by leads me to prioritize this as P-medium.
assigning to self to confirm that is the reason this is fixed, and (if need be) add a regression test.
Here's a slightly smaller case of what appears to potentially be the same thing which shows up if you select the "show MIR" option in In particular the following error is observed:
I think this issue is fixed in all channels. I tried stable and nightly both locally and on , and couldn't get any ICEs. Should we add a test? Otherwise we can just close I think.
Adding a test with seems like a good idea.

Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.
Change:
<ins> error[E0428]: the name `b` is defined multiple times --> $DIR/issue-58490.rs:18:5 | LL |         macro_rules! b { () => () } |         -------------- previous definition of the macro `b` here ... LL |     macro_rules! b { () => () } |     ^^^^^^^^^^^^^^ `b` redefined here | = note: `b` must be defined only once in the macro namespace of this module error: aborting due to previous error For more information about this error, try `rustc --explain E0428`. </ins>

Discussion:
results in: Removing the constgenerics feature flag gets the expected error message: (IIUC that itself is a bug related to ) Using directly outside of a const-context works, which I guess is something const_generics enables that isn't otherwise allowed. Finally, the error message is the same whether or not the code is in a provided method or a impl block; I actually ran into the bug in the later.
I believe this should be fixed by
Now, it shows different ICE(s) ():
Now ICE no longer occurs. I think it's fixed by .
Change:
<ins> - // MIR for `remove_casts_must_change_both_sides` before GVN + // MIR for `remove_casts_must_change_both_sides` after GVN fn remove_casts_must_change_both_sides(_1: &*mut u8, _2: *mut u8) -> bool { let mut _0: bool; let mut _3: *const u8; let mut _4: *const u8; bb0: { _3 = (*_1) as *const u8 (PtrToPtr); _4 = _2 as *const u8 (PtrToPtr); _0 = Eq(_3, _4); return; } } </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. --Compiling the following code with results in ICE. Strangely, this code compiles fine without . Replace with plain comparison also works. : <!-- 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 seems to bisect to cc
Thanks for the ping! I'll take a look. I thought I'd checked for this with , but clearly I missed something.
Change:
<del> // Verify that we ban usage of `Self` as constructor from inner items. struct S0<T>(T); impl<T> S0<T> { fn foo() { const C: S0<u8> = Self(0); //~^ ERROR can't use generic parameters from outer function fn bar() -> Self { //~^ ERROR can't use generic parameters from outer function Self(0) //~^ ERROR can't use generic parameters from outer function } } } fn main() {} </del>

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 made a blank cargo project (ran in an empty directory), and dependencies to my like so: Originally when I went to run , I was in nightly, and got a compile error (full error below). Then, when i switched to stable, there was no error and everything built fine! <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.69 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- 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 -- modify labels: +regression-from-stable-to-nightly -regression-untriaged
searched nightlies: from nightly-2023-02-15 to nightly-2023-05-13 regressed nightly: nightly-2023-05-05 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsrollup it didn't want to bisect the perf builds for some reason but i guess or could be at fault? haven't looked into the actual issue in detail, since it's behind a macro you probably know something about this anyways even if it may not be your fault
its not that is genericconstexprs only code
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler
Change:
<ins> <div class="variants"><section id="variant.A" class="variant"><a href="#variant.A" class="anchor">&#167;</a><h3 class="code-header">A</h3></section><div class="docblock"><p>A variant with no fields</p> </div><section id="variant.B" class="variant"><a href="#variant.B" class="anchor">&#167;</a><h3 class="code-header">B</h3></section><div class="docblock"><p>A variant with hidden fields</p> </div></div> </ins>  No newline at end of file

Discussion:
While working on , I noticed that struct variants with no (visible) fields look kinda awkward. ! The Fields heading takes a lot of space without adding particularly much to the content. The easiest solution would be to just remove the heading, but that would show no indication that there exist private fields. The same issue exists in top-level structs as well, but there it is mitigated by having the definition in the code block just above, while for enums there can be a sizeable distance between the two. Any thoughts? Am I just overthinking the whole thing?
No this is a very good point. If there are no fields, we shouldn't add the "Fields" heading. Sending a fix.
Change:
<ins> error[E0412]: cannot find type `Someunknownname` in this scope --> $DIR/type-not-found-in-adt-field.rs:2:12 | LL |     m: Vec<Someunknownname<String, ()>>, |            ^^^^^^^^^^^^^^^ not found in this scope error[E0412]: cannot find type `K` in this scope --> $DIR/type-not-found-in-adt-field.rs:6:8 | LL | struct OtherStruct { |                   - help: you might be missing a type parameter: `<K>` LL |     m: K, |        ^ not found in this scope error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0412`. </ins>

Discussion:
Rustc should know that is not in the right direction because that still wouldn't make a valid thing to write; type parameters can't have type parameters (yet??). Separately, should also have prevented the suggestion in this case, but is an independent issue. cc who worked on this recently in .
Change:
// FIXME(#75598): Direct use of these intrinsics improves codegen significantly at opt-level <= // 1, where the method versions of these operations are not inlined. use intrinsics::{ <del> cttz_nonzero, exact_div, unchecked_rem, unchecked_shl, unchecked_shr, unchecked_sub, wrapping_add, wrapping_mul, wrapping_sub, </del> <ins> cttz_nonzero, exact_div, mul_with_overflow, unchecked_rem, unchecked_shl, unchecked_shr, unchecked_sub, wrapping_add, wrapping_mul, wrapping_sub, </ins> }; /// Calculate multiplicative modular inverse of `x` modulo `m`.

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. --I tried this code: I expected to see this happen: The program terminates. Instead, this happened: The program loops indefinitely. I encountered this while working on <!-- 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. --:
Hangs here: label I-hang
CC
Thanks for the report. Priority wise, this seems like it isn’t going to be super high priority to resolve, given that 1<<47 is 128TiB. 128TiB, unfortunately, is half of the maximum supported address space on many modern x8664 and aarch64 deployments, so it is conceivable that this could be actually hit. Still would be nice to actually fix it. As for the strategies to fix this, there are a couple of approaches to consider: could store the into a u128 (2 usize on any supported platform today.) This is not super future-proof, and unfortunately probably somewhat more costly in the non-const-evaluated case. could use instead of . When overflows on the last iteration, it will become the maximum value that fits in and the termination condition will be hit. Not super clear what codegen quality implications are for using saturatingmul; a widening/checked multiplication and additionally compare the high bits for in the terminating condition. This is an alteration of 1. I suspect this is going to produce the best code, but that remains to be seen.
Would it work to change the termination condition from to ? Where means it wrapped, so the logical value is out of the type's range, and thus bigger than .
Or weirder: store instead of , so the comparison can be done using and the squaring operation can be replaced with a doubling (bit shift).
Change:
self.print_type(ty); if let Some(ref _default) = default { // FIXME(const_generics_defaults): print the `default` value here <del> todo!(); </del> } } }

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. --code from <!-- 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</detailsThis happens since cc
Oh my, I'll fix that now. The syntax is gated but evidently the flag can still reach into the parts which were not completed yet. Update: Ah but I misread the code, this is actually using const generics defaults. They're not done yet, ICE-ing is expected until the feature is completed in . how did you hit that ? Were you trying to use const generics defaults or did the ICE come up unexpectedly ? I can open a PR that will do nothing here instead of ICE-ing.
I made a small program that executes rustc on all the rust files with different flags and filters the ICEs. The file showed up as previously unknown crash.
On nightly-2020-12-31 (commit ), I get a parse error with the code you provided:
Yes, the PR was merged ~7 hours ago, it's not in nightly yet.
Ah, things move fast :) How did you get a build with the commit then? Did you use ?
There are inofficial "master" builds released for every merge commit in the repo (the latest one is then promoted to "nightly" once at some point of the day) You can install them with and run something like or afterwards.
Oh, I forgot about RTIM
will remove the ICE so that only the appears