jiebi/CodeConvo huggingface dataset:
Change:
I tried this code: I expected to see this happen: no bounds check Instead, this happened (with ) However adding more variants to the enum makes the bound check go away: generates: Here's a godbolt link to play around further: The MIR of the two cases is identical, but the llvm IR in ZST case is lacking , which I assume (heh!) leads to the bounds check being preserved. (However i don't actually understand LLVM, I'm just reading the diff...) rustc 1.50.0 This sounds very closely related to , but I'm not actually sure if it is. Please reroute as appropriate. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Removing any attributes from the enum also leads to the optimization occurring as expected ().
We don't emit the enum range assumption if the range only contains one element:
claim

Discussion:
let er = scalar.valid_range_exclusive(bx.cx()); if er.end != er.start <del> && scalar.valid_range.end() > scalar.valid_range.start() </del> <ins> && scalar.valid_range.end() >= scalar.valid_range.start() </ins> { // We want `table[e as usize ± k]` to not // have bound checks, and this is the most

<ins> // compile-flags: -O // min-llvm-version: 11.0 #![crate_type = "lib"] #[repr(C)] pub enum E { A, } // CHECK-LABEL: @index #[no_mangle] pub fn index(x: &[u32; 3], ind: E) -> u32{ // CHECK-NOT: panic_bounds_check x[ind as usize] } </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. 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!
The error:
See , the way to do this now is to set .
Oh oops, you already opened

Discussion:
<del> Subproject commit 3bd7215d48ba05f18401cc340ae8d71af002ba6d </del> <ins> Subproject commit fd1df1554a22accde727e8c4bdeb2a065627d10c </ins>
Change:
It suggests when it should suggest or at least suggest () Errors: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Probably the "free function without body" variant has this bug as well.
The code at issue:
I think I'll take a shot at this. claim
That was... an easy fix. to That provides this: which isn't entirely satisfactory imo cause the suggestion span is directly after the rather than a space after, but it's at least valid Rust code that can be formatted into more "properly" formatted Rust code.
It appears that it has a similar bug: Looks like this can probably be fixed similarly.
Oh wait, that bug was caused by me. It looks like I'll probably have to implement a better solution.
Okay, so it appears that this bug is triggered in inherent impls with and without a semicolon, and in free functions with a semicolon. I'll have to find some kind of way to change the span depending on if it had a semicolon or not.
Okay, so it looks like in 99% of cases that trigger the same code path as this error: free fn free const free static free type inherent const inherent fn trait const trait type trait fn the existing code is already correct, as in those cases a semicolon is (usually) required. Either we can modify the parser to give some kind of indication to the AST validator that an inherent fn/const/type has no semicolon at the end, or we can just use a hack to check if there's a semicolon at the end of the span
I'm not quite sure how this should be fixed :/
I would suggest asking in since someone there can probably give advice.

Discussion:
} fn error_item_without_body(&self, sp: Span, ctx: &str, msg: &str, sugg: &str) { <ins> let source_map = self.session.source_map(); let end = source_map.end_point(sp); let replace_span = if source_map.span_to_snippet(end).map(|s| s == ";").unwrap_or(false) { end } else { sp.shrink_to_hi() }; </ins> self.err_handler() .struct_span_err(sp, msg) .span_suggestion( <del> self.session.source_map().end_point(sp), </del> <ins> replace_span, </ins> &format!("provide a definition for the {}", ctx), sugg.to_string(), Applicability::HasPlaceholders,

--> $DIR/issue-87635.rs:4:5 | LL |     pub fn bar() <del> |     ^^^^^^^^^^^- |                | |                help: provide a definition for the function: `{ <body> }` </del> <ins> |     ^^^^^^^^^^^^- help: provide a definition for the function: `{ <body> }` </ins> error: aborting due to 2 previous errors
Change:
<!-- 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. --The code is my entire project, unfortunately. The ICE appears to be related to incremental compilation, so I'm not sure how to minimise it. (There was a large section here which is irrelevant now I have "steps to reproduce" and a repro on current nightly.) <!-- 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
modify labels +A-incr-comp +E-needs-mcve
Neither nor commit exists when I clone that repository.
Err, sorry. Not sure what happened there. Maybe I deleted the remote branch by mistake somehow. I have the commit locally so I have pushed it again. In case of other confusion I also retried my "steps to repro" and it still goes wrong as I described. Also I noticed that the commitids there have a spurious "ESC" at the end (!), the result of a git+less misbehaviour. I have deleted those from the summary above.
This will be fixed by

Discussion:
E: 'a + OpaqueEncoder, { fn encode(&self, s: &mut CacheEncoder<'a, 'tcx, E>) -> Result<(), E::Error> { <del> if *self == DUMMY_SP { </del> <ins> let span_data = self.data(); if self.is_dummy() { </ins> TAG_PARTIAL_SPAN.encode(s)?; <del> return SyntaxContext::root().encode(s); </del> <ins> return span_data.ctxt.encode(s); </ins> } <del> let span_data = self.data(); </del> let pos = s.source_map.byte_pos_to_line_and_col(span_data.lo); let partial_span = match &pos { Some((file_lo, _, _)) => !file_lo.contains(span_data.hi),

<ins> include ../../run-make-fulldeps/tools.mk # FIXME https://github.com/rust-lang/rust/issues/78911 # ignore-32bit wrong/no cross compiler and sometimes we pass wrong gcc args (-m64) # Regression test for issue #83112 # The generated test harness code contains spans with a dummy location, # but a non-dummy SyntaxContext. Previously, the incremental cache was encoding # these spans as a full span (with a source file index), instead of skipping # the encoding of the location information. If the file gest moved, the hash # of the span will be unchanged (since it has a dummy location), so the incr # cache would end up try to load a non-existent file using the previously # enccoded source file id. SRC=$(TMPDIR)/src INCR=$(TMPDIR)/incr all: mkdir $(SRC) mkdir $(SRC)/mydir mkdir $(INCR) cp main.rs $(SRC)/main.rs $(RUSTC) --test -C incremental=$(INCR) $(SRC)/main.rs mv $(SRC)/main.rs $(SRC)/mydir/main.rs $(RUSTC) --test -C incremental=$(INCR) $(SRC)/mydir/main.rs </ins>
Change:
I inadvertently deleted a assignment (which meant that any would not be resolved. Since query functions are assigned at runtime, this is not a build-time error. The best that can do is generate a runtime error, but the error message is non-intuitive, and it took quite a while for me to realize my mistake: Is there a better way to word this message to make it more obvious that there is a defined, but a provider was never assigned?
Maybe something like "no provider available for local/external crate" (depending on whether it's local or not)?
I think the reference to "crate" is what threw me off actually. To me, it implies the missing provider is missing in the code being compiled, but the problem was the provider should have been assigned in the compiler code itself.
The distinction matters though - there can be a provider for local crates but not external ones, or vice versa.
That's fine. I don't fully understand the significance of the crate, but if it helps others debug certain types of issues, it's fine to replace "unsupported by its crate" to "no provider available for local/external crate" (if the information is available). But the problem I had didn't have anything to do with the crate distinction, or at least, if it did, the message wouldn't have helped me diagnose the actual problem: In my case, there was a defined in for , and there should have been a assigned to that query, defined in the compiler code, in (except I mistakenly removed that query's assignment to . Removing that query assignment was a bug in the compiler code itself, regardless of what was happening with local vs. external crates. So how about just adding to either the current message or your revised message? I'm not sure how to tell what is local or external here, from just the or the , but I a placeholder. (AFAIK, the type is not necessarily a at this point.):
That looks good! Could you make a pr with that change? :)
- Happy to submit a PR, but I don't think exists. Is there a method that will give me something equivalent? If not, I can just use the original message, and add the to the end of it.
It's the other way around - there's only ever one , but may be local or non-local. You could add an field to , and set it in
Hmm, that actually won't work because you have to have a function pointer, not a closure - you don't have access to the current state of the struct. Using the original message seems ok; I don't know if there's a better way.
OK, will do then. Thanks!

Discussion:
fn default() -> Self { Providers { $($name: |_, key| bug!( <del> "`tcx.{}({:?})` unsupported by its crate", stringify!($name), key </del> <ins> "`tcx.{}({:?})` unsupported by its crate;  perhaps the `{}` query was never assigned a provider function", stringify!($name), key, stringify!($name), </ins> ),)* } }
Change:
For example, I would much rather have the documentation for my crate Staticvec look , as opposed to pulling in the docs for every single slice method Edit: Some additional thoughts: even if this isn't possible for some reason, it would almost certainly be better to have the crate-native "Trait Implementations" section appear before the "Methods From Deref" section does, since "Trait Implementations" will pretty much always be describing things that are unique to the crate being documented and so actually directly relevant a good idea might also be to have the "Methods From Deref" header amount to a clickable link that redirects to the actual primary docs for whatever is being derefed to in any case where it is being left empty, if that is still possible
Are there any details on when precisely this changed, also? I've noticed that even though the auto-generated docs on previously left the "Methods From Deref" section empty for user-submitted crates, it was seemingly always filled out for stuff like the official docs for , so presumably there has always been some kind of way of controlling 's behaviour in this regard, unless I'm missing something.
Yes, it was changed intentionally in and mentioned in the release notes: Vec derefs directly to slice - maybe the user crates you're talking about always deref to Vec?
:+1: I like this idea. Hmm, I'm a little concerned the methods will be harder to find that way. We get a lot of complaints that the "Trait Implementations" section is hard to read because you have to click on the name of the trait to see what methods are available.
Yeah, that makes sense. Honestly just showing before in any case where both exist would likely pretty much cover the kind of thing I was mostly concerned about by itself anyways.
Are you interested in making a PR for that? I think it would be as simple as moving after :)
Sure, I'll take a look at it tomorrow.
Got busy with some other stuff, but I've now opened a PR that make those changes, which do accomplish what you thought they would.

Discussion:
} if v.iter().any(|i| i.inner_impl().trait_.is_some()) { <del> if let Some(impl_) = v .iter() .filter(|i| i.inner_impl().trait_.is_some()) .find(|i| i.inner_impl().trait_.def_id_full(cache) == cx.cache.deref_trait_did) { sidebar_deref_methods(cx, out, impl_, v); } </del> let format_impls = |impls: Vec<&Impl>| { let mut links = FxHashSet::default();

); write_sidebar_links(out, blanket_format); } <ins> if let Some(impl_) = v .iter() .filter(|i| i.inner_impl().trait_.is_some()) .find(|i| i.inner_impl().trait_.def_id_full(cache) == cx.cache.deref_trait_did) { sidebar_deref_methods(cx, out, impl_, v); } </ins> } } }
Change:
Specialized slice::fill implementations are not inlined even though they would compile down to pretty much just a single memset-call. The function below represents manual inlining of . () I haven’t tested it in any way, but I suspect that this can be fixed by marking as . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: C-enhancement, T-libs-impl, I-slow, E-easy
claim
Don't you need at the very least (but not necessarily ) to actually guarantee cross-crate-inlining eligibility with the default no-LTO profile? It'd certainly make sense to add that to all of the impls in IMO.
It being generic is sufficient for being eligible because the monomorphized function is only created in the consuming crate once all the generics have been filled in. Adding on top just encourages it further.

Discussion:
rotate!(rotate_16_usize_5, 16, |i| [i; 5]); rotate!(rotate_64_usize_4, 64, |i| [i; 4]); rotate!(rotate_64_usize_5, 64, |i| [i; 5]); <ins> #[bench] fn fill_byte_sized(b: &mut Bencher) { #[derive(Copy, Clone)] struct NewType(u8); let mut ary = [NewType(0); 1024]; b.iter(|| { let slice = &mut ary[..]; black_box(slice.fill(black_box(NewType(42)))); }); } </ins>

<ins> use crate::mem::{size_of, transmute_copy}; </ins> use crate::ptr::write_bytes; pub(super) trait SpecFill<T> {

} impl<T: Copy> SpecFill<T> for [T] { <del> default fn spec_fill(&mut self, value: T) { for item in self.iter_mut() { *item = value; } } } impl SpecFill<u8> for [u8] { fn spec_fill(&mut self, value: u8) { // SAFETY: this is slice of u8 unsafe { let ptr = self.as_mut_ptr(); let len = self.len(); write_bytes(ptr, value, len); } } } impl SpecFill<i8> for [i8] { fn spec_fill(&mut self, value: i8) { // SAFETY: this is slice of i8 unsafe { let ptr = self.as_mut_ptr(); let len = self.len(); write_bytes(ptr, value as u8, len); } } } impl SpecFill<bool> for [bool] { fn spec_fill(&mut self, value: bool) { // SAFETY: this is slice of bool unsafe { let ptr = self.as_mut_ptr(); let len = self.len(); write_bytes(ptr, value as u8, len); </del> <ins> fn spec_fill(&mut self, value: T) { if size_of::<T>() == 1 { // SAFETY: The size_of check above ensures that values are 1 byte wide, as required // for the transmute and write_bytes unsafe { let value: u8 = transmute_copy(&value); write_bytes(self.as_mut_ptr(), value, self.len()); } } else { for item in self.iter_mut() { *item = value; } </ins> } } }
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. 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!
It looks like miri just has one instance of , which should be replaced with . Should be easy enough.
This can be closed when the miri submodule is bumped.

Discussion:
<del> Subproject commit ae964207bb17911cf96d9744d9469fa2734093a8 </del> <ins> Subproject commit 12dac5c0f7acd106401aa14fec758f0ff552f678 </ins>
Change:
Code that generated this error is available here: I am happy to spend some time trying to create a smaller repro but it will take me a few days. This error is reproducible on my machine. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
FYI, with this code compiled.
Minimized: Similar error was reported in . The issue is in code that attempts to suggest a different method, that might potentially return items. In that particular case there are no other suggestions to make, but code will attempt to emit diagnostic anyway, eventually failing the assertion: label: +E-easy
claim
label +regression-from-stable-to-beta
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium

Discussion:
.starts_with(&original_method_ident.name.to_string()) }) .map(|ident| format!("{}()", ident)) <ins> .peekable() </ins> }); <del> if let Some(suggestions) = opt_suggestions { err.span_suggestions( path_segment.ident.span, &format!("use mutable method"), suggestions, Applicability::MaybeIncorrect, ); </del> <ins> if let Some(mut suggestions) = opt_suggestions { if suggestions.peek().is_some() { err.span_suggestions( path_segment.ident.span, &format!("use mutable method"), suggestions, Applicability::MaybeIncorrect, ); } </ins> } } };

<ins> // rust-lang/rust#83309: The compiler tries to suggest potential // methods that return `&mut` items. However, when it doesn't // find such methods, it still tries to add suggestions // which then fails an assertion later because there was // no suggestions to make. fn main() { for v in Query.iter_mut() { //~^ NOTE this iterator yields `&` references *v -= 1; //~^ ERROR cannot assign to `*v` which is behind a `&` reference //~| NOTE `v` is a `&` reference, so the data it refers to cannot be written } } pub struct Query; pub struct QueryIter<'a>(&'a i32); impl Query { pub fn iter_mut<'a>(&'a mut self) -> QueryIter<'a> { todo!(); } } impl<'a> Iterator for QueryIter<'a> { type Item = &'a i32; fn next(&mut self) -> Option<Self::Item> { todo!(); } } </ins>

<ins> error[E0594]: cannot assign to `*v` which is behind a `&` reference --> $DIR/issue-83309-ice-immut-in-for-loop.rs:11:9 | LL |     for v in Query.iter_mut() { |              ---------------- this iterator yields `&` references LL | LL |         *v -= 1; |         ^^^^^^^ `v` is a `&` reference, so the data it refers to cannot be written error: aborting due to previous error For more information about this error, try `rustc --explain E0594`. </ins>
Change:
Happens on stable and nightly. Compiler crash <details<summary<strongBacktrace</strong</summary<p</p</details
This regression looks to be really old. Could not pinpoint a specific commit while bisecting
I don't think this is a regression, the flag just didn't exist before 1.31 (the panic doesn't occur without ).
Assigning and removing as in the prioritization working group. label: +P-low -I-prioritize

Discussion:
} return None; } <del> PathResult::NonModule(path_res) if path_res.base_res() == Res::Err => { </del> <ins> PathResult::NonModule(_) => { </ins> if no_ambiguity { assert!(import.imported_module.get().is_none()); } // The error was already reported earlier. return None; } <del> PathResult::Indeterminate | PathResult::NonModule(..) => unreachable!(), </del> <ins> PathResult::Indeterminate => unreachable!(), </ins> }; let (ident, target, source_bindings, target_bindings, type_ns_only) = match import.kind {

<ins> use clippy::a; //~ ERROR unresolved import `clippy` use clippy::a::b; //~ ERROR failed to resolve: maybe a missing crate `clippy`? use rustdoc::a; //~ ERROR unresolved import `rustdoc` use rustdoc::a::b; //~ ERROR failed to resolve: maybe a missing crate `rustdoc`? fn main() {} </ins>

<ins> error[E0433]: failed to resolve: maybe a missing crate `clippy`? --> $DIR/tool-mod-child.rs:2:5 | LL | use clippy::a::b; |     ^^^^^^ maybe a missing crate `clippy`? error[E0432]: unresolved import `clippy` --> $DIR/tool-mod-child.rs:1:5 | LL | use clippy::a; |     ^^^^^^ maybe a missing crate `clippy`? error[E0433]: failed to resolve: maybe a missing crate `rustdoc`? --> $DIR/tool-mod-child.rs:5:5 | LL | use rustdoc::a::b; |     ^^^^^^^ maybe a missing crate `rustdoc`? error[E0432]: unresolved import `rustdoc` --> $DIR/tool-mod-child.rs:4:5 | LL | use rustdoc::a; |     ^^^^^^^ maybe a missing crate `rustdoc`? error: aborting due to 4 previous errors Some errors have detailed explanations: E0432, E0433. For more information about an error, try `rustc --explain E0432`. </ins>
Change:
It should say instead.
Relevant code: I think the fix is to use the crate name instead of .
Also, I would be curious to see if you can remove altogether by using : That might break renamed modules maybe? I don't remember how modules interact with re-exports.

Discussion:
self.primitive_locations.insert(prim, def_id); } <del> self.stack.push(krate.name.to_string()); </del> krate = CacheBuilder { tcx, cache: self, empty_cache: Cache::default() }.fold_crate(krate); for (trait_did, dids, impl_) in self.orphan_trait_impls.drain(..) {

&Spanned { span: rustc_span::DUMMY_SP, node: hir::VisibilityKind::Public }, hir::CRATE_HIR_ID, &krate.item.module, <del> None, </del> <ins> Some(self.cx.tcx.crate_name), </ins> ); top_level_module.is_crate = true; // Attach the crate's exported macros to the top-level module.

<ins> // check-pass //! [my_module] //~^ WARN public documentation for `private_from_crate_level` links to private item `my_module` mod my_module {} </ins>

<ins> warning: public documentation for `private_from_crate_level` links to private item `my_module` --> $DIR/private-from-crate-level.rs:3:6 | LL | //! [my_module] |      ^^^^^^^^^ this item is private | = note: `#[warn(rustdoc::private_intra_doc_links)]` on by default = note: this link will resolve properly if you pass `--document-private-items` warning: 1 warning emitted </ins>
Change:
try returns a value of type . It actually returns where T is whatever the closure passed to it returns.

Discussion:
While it isn't possible for a task to recover from failure, tasks may notify each other of failure. The simplest way of handling task failure is with the `try` function, which is similar to `spawn`, but immediately blocks waiting <del> for the child task to finish. `try` returns a value of type `Result<int, </del> <ins> for the child task to finish. `try` returns a value of type `Result<T, </ins> ()>`. `Result` is an `enum` type with two variants: `Ok` and `Err`. In this case, because the type arguments to `Result` are `int` and `()`, callers can pattern-match on a result to check whether it's an `Ok` result with an `int`
Change:
When documenting the handling of whitespace in the crate, I noticed that whitespace is collapsed in inline code. That is, is rendered the same as Test it with It worked on Rust 1.50: ! It stopped working on Rust 1.51. I tracked down the change to , which removed from the CSS. The page now looks like this: !
Note that a fix here could potentially create a regression for ascii art on mobile. Need to double check the vec page.
Assigning and removing as in the prioritization working group. label: +P-high -I-prioritize

Discussion:
text-overflow: ellipsis; margin: 0; } <del> .docblock-short code { </del> <ins> /* Wrap non-pre code blocks (`text`) but not (```text```). */ .docblock > :not(pre) > code, .docblock-short > :not(pre) > code { </ins> white-space: pre-wrap; }