jiebi/CodeConvo huggingface dataset:
Change:
} } <del> fn overlap_x_and_y() -> impl Generator<Yield = (), Return = ()>{ </del> <ins> fn overlap_x_and_y() -> impl Generator<Yield = (), Return = ()> { </ins> static || { let x = Foo([0; FOO_SIZE]); yield;

Discussion:
Currently they use a hardcoded discriminant, which is quite a lot of room considering that generators don't typically have billions of states. They should be able to use the smallest unsigned integer type that fits all states instead (so in the vast majority of cases).
The discriminant is also never marked with a valid range, meaning that it never provides any niches that could be used to store other values. Not sure if doing that has any drawbacks, but it seems like a somewhat easy size optimization on first glance.
Fixing this was way easier than I expected, but I'd appreciate help with benchmarking the runtime impact of the fix in . So if anyone knows any async/await benchmarks that are not I/O heavy (so that they mostly test CPU overhead of async/await), I'd be happy to run them.
Change:
<ins> #![crate_name = "foo"] #![deny(rustdoc::broken_intra_doc_links)] //! [foo!()] // @has foo/index.html '//a[@href="macro.foo.html"]' 'foo!()' //! [foo!{}] // @has - '//a[@href="macro.foo.html"]' 'foo!{}' //! [foo![]](foo![]) // @has - '//a[@href="macro.foo.html"]' 'foo![]' //! [foo1](foo!()) // @has - '//a[@href="macro.foo.html"]' 'foo1' //! [foo2](foo!{}) // @has - '//a[@href="macro.foo.html"]' 'foo2' //! [foo3](foo![]) // @has - '//a[@href="macro.foo.html"]' 'foo3' #[macro_export] macro_rules! foo { () => {}; } </ins>

Discussion:
Consider this code: I'm not sure if this is a deliberate decision or not. If it is, what's the rationale for not accepting and ? cc
It isn't valid markdown syntax.
Well, might be. But [] definitely is not.
seems to work fine (it renders as and the link is correct). But maybe you're saying that we shouldn't accept because it wouldn't be valid markdown? Is it worth implementing?
hmm, it might be valid in that position, but it's not valid as a link reference: But I guess there's no reason for rustdoc to explicitly reject it. I would be ok with it, may have opinions.
I'm okay with it. I'm mostly wary about characters that are common in URLs, curly braces are not.
Oh, the reason why works is because the rules for inline links are more relaxed: vs So instead do you think rustdoc should parse ?

Consider this code: In the generated docs, the link on the page appears as , with the correct link, but without the parentheses.
Sorry, I stole this from you :smile:
That's okay! Thanks for fixing this :)
Change:
impl A for B {} fn test<const T: &'static dyn A>() { <del> //~^ ERROR must be annotated with `#[derive(PartialEq, Eq)]` to be used </del> <ins> //[full]~^ ERROR must be annotated with `#[derive(PartialEq, Eq)]` to be used </ins> //[min]~^^ ERROR `&'static (dyn A + 'static)` is forbidden unimplemented!() }

Discussion:
Given the following code (): Rust gives a diagnostic suggesting deriving : However, adding leads the compiler to still give an error about not supporting this. A non-nightly compiler should not give the second error at all; it should only give the first, saying that the only supported types are integers, and . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assigning this to project-const-generics, getting worked on in https://rust-
claim
To fix this issue, you can do the following steps: grep for "forbidden as the type of a const generic parameter" look at that function for a bit change it so that the second error isn't emitted on stable (probably actually change the control flow to start by branching on In case you are interested but need more help to fix this, feel free to reach out to me on
claim
Change:
} #[test] <ins> fn empty_seeks() { let mut e = empty(); assert!(matches!(e.seek(SeekFrom::Start(0)), Ok(0))); assert!(matches!(e.seek(SeekFrom::Start(1)), Ok(0))); assert!(matches!(e.seek(SeekFrom::Start(u64::MAX)), Ok(0))); assert!(matches!(e.seek(SeekFrom::End(i64::MIN)), Ok(0))); assert!(matches!(e.seek(SeekFrom::End(-1)), Ok(0))); assert!(matches!(e.seek(SeekFrom::End(0)), Ok(0))); assert!(matches!(e.seek(SeekFrom::End(1)), Ok(0))); assert!(matches!(e.seek(SeekFrom::End(i64::MAX)), Ok(0))); assert!(matches!(e.seek(SeekFrom::Current(i64::MIN)), Ok(0))); assert!(matches!(e.seek(SeekFrom::Current(-1)), Ok(0))); assert!(matches!(e.seek(SeekFrom::Current(0)), Ok(0))); assert!(matches!(e.seek(SeekFrom::Current(1)), Ok(0))); assert!(matches!(e.seek(SeekFrom::Current(i64::MAX)), Ok(0))); } #[test] </ins> fn repeat_repeats() { let mut r = repeat(4); let mut b = [0; 1024];

Discussion:
You can create an empty io-reader with , which returns an . That doesn't implement the trait. However, I don't see any reason why it shouldn't.
I don't understand how a reader which is always at EOF should be seekable. Can you please explain more about it?
You can think of a reader which is always at EOF as a reader which is always at position 0 with a stream end of position 0. I don't think there is any disadvantage of having implemented for . It allows it to be passed to more generic code.
Did you hit a case where you actually wanted to do this?
In is discussing ways to implement a 307/308 HTTP redirect. Those two codes (in contrast to 301/302/303) require the payload to be sent after the redirect. However, parts of the payload may already have been sent to the server, before the server responds with the redirect. With a generic API taking an as Payload, it's not possible to seek back to the beginning. Thus, one suggestion is to use instead. To allow an empty body (e.g. for a GET request), it would be nice to keep using . While will probably decide to follow a different way for those redirects, I still think this pattern makes sense to support.
Change:
to use PGO with Rust. [clang-pgo]: https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization <ins> ## Community Maintained Tools As an alternative to directly using the compiler for Profile-Guided Optimization, you may choose to go with `cargo-pgo`, which has an intuitive command-line API and saves you the trouble of doing all the manual work. You can read more about it in their repository accessible from this link: https://github.com/Kobzol/cargo-pgo For the sake of completeness, here are the corresponding steps using `cargo-pgo`: ```bash # Install if you haven't already cargo install cargo-pgo cargo pgo build cargo pgo optimize ``` These steps will do the following just as before: 1. Build an instrumented binary from the source code. 2. Run the instrumented binary to gather PGO profiles. 3. Use the gathered PGO profiles from the last step to build an optimized binary. </ins>

Discussion:
I think would be nice to mention in the Rustc Profile-Guided Optimization documentation. With it's much easier to apply PGO to the Rust programs (I did it many times). I suggest adding the information about to the mentioned above page. Even if this project does not belong directly to Rustc or Cargo - it's still worth mentioning. - ping you as the author. P.S. I am creating the issue here since not sure where it should go. Maybe we want to mention in the Cargo book as well. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I don't know if this is already approved, but in case it is, here's my effort for a chance of contribution.
claim
Well, I would of course like it to be mentioned in the docs :) I'm not sure what's the policy on linking to community maintained Cargo subcommands though (if there is any).
Change:
Ty::new_projection(self.tcx, index_trait_output_def_id, impl_trait_ref.args), ); <del> let errors = ocx.select_where_possible(); </del> <ins> let true_errors = ocx.select_where_possible(); // Do a leak check -- we can't really report report a useful error here, // but it at least avoids an ICE when the error has to do with higher-ranked // lifetimes. self.leak_check(outer_universe, Some(snapshot))?; // Bail if we have ambiguity errors, which we can't report in a useful way. let ambiguity_errors = ocx.select_all_or_error(); if true_errors.is_empty() && !ambiguity_errors.is_empty() { return Err(NoSolution); } </ins> // There should be at least one error reported. If not, we // will still delay a span bug in `report_fulfillment_errors`. Ok::<_, NoSolution>(( <del> self.err_ctxt().report_fulfillment_errors(errors), </del> <ins> self.err_ctxt().report_fulfillment_errors(true_errors), </ins> impl_trait_ref.args.type_at(1), element_ty, ))

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
Regression in nightly-2023-04-20 commit[0] 2023-04-18: Auto merge of - petrochenkov:slimchild, r=cjgillot commit[1] 2023-04-18: Auto merge of - saethlin:encode-hashes-as-bytes, r=cjgillot commit[2] 2023-04-19: Auto merge of - jyn514:download-rustc-tests, r=albertlarsan68 commit[3] 2023-04-19: Auto merge of - miguelraz:canoodling2-electric-boogaloo, r=compiler-errors commit[4] 2023-04-19: Auto merge of - matthiaskrgr:rollup-9m7rw3u, r=matthiaskrgr commit[5] 2023-04-19: Auto merge of - Nilstrieb:fluent-macro, r=davidtwco commit[6] 2023-04-19: Auto merge of - fee1-dead-contrib:rm-const-traits, r=oli-obk commit[7] 2023-04-19: Auto merge of - WaffleLapkin:‍sound, r=compiler-errors commit[8] 2023-04-19: Auto merge of - matthiaskrgr:rollup-346kik6, r=matthiaskrgr commit[9] 2023-04-19: Auto merge of - ecnelises:big_archive, r=bjorn3 ERROR: no CI builds available between and within last 167 days
Oh this might be contained in the first rollup ping reduced a bit: `
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> // check-pass trait Mirror { type Other; } #[derive(Debug)] struct Even(usize); struct Odd; impl Mirror for Even { type Other = Odd; } impl Mirror for Odd { type Other = Even; } trait Dyn<T: Mirror>: AsRef<<T as Mirror>::Other> {} impl Dyn<Odd> for Even {} impl AsRef<Even> for Even { fn as_ref(&self) -> &Even { self } } fn code<T: Mirror>(d: &dyn Dyn<T>) -> &T::Other { d.as_ref() } fn main() { println!("{:?}", code(&Even(22))); } </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<pthe backtrace itself is all </p</details
It's strange, I tried these code in main and it complains about (Compile Error but not ICE) I think the trait is depends on and dyn could resolve this.
Assigning and removing nomination. This was . This one also sounds a bit similar to and which is very old. Would be nice to find if there are duplicates too.
Pinging cleanup to find duplicates ... ping cleanup
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
Triage: It's no longer ICE with the latest nightly, I think it's fixed by .

Discovered a compiler panic, thought it might relate to , but was told to post a new issue. In minimizing, it seems the generic types are required to trigger the panic, I was unable to reproduce when inlining t7p or t8n. This code panics on 1.33 - 1.35, but does not panic on 1.32 (): On 1.32: On 1.35 nightly: --Bryan
triage: P-high. Removing nominated tag since there's little to discuss beyond its P-highness. (The fact its unassigned will be discussed regardless of nomination state.)
Bisection points to i.e. as the culprit. The backtrace in that commit looks very similar to the one reported here, and the parent commit () gives the same compiler error.
I spent some time looking at this a few weeks ago but did not manage to find anything conclusive. At this point I'm going to be taking a break for a few months, so I am unassigning myself from this issue.
triage: assigning self.
triage: downgrading to P-medium; this does not warrant revisiting every week.
I was able to minify it a bit further:
Triage: It's no longer ICE with the latest nightly.

The following example ICEs yields (Same is true on stable.)
That's because the ObjectCandidate code is not normalizing the upcast trait refs. Should we wait for Chalk for the fix?
Hitting this error, any updates?
Triage: no longer ICEs.
It's still an ICE, note that we should build/run the snippet to check it ().
Triage: It's no longer ICE with the latest nightly, I think it's fixed by .
Change:
/// Strip items marked `#[doc(hidden)]` pub(crate) fn strip_hidden(krate: clean::Crate, cx: &mut DocContext<'_>) -> clean::Crate { let mut retained = ItemIdSet::default(); <ins> let is_json_output = cx.output_format.is_json() && !cx.show_coverage; </ins> // strip all #[doc(hidden)] items let krate = {

Discussion:
cc label +A-docs +A-rustdoc-ui +C-enhancement +T-rustdoc This is technically a regression, but it doesn't feel appropriate to label it as such.
Here is an example of a block that should be hidden when is not passed:
Change:
<ins> // compile-flags: --document-private-items #![deny(rustdoc::redundant_explicit_links)] pub mod webdavfs { pub struct A; pub struct B; } /// [`Vfs`][crate::Vfs] pub use webdavfs::A; //~^^ error: redundant explicit link target /// [`Vfs`] pub use webdavfs::B; pub struct Vfs; </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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(type_macros)] macro_rules! t { () => ( String ; );     //~ ERROR macro expansion ignores token `;` } fn main() { let i: Vec<t!()>;       //~ NOTE caused by the macro expansion here } </ins>

Discussion:
This compiles: I expected this to be rejected, simply because doesn't parse as a type.

afaik, it's because the context where you're using the macro (expr, item, etc.) stopped parsing before that token. We should mention that context.
Is this fixed? I think this was fixed the referenced pull request.
I'd prefer a message like
Change:
LL |           unsafe { intrinsics::ptr_offset_from(self, origin) } |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                    | <del> |                    null pointer is not allowed for this operation </del> <ins> |                    null pointer is not a valid pointer for this operation </ins> |                    inside `ptr::const_ptr::<impl *const u8>::offset_from` at $SRC_DIR/core/src/ptr/const_ptr.rs:LL:COL |                    inside `OFFSET_FROM_NULL` at $DIR/offset_from_ub.rs:36:14 |

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! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Some error message changes (cc ) broke Miri, but some "null pointer is not allowed for this operation" changes look... wrong? For example: (and many more) They are all not .
Yeah my patch makes no sense... working on a fix.
I don't think the toolstate is fixed: ! But it's just error message differences: claim
Change:
/// [`Iterator`]: trait.Iterator.html #[must_use = "iterators are lazy and do nothing unless consumed"] #[stable(feature = "iterator_flatten", since = "1.29.0")] <del> pub struct Flatten<I: Iterator> where I::Item: IntoIterator, { </del> <ins> pub struct Flatten<I: Iterator<Item: IntoIterator>> { </ins> inner: FlattenCompat<I, <I::Item as IntoIterator>::IntoIter>, }

Discussion:
Follow up of . These two particular cases could not be refactored due to an ambiguity issue: With Result (line numbers are off): With Result (line numbers are off): cc
cc also
Thanks for this report. If you/Centril/someone could produce a MCVE, I would then be happy to investigate further... right now I don't have the time to reduce it though, I'm afraid.
I tried again for an hour or two without success. Unfortunately I don't know enough about the internals to understand how this could happen. I'll look at the associated type bounds PR, maybe that will help.
This is odd; I basically pasted the code in verbatim into the , made it compile, and the made the tweaks above. The issue still won't reproduce but it does reproduce when I . Maybe this is a bootstrapping issue... in which case we'll know in a few hours.
Change:
struct Struct; impl Ambiguous<One> for Struct {} <ins> //~^ NOTE multiple `impl`s satisfying `Struct: Ambiguous<_>` found </ins> impl Ambiguous<Two> for Struct {} fn main() { <Struct as Ambiguous<_>>::method(); //~^ ERROR type annotations needed <ins> //~| NOTE cannot infer type of the type parameter `A` </ins> //~| ERROR type annotations needed <ins> //~| NOTE infer type of the type parameter `A` </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. --: This was also tried on with on Rust Playground, with the same error. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsWithout the fully qualified path, see commented code, the error is . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized: Looking into this. claim label D-incorrect
Change:
def display_hint(): return "string" <ins> def _enumerate_array_elements(element_ptrs): for (i, element_ptr) in enumerate(element_ptrs): key = "[{}]".format(i) element = element_ptr.dereference() try: # rust-lang/rust#64343: passing deref expr to `str` allows # catching exception on garbage pointer str(element) except RuntimeError: yield key, "inaccessible" break yield key, element class StdSliceProvider: def __init__(self, valobj): self.valobj = valobj self.length = int(valobj["length"]) self.data_ptr = valobj["data_ptr"] def to_string(self): return "{}(size={})".format(self.valobj.type, self.length) def children(self): return _enumerate_array_elements( self.data_ptr + index for index in xrange(self.length) ) @staticmethod def display_hint(): return "array" </ins> class StdVecProvider: def __init__(self, valobj):

Discussion:
Currently, support for pretty-printing slice types is missing for rust-gdb.
Can you describe in more detail?
provides pretty-printing function for some Rust types, such as , , , etc. This allows gdb to display values of some types in a more readable way. I think it is implemented in the following files: , , Currently, slices can only be displayed as a pointer and a length value in the debugger. I hope rust-gdb can support displaying slices. I also noticed that already supports pretty-printing const slices (), but not mutable slices (). Maybe rust-lldb can also add pretty-printing support fur mutable slices.
label A-slice C-enhancement T-dev-tools
Change:
self.drain_filter(|k, v| !f(k, v)); } <del> /// Moves all elements from `other` into `Self`, leaving `other` empty. </del> <ins> /// Moves all elements from `other` into `self`, leaving `other` empty. </ins> /// /// # Examples ///

Discussion:
See the documentation for here and for here: In both cases, the documentation refers to the object the method is called for, not the type, so it should be using the lower case . (And maybe should be in backticks here?) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label +A-docs +T-libs +E-easy
claim
Change:
enum_definition: &'v EnumDef, generics: &'v Generics, item_id: NodeId) { <del> for variant in &enum_definition.variants { visitor.visit_variant(variant, generics, item_id); } </del> <ins> walk_list!(visitor, visit_variant, &enum_definition.variants, generics, item_id); </ins> } pub fn walk_variant<'v, V: Visitor<'v>>(visitor: &mut V,

Discussion:
Namely: + maybe So, if I want to visit, for example, a and report an error, I can't do it and have to visit all its parents instead.
Change:
--> $DIR/edition-imports-virtual-2015-gated.rs:8:5 | LL |     gen_gated!(); <del> |     ^^^^^^^^^^^^^ could not find `E` in `{{root}}` </del> <ins> |     ^^^^^^^^^^^^^ could not find `E` in crate root </ins> | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

Discussion:
Test program: This produces the following error messages: Both the error and the help seem entirely unhelpful. The error suggests that it looked for a function in the crate root, but in fact it looked for a crate . The whole "possible candidate" help seems incorrect, and adding that line would lead to a compilation failure.
cc
This is still an issue, but at least the incorrect help message is no longer displayed: