jiebi/CodeConvo huggingface dataset:
Change:
for frag in doc_strings { add_doc_fragment(&mut acc, frag); } <ins> acc.pop(); </ins> acc }

Discussion:
I expected this change to work: But it causes to panic: <details<summaryBacktrace</summary</detailsI don't have time to look into it right now, but I wouldn't expect it to be too hard to fix and it would reduce the memory usage of rustdoc by quite a lot. I'd suggest starting by adding a bunch of assertions that the old and new behavior of is the same and investigating the assertion failures. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Since would unconditionally add a final newline, shouldn't the note say that (instead of "this can") and the 'pop's be unconditional? Across the entire codebase, there's just one other invocation of 'adddocfragment' (currently line 1087 ); it seems that that doesn't need a newline popped. Instead, I think the last function you modified () should only have a newline popped for the last , as would only be false for the last , as far as I can tell. I made a commit to that effect in the PR above, though I have to resolve the merge conflict somehow.
feel free to try that out and see if it works :) like I said, I don't have time to work on it right now.
Change:
t("```rustn```n```rustn```", &[1, 3]); t("```rustn```n ```rustn```", &[1, 3]); } <ins> #[test] fn test_ascii_with_prepending_hashtag() { fn t(input: &str, expect: &str) { let mut map = IdMap::new(); let output = Markdown { content: input, links: &[], ids: &mut map, error_codes: ErrorCodes::Yes, edition: DEFAULT_EDITION, playground: &None, heading_offset: HeadingOffset::H2, } .into_string(); assert_eq!(output, expect, "original: {}", input); } t( r#"```ascii #..#.####.#....#.....##.. #..#.#....#....#....#..#. ####.###..#....#....#..#. #..#.#....#....#....#..#. #..#.#....#....#....#..#. #..#.####.####.####..##.. ```"#, "<div class="example-wrap"><pre class="language-ascii"><code> #..#.####.#....#.....##.. #..#.#....#....#....#..#. ####.###..#....#....#..#. #..#.#....#....#....#..#. #..#.#....#....#....#..#. #..#.####.####.####..##.. </code></pre></div>", ); } </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: text //! #..#.####.#....#.....##.. //! #..#.#....#....#....#..#. //! ####.###..#....#....#..#. //! #..#.#....#....#....#..#. //! #..#.#....#....#....#..#. //! #..#.####.####.####..##.. //! I expected to see this happen: When I run , I expect to see ASCII art in the output that matches the above example. Instead, this happened: In the output, this actually appears: It appears that if a line starts with at least three s, one gets "swallowed" somehow. <!-- 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
It's because of how are handled for rust code blocks. I'll send a PR but we need to ensure that people are not relying on to hide a line for non-rust code blocks.
This is actually a regression. I haven't bisected, but it occurred sometime between 1.50.0 and 1.63.0 based on a quick test. In 1.50.0, the following code block markdown /// # Header /// rendered as , but in 1.63.0 it renders as a blank code block.
Thanks for the information !

The regression is in nightly-2021-07-15 Commits in range: commit[0] 2021-07-13UTC: Auto merge of - camsteffen:hash-lint-resolved, r=oli-obk commit[1] 2021-07-13UTC: Auto merge of - cjgillot:expnhash, r=petrochenkov commit[2] 2021-07-14UTC: Auto merge of - Mark-Simulacrum:edition-no-clone, r=petrochenkov commit[3] 2021-07-14UTC: Auto merge of - tlyu:option-result-overviews, r=joshtriplett commit[4] 2021-07-14UTC: Auto merge of - JohnTitor:rollup-8ltidsq, r=JohnTitor commit[5] 2021-07-14UTC: Auto merge of - michaelwoerister:const-in-debuginfo-type-names-fix, r=oli-obk,wesleywiser commit[6] 2021-07-14UTC: Auto merge of - GuillaumeGomez:rollup-pfz9jbk, r=GuillaumeGomez commit[7] 2021-07-14UTC: Auto merge of - cuviper:fuse-less-specialized, r=joshtriplett Maybe this happened in (merged by ) (cc
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/slice-const-param.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>

Discussion:
Results in cc
modify labels: I-ICE C-Bug T-compiler A-const-generics
I'm looking into this currently.
Partially as a note to myself and partially as an update to anyone interested The root cause of this bug seems to be the fact that we currently don't explicitly handle slice const values in , and therefore we always say they cannot match. This error eventually bubbles up to to produce all three errors.
Change:
} #[inline] <del> fn mut_last(self) -> &'a mut T { </del> <ins> fn mut_last(self) -> Option<&'a mut T> { </ins> let len = self.len(); <del> if len == 0 { fail!("mut_last: empty vector") } &mut self[len - 1] </del> <ins> if len == 0 { return None; } Some(&mut self[len - 1]) </ins> } #[inline]

Discussion:
changed the , and methods of vectors to return an Option instead of failing on empty vectors. These methods should probably get the same change, to be consistent - - -
I'll try to fix this!
Change:
<del> use crate::mem::{size_of, transmute_copy}; use crate::ptr::write_bytes; </del> pub(super) trait SpecFill<T> { fn spec_fill(&mut self, value: T); }

Discussion:
This was reported by on Zulip: https://rust- Demo:
I think the fix should be as simple as using instead of as the type of - that will work regardless of whether or not the memory is initialized.
The other option is just removing the case entirely. Llvm is smart enough to turn that loop in the branch into a memset.
It does help the gcc codgen backend at least as it can't manage to produce a memset for u64 so I assume it would fail to do the same for u8 if it weren't for that specialization.
It also fails for the case:
It does call memset if you don't pass an array.
I'd think the intrinsic could easily have its type changed to take a , which would let one solve this problem. The stable function of course cannot be changed, though...
Reopening to track adding a test. (That's the standard procedure for this, isn't it?)
I would like to try working on adding the test, though this will be my first contribution so I'd need some guidance. I'm assuming this would be a miri test as it's related to correctness--may I DM you on Zulip? (or would someone else be more suitable?)
great. :) Miri runs the libcore test suite via So adding it as a test in libcore makes most sense, IMO.
Change:
<ins> // compile-flags: -Zmir-opt-level=2 -Zinline-mir // ignore-debug: standard library debug assertions add a panic that breaks this optimization #![crate_type = "lib"] pub enum Thing { A, B, } // EMIT_MIR instcombine_duplicate_switch_targets_e2e.ub_if_b.PreCodegen.after.mir pub unsafe fn ub_if_b(t: Thing) -> Thing { match t { Thing::A => t, Thing::B => std::hint::unreachable_unchecked(), } } </ins>

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: no branch instructions emitted, makes an assumption that is , so should be inlined and optimized as a panic. Instead, this happened: there is a discriminant check still emitted. <!-- Provide the most recent version this worked on, for example: It most recently worked on: --It most recently worked on: nightly-2023-03-26 <!-- Provide the version you are using that has the regression. --See godbolt: Regression occurred in (cc searched nightlies: from nightly-2023-03-01 to nightly-2023-04-01 regressed nightly: nightly-2023-03-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: aarch64-unknown-linux-gnu Reproduce with: </details<details</summary(if you want to test on replace with ) </details<details</summary</details originally noticed the problem and opened , then suggested that this is a compiler issue, then that this is a regression, then bisected and opened this issue.
The end of this regression window is over 2 weeks from now. Why? Godbolt usually has pretty old nightlies. If I add : you can see we have duplicate switch targets, which means that either this commit is broken or godbolt doesn't have it:
godbolt seems to have ?
Because I knew that reproduces the regression, and wanted to cut some time bisecting. For reference I can reproduce the same issue with . <details<summary+nightly-2023-04-19 --emit=mir</summary</details
To be clear, separate from this issue I believe that this MIR: is a bug. I do not know what impact resolving that would have on this issue. But the helper that combines switch targets was (notionally) supposed to prevent this.
Yeah, I'm pretty sure that is the root cause.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> #![feature(specialization)] #![allow(incomplete_features)] trait X {} trait Y: X {} trait Z { type Assoc: Y; } struct A<T>(T); impl<T> Y for T where T: X {} impl<T: X> Z for A<T> { type Assoc = T; } // this impl is invalid, but causes an ICE anyway impl<T> From<<A<T> as Z>::Assoc> for T {} //~^ ERROR type parameter `T` must be used as the type parameter for some local type (e.g., `MyStruct<T>`) fn main() {} </ins>

Discussion:
The following code () produces
Triage: still ICEs
This ICEs since modify labels: +regression-from-stable-to-stable
Change:
--> $DIR/issue-65436-raw-ptr-not-send.rs:14:9 | LL |         bar(Foo(std::ptr::null())).await; <del> |         ^^^^^^^^----------------^^^^^^^^- `std::ptr::null()` is later dropped here |         |       | |         |       has type `*const u8` which is not `Send` |         await occurs here, with `std::ptr::null()` maybe used later </del> <ins> |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ first, await occurs here, with `std::ptr::null()` maybe used later... note: `std::ptr::null()` is later dropped here --> $DIR/issue-65436-raw-ptr-not-send.rs:14:41 | LL |         bar(Foo(std::ptr::null())).await; |                 ----------------        ^ |                 | |                 has type `*const u8` which is not `Send` </ins> help: consider moving this into a `let` binding to create a shorter lived borrow --> $DIR/issue-65436-raw-ptr-not-send.rs:14:13 |

Discussion:
Especially the fact that the lines are broken up seems like a bug. () Errors: modify labels: A-diagnostics, C-bug, D-papercut, T-compiler
There are two things here have a label that has embedded newlines which causes the broken down ASCII art should find a way to reverse the order in which multiline spans are sorted, but this will require handling multiple labels. The current order is optimized for not having to tweak the label positions, but when no labels are involved, we could do much better.
So, using raw text from the program as part of our label feels like a hack. We should try to come up with another way of getting a name (and falling back to a description like "async block" or something if that doesn't work). Failing a good way of doing that, I guess we can scan the program text for newlines and only use it if there aren't any..
Agree, we should never be using snippets in labels. The change needs to happen in You have the which lets you get the and from there use an appropriate description. I think there is an open PR that adds description to all variants.
Change:
<del> error[E0616]: field `c` of struct `m::U` is private </del> <ins> error[E0616]: field `c` of union `m::U` is private </ins> --> $DIR/union-field-privacy-2.rs:14:13 | LL |     let c = u.c;

Discussion:
() Errors: Notice how it says "struct" when it should say "union". cc this looks like low-hanging fruit
Can I pick this up if no-one is working on this?
go ahead! You need to use here to get whether it is a struct or union using .
Thanks . Newbie question, but how do I test this while development? Do I build the stage1 compiler and then write a sample test?
is the way to get the fastest iteration time. is theoretically suspect but should affect you on what you're working on and is marginally slower on first compile but much faster on subsequent compiles. You rarely (if ever) need .
Change:
<ins> error[E0005]: refutable pattern in local binding: `std::i32::MIN..=-1i32` and `3i32..=std::i32::MAX` not covered --> $DIR/issue-69875-should-have-been-expanded-earlier-non-exhaustive.rs:4:9 | LL |     let 0 | (1 | 2) = 0; |         ^^^^^^^^^^^ patterns `std::i32::MIN..=-1i32` and `3i32..=std::i32::MAX` not covered | = note: `let` bindings require an "irrefutable pattern", like a `struct` or an `enum` with only one variant = note: for more information, visit https://doc.rust-lang.org/book/ch18-02-refutability.html help: you might want to use `if let` to ignore the variant that isn't matched | LL |     if let 0 | (1 | 2) = 0 { /* */ } |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error[E0004]: non-exhaustive patterns: `std::i32::MIN..=-1i32` and `3i32..=std::i32::MAX` not covered --> $DIR/issue-69875-should-have-been-expanded-earlier-non-exhaustive.rs:5:11 | LL |     match 0 { |           ^ patterns `std::i32::MIN..=-1i32` and `3i32..=std::i32::MAX` not covered | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms error: aborting due to 2 previous errors Some errors have detailed explanations: E0004, E0005. For more information about an error, try `rustc --explain E0004`. </ins>

Discussion:
This code is reduced from issue--unused-parens- :
Another variation on this to include in a regression test:
cc
Ah yeah, I see the issue. There's an implicit invariant that there should be no or-patterns directly in the first column of the matrix, but this invariant is broken exactly when an or-pattern has a child that is itself an or-pattern. I should have documented that. Specifically this fails to preserve the invariant: I don't expect to have the bandwidth to work on rustc in the foreseeable future sadly. I anyone wants to try, I believe the fix could be as simple as replacing in the above function with a loop that calls (and not ). That will ensure that we recursively expand or-patterns as needed instead of just expanding the first one.
Yep, that did it. Thanks for the pointer. This issue is fixed by
Change:
<ins> error[E0412]: cannot find type `Missing` in this scope --> $DIR/return-not-existing-type-wrapping-rpitit.rs:10:25 | LL |     fn bar() -> Wrapper<Missing<impl Sized>>; |                         ^^^^^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0412`. </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
Probably just need to suppress this assertion if the signature of the trait references . This could use a good explanation for why we ICE, though.
Ohh I've just pushed a fix and now read your comment. Your idea is better.
Change:
# An optional number to put after the label, e.g. '.2' -> '-beta.2' # NB Make sure it starts with a dot to conform to semver pre-release # versions (section 9) <del> CFG_PRERELEASE_VERSION=.4 </del> <ins> CFG_PRERELEASE_VERSION=.5 </ins> ifeq ($(CFG_RELEASE_CHANNEL),stable) # This is the normal semver version string, e.g. "0.12.0", "0.12.0-nightly"

Discussion:
Specifically at , and recommend for Windows too, right? We've , but in the meantime, the old book should recommend the new recommended toolchain :) If it's too soon to do this because isn't stable enough yet, consider this a reminder issue to make this change once it is :)
wants to wait a bit, and we'd need to then make sure to update the website in sync (see )
Maybe the big red warning "this is beta software" should be removed from the website?
This will be fixed by
Change:
match res { LifetimeRes::Param { .. } | LifetimeRes::Fresh { .. } | LifetimeRes::Static => { if let Some(ref mut candidates) = self.lifetime_elision_candidates { <del> candidates.insert(res, candidate); </del> <ins> candidates.push((res, candidate)); </ins> } } LifetimeRes::Infer | LifetimeRes::Error | LifetimeRes::ElidedAnchor { .. } => {}

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:
/// A conversion that consumes `self`, which may or may not be expensive. /// <ins> /// **Note: this trait must not fail**. If the conversion can fail, use a dedicated method which /// return an `Option<T>` or a `Result<T, E>`. /// /// Library writer should not implement directly this trait, but should prefer the implementation /// of the `From` trait, which offer greater flexibility and provide the equivalent `Into` /// implementation for free, thanks to a blanket implementation in the standard library. /// </ins> /// # Examples /// /// `String` implements `Into<Vec<u8>>`:

Discussion:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart.

:+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!
Change:
<ins> #![feature(type_alias_impl_trait)] use std::marker::PhantomData; trait ProofForConversion<'a, 'b> { fn convert<T: ?Sized>(_: PhantomData<Self>, r: &'a T) -> &'b T; } impl<'a, 'b> ProofForConversion<'a, 'b> for &'b &'a () { fn convert<T: ?Sized>(_: PhantomData<Self>, r: &'a T) -> &'b T { r } } type Converter<'a, 'b> = impl ProofForConversion<'a, 'b>; //~^ ERROR reference has a longer lifetime than the data it references // Even _defining_use with an explicit `'a: 'b` compiles fine, too. fn _defining_use<'a, 'b>(x: &'b &'a ()) -> Converter<'a, 'b> { x } fn extend_lifetime<'a, 'b, T: ?Sized>(x: &'a T) -> &'b T { Converter::<'a, 'b>::convert(PhantomData, x) } fn main() { let d; { let x = "Hello World".to_string(); d = extend_lifetime(&x); } println!("{}", d); } </ins>

Discussion:
() I would’ve expected rustc to complain about the not matching the with a suggestion to turn it into . modify labels: A-typesystem, A-lifetimes, A-traits, A-impl-trait, F-typealiasimpl_trait, T-compiler, requires-nightly and someone please add “I-unsound ” (and/or tell me if there is a way to do it myself).
One thing that is of note here is that we properly enforce type bounds, but not lifetime bounds, as the equivalent program with types fails to compile right where we expect that:
Aha! If we change to have an explicit bound, then we get the right error: so we're just missing a check of the implied bounds on the impl
Change:
<ins> // Breaks with values inside closures used to ICE (#66863) fn main() { 'some_label: loop { || break 'some_label (); //~ ERROR: `break` inside of a closure } } </ins>

Discussion:
The following code ICE's on stable, beta and nightly: <details<summaryBacktrace:</summary</details
reduced
This is not an bug, here's another reproducer for the same bug: EDIT: Fix coming ...
A closure is just enough: modify labels: -A-async-await +A-closures