jiebi/CodeConvo huggingface dataset:
Change:
padding: 0; white-space: pre-wrap; } <ins> .structfield { margin: 0.6em 0; } </ins> #crate-search, h1, h2, h3, h4, h5, h6,

Discussion:
Sample at <img width="1066" alt="image" src=""Headings seem too close to the paragraphs around them, enough so that paragraph breaks stand out more than field breaks. Testing with , I think this makes sections stand out better: <img width="1023" alt="image" src=""
If somebody points me in the right direction then I can do this (unless somebody beats me to it, feel free).
I'm no rustdoc expert but this is the template that seems to be rendering the HTML in question: It might also help to just search for "structfield" under src/librustdoc in the repo.
Thanks for taking a look - aiui that is indeed where the HTML comes from, but I was less certain about the CSS. seems like a reasonable guess, but I just wanted to double check styles aren't applied in JS or something like that (I assume themes are but maybe not layout?).
Change:
CrateError::NonDylibPlugin(crate_name) => { sess.emit_err(errors::NoDylibPlugin { span, crate_name }); } <ins> CrateError::NotFound(crate_name) => { sess.emit_err(errors::CannotFindCrate { span, crate_name, add_info: String::new(), missing_core, current_crate: sess.opts.crate_name.clone().unwrap_or("<unknown>".to_string()), is_nightly_build: sess.is_nightly_build(), profiler_runtime: Symbol::intern(&sess.opts.unstable_opts.profiler_runtime), locator_triple: sess.opts.target_triple.clone(), }); } </ins> } } }

Discussion:
I decided to try address sanitizer on WSL Ubuntu today, but ran into 2 errors. These errors are only present when using the sanitizer, so my crate compiles normally. To give context there are 2 crates: and . On there is a procedural macro called , which is named the same as my crate which I am re-exporting it to. I don't really know if this a bug or a problem on my end, but I thought I'd mention it just in case. : I included the full error output in a file below
If you use sanitizers you need to pass the flag, but I guess you missed it. See also :
Oh I did miss it and that fixed it. The documentation made it sound optional though, so I didn't realize that was the issue. Thanks for the quick reply!
Re-opening because the error is very confusing. See also
On the error is: which isn't great, but at least suggests some issue related to asan. On the error is: Which is very confusing. was merged between those two versions and changes in which cases E0519 is emitted. ping who wrote that PR.
Change:
| (2<sup>30</sup>) - 1 |      | 5                    | | ...                  | ...  | ...                  | | 12                   | g    | 100                  | <del> | 11                   | f    | 4                    | </del> <ins> | 11                   | f    | 9                    | </ins> | 10                   | e    | 9                    | | 9                    | d    | (2<sup>30</sup>) - 1 | | 8                    | c    | 5                    |

Discussion:
At the end of bar(), it calls baz(): In the code baz is passed f whose value is the address of d which is 9. However, in the diagram, it is given a value of 4.
I believe this is fixed on master, can you confirm?
I believe it should say 11 f 9 not 11 f 4
not fixed on master but just filed a PR to do so
Change:
true } <ins> // Check from a list of attributes if it contains the appropriate // `#[level(lintname)]` attribute (e.g. `#[allow(dead_code)]). pub fn contains_lint(attrs: &[ast::Attribute], level: level, lintname: &'static str) -> bool { let level_name = level_to_str(level); for attr in attrs.iter().filter(|m| level_name == m.name()) { if attr.meta_item_list().is_none() { continue } let list = attr.meta_item_list().unwrap(); for meta_item in list.iter() { if lintname == meta_item.name() { return true; } } } false } </ins> fn check_while_true_expr(cx: &Context, e: &ast::Expr) { match e.node { ast::ExprWhile(cond, _) => {

Discussion:
Currently if you have some dead_code and you want to preserve it, you have to annotate every function you want to preserve and all the dead code that function calls. I think we should consider annotated code to be alive, and then all the code that touches to be alive as well.
cc sounds like a cool idea to me.
By "annotate", do you mean putting an attribute above the function you want to preserve?
yes.
Change:
// Links to trait implementations in the sidebar should not wrap even if they are long. goto: file://|DOC_PATH|/lib2/struct.HasALongTraitWithParams.html assert-property: (".sidebar-links a", {"offsetHeight": 29}) <ins> // Test that clicking on of the "In <module>" headings in the sidebar links to the // appropriate anchor in index.html. goto: file://|DOC_PATH|/test_docs/struct.Foo.html click: ".block.mod h3 a" // PAGE: index.html assert-css: ("#modules", {"background-color": "rgb(253, 255, 211)"}) </ins>

Discussion:
In rustdoc sidebars, most headings are clickable links. For instance, "Required Methods" and "Implementors" in the sidebar of However, the headings under "Other items in..." are not clickable. We should link those to the appropriate subheading on the module page. That allows the user to see a more verbose listing of items in the module, since each one has a description alongside it. <img width=150 src="https://user-"<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
So, for instance, sidebar heading should lead ?
claim
Yes, that's correct.
By the way be aware this will conflict with Resolving the conflict should be pretty easy though.
Thanks
any progress on this? I'd like to get it landed before the beta cut, so we have a consistent UI where headings in the sidebar are clickable.
sorry, i couldn't make time last ,i will unassign me, thanks.
Change:
self.mode = mode as mode_t; } <del> pub fn as_flags(&self) -> io::Result<c_int> { let access_mode = self.get_access_mode()?; let creation_mode = self.get_creation_mode()?; Ok(creation_mode | access_mode | self.custom_flags) } </del> fn get_access_mode(&self) -> io::Result<c_int> { match (self.read, self.write, self.append) { (true, false, false) => Ok(libc::O_RDONLY),

Discussion:
The following code compiles fine with nightly-2020-09-22 (and stable rustc since 1.10.0) but not nightly-2020-09-23. This is minimized from Mentioning , ,
Whoops, I didn't realize the trait itself was stable. Probably the PR should either be reverted or add a default implementation for .
Assigning P-critical as as part of the Prioritization Working Group procedure and removing I-prioritize.
is now broken on nightly as well:
I was under the impression that the traits were not intended to be implemented outside of which means this is really an issue with which shouldn't have implemented at all.  for example has had several methods to it since 1.0. Is there something different with or is this just that it was implemented by a popular crate?
The trait likely should have been , but I think sealed traits were not invented until after 1.0.0.
Can we retroactively seal ? It seems like we should, if we keep adding methods like in
Wouldn't that be a breaking change?
Yes, just like adding more methods to it (which has been done several times)
We could do a crater run to see if sealing it would break anything.
Well clearly it would - it would break async-std the same way broke async std. We need to get them not to use before we can change anything here.
My comment was in reference to sealing , not .
Change:
// run-fail <del> // error-pattern:assertion failed: `(left != right)` // error-pattern: left: `2` // error-pattern:right: `2`: 1 + 1 definitely should not be 2 </del> <ins> // error-pattern:assertion `left != right` failed: 1 + 1 definitely should not be 2 // error-pattern:  left: 2 // error-pattern: right: 2 </ins> // ignore-emscripten no processes fn main() {

Discussion:
The custom message in macro is shown right after the . This is hard to read because the value strings could be very long. I think it is better to print the custom message (if available) on a separate line. The above (playground) prints this: Note that custom message and the location in source are still on the same line <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I will try it. claim
Note that the linked PR, , has a lot of review comments. I think rebasing that PR and addressing the comments would already be very close to landing this change.
(taking over due to inactivity) claim
:tada: Horray! It only took 548 days (1.5+ years) since I created on Feb 14th, 2022. Numerous commits. Tens of people. 4 PRs... 100s of files. All to change a few lines of output :) Special thanks to for all the support!
Change:
} pub fn into_iter(self) -> MoveEntries<K, V> { <ins> let RawBuckets { raw, hashes_end, .. } = self.raw_buckets(); // Replace the marker regardless of lifetime bounds on parameters. </ins> MoveEntries { <del> iter: self.raw_buckets(), </del> <ins> iter: RawBuckets { raw: raw, hashes_end: hashes_end, marker: marker::ContravariantLifetime, }, </ins> table: self, } }

Discussion:
Sorry, I'm not sure how to describe this very well in a sentence. I am able to mutably borrow the innermost values of a , delete the values, then reference them after they were deleted. This code compiles, runs, and barfs out strange numbers.
Little bit shorter example, without mutable borrows. But still fails to freeze :
nominating for 1.0 P-backcompat-lang
though this may be a library issue
weird This code is also valid: This is because the hashmap iterator just wraps the rawtable iterator, which just defers to the RawBuckets iterator, which is just a wrapper around two *mut's. That is, literally none of these iterators actually borrows the hashmap. Presumably this is fixable by taking a useless reference somewhere. The other thing I'm seeing is that there's , but the signature for Hashmap's iterator function is . How is this lifetime being elided? Is it doing the same thing as , or is something else happening? CC
Yep, it's eliding !
So there's two bugs here: the iterator doesn't borrow the map, and the references are being yielded as .
Assigning P-backcompat-libs, 1.0
thanks for fixing this! Great job!
Change:
} } <ins> if matches!(mode, Mode::Std) { if let Some(mir_opt_level) = self.config.rust_validate_mir_opts { rustflags.arg("-Zvalidate-mir"); rustflags.arg(&format!("-Zmir-opt-level={}", mir_opt_level)); } } </ins> Cargo { command: cargo, rustflags, rustdocflags, allow_features } }

Discussion:
Because currently it doesn't. has a handful of problems which are reported elsewhere, but discovering problems with MIR optimizations is often as simple as building the compiler with the optimization enabled and . So we should do that in CI. Note that all MIR opt levels are supposed to be sound, and known unsoundness is supposed to be gated behind , which I am not suggesting we test with. Currently attempting to build the standard library with these flags results in pages of this error: Which looks to me like <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
also mentioned to me that some opts are using as a minimum threshold, it may be helpful to test that as well (maybe in a separate builder). does not change the output of the compiler and should be ok to turn on unconditionally for libstd; we might want to be more selective about where we enable it for the compiler itself, though, since it's a lot slower. We should also have at least one builder where we enable for UI tests.
Mentoring instructions: new option to and This option should pass unconditionally for libstd. Test it works locally with , you should see the ICE posted above. that new option on all builders around here: You can test that works by opening a PR (please put in the description) and making sure it shows the same ICE. that works, we can figure out whether we want to enable this for rustc as well on some builders; maybe we should have separate and configs? And for turning it on in compiletest?
claim
Reproduced it on the PR.
Change:
renamed) ); } <del> FoundConst(def, lp) if mode == RefutableMode => { </del> <ins> FoundConst(def, lp) if const_ok => { </ins> debug!("(resolving pattern) resolving `{}` to  constant", renamed);

Discussion:
This is accepted, but probably shouldn't be. (A normal declaration of a variable named None is rejected.)
Related testcase:
That second case is unrelated. (And really weird, I'm not even sure how that's happening!)
Change:
<ins> // compile-flags: -g -Zmir-opt-level=0 -Zmir-enable-passes=+ScalarReplacementOfAggregates // compile-flags: -Cno-prepopulate-passes // // Tested offsets are only correct for x86_64. // only-x86_64 #![crate_type = "lib"] pub struct ExtraSlice<'input> { slice: &'input [u8], extra: u32, } #[no_mangle] pub fn extra(s: &[u8]) { // CHECK: void @extra( // CHECK: %slice.dbg.spill1 = alloca i32, // CHECK: %slice.dbg.spill = alloca { ptr, i64 }, // CHECK: %s.dbg.spill = alloca { ptr, i64 }, // CHECK: call void @llvm.dbg.declare(metadata ptr %s.dbg.spill, metadata ![[S_EXTRA:.*]], metadata !DIExpression()), // CHECK: call void @llvm.dbg.declare(metadata ptr %slice.dbg.spill, metadata ![[SLICE_EXTRA:.*]], metadata !DIExpression(DW_OP_LLVM_fragment, 0, 128)), // CHECK: call void @llvm.dbg.declare(metadata ptr %slice.dbg.spill1, metadata ![[SLICE_EXTRA]], metadata !DIExpression(DW_OP_LLVM_fragment, 128, 32)), let slice = ExtraSlice { slice: s, extra: s.len() as u32 }; } struct Zst; pub struct ZstSlice<'input> { slice: &'input [u8], extra: Zst, } #[no_mangle] pub fn zst(s: &[u8]) { // The field `extra` is a ZST. The fragment for the field `slice` encompasses the whole // variable, so is not a fragment. In that case, the variable must have no fragment. // CHECK: void @zst( // CHECK-NOT: call void @llvm.dbg.declare(metadata ptr %slice.dbg.spill, metadata !{}, metadata !DIExpression(DW_OP_LLVM_fragment, // CHECK: call void @llvm.dbg.declare(metadata ptr %{{.*}}, metadata ![[SLICE_ZST:.*]], metadata !DIExpression()), // CHECK-NOT: call void @llvm.dbg.declare(metadata ptr %{{.*}}, metadata ![[SLICE_ZST]], let slice = ZstSlice { slice: s, extra: Zst }; } // CHECK: ![[S_EXTRA]] = !DILocalVariable(name: "s", // CHECK: ![[SLICE_EXTRA]] = !DILocalVariable(name: "slice", </ins>

Discussion:
Building Firefox for the thumbv7neon-linux-androideabi and i686-linux-android fails with a rust compiler crash: I wish I could give something more detailed, but I haven't had the time to try to yet. I however identified the regression to come from (Enable ScalarReplacementOfAggregates in optimized builds) and building with avoids the crash.
Duplicate of
going to close as such. thanks for reporting !
Change:
(format!("use of undeclared crate or module `{}`", ident), None) } } else { <del> let mut msg = format!("could not find `{}` in `{}`", ident, path[i - 1].ident); </del> <ins> let parent = path[i - 1].ident.name; let parent = if parent == kw::PathRoot { "crate root".to_owned() } else { format!("`{}`", parent) }; let mut msg = format!("could not find `{}` in {}", ident, parent); </ins> if ns == TypeNS || ns == ValueNS { let ns_to_try = if ns == TypeNS { ValueNS } else { TypeNS }; if let FindBindingResult::Binding(Ok(binding)) =

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:
Change:
fn consume(&mut self, amt: usize) { self.pos += amt as u64; } } <ins> // Non-resizing write implementation fn slice_write(pos_mut: &mut u64, slice: &mut [u8], buf: &[u8]) -> io::Result<usize> { let pos = cmp::min(*pos_mut, slice.len() as u64); let amt = (&mut slice[(pos as usize)..]).write(buf)?; *pos_mut += amt as u64; Ok(amt) } // Resizing write implementation fn vec_write(pos_mut: &mut u64, vec: &mut Vec<u8>, buf: &[u8]) -> io::Result<usize> { let pos: usize = (*pos_mut).try_into().map_err(|_| { Error::new(ErrorKind::InvalidInput, "cursor position exceeds maximum possible vector length") })?; // Make sure the internal buffer is as least as big as where we // currently are let len = vec.len(); if len < pos { // use `resize` so that the zero filling is as efficient as possible vec.resize(pos, 0); } // Figure out what bytes will be used to overwrite what's currently // there (left), and what will be appended on the end (right) { let space = vec.len() - pos; let (left, right) = buf.split_at(cmp::min(space, buf.len())); vec[pos..pos + left.len()].copy_from_slice(left); vec.extend_from_slice(right); } // Bump us forward *pos_mut = (pos + buf.len()) as u64; Ok(buf.len()) } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl<'a> Write for Cursor<&'a mut [u8]> { #[inline] <del> fn write(&mut self, data: &[u8]) -> io::Result<usize> { let pos = cmp::min(self.pos, self.inner.len() as u64); let amt = (&mut self.inner[(pos as usize)..]).write(data)?; self.pos += amt as u64; Ok(amt) </del> <ins> fn write(&mut self, buf: &[u8]) -> io::Result<usize> { slice_write(&mut self.pos, self.inner, buf) } fn flush(&mut self) -> io::Result<()> { Ok(()) } } #[unstable(feature = "cursor_mut_vec", issue = "30132")] impl<'a> Write for Cursor<&'a mut Vec<u8>> { fn write(&mut self, buf: &[u8]) -> io::Result<usize> { vec_write(&mut self.pos, self.inner, buf) </ins> } fn flush(&mut self) -> io::Result<()> { Ok(()) } }

Discussion:
It is currently impossible to use a std::io::Cursor over a Vec in a smart pointer (Mutex, RefCell, ...) in a sane way. Please implement Read/Write/... over Cursor<&'a mut Vec<u8. Discussed on .
Good workaround is to call the function on the mutable Vec reference when creating the Cursor. Then you'll have and Read/Write is implemented.
AFAICT, adding such an impl is a breaking change:
New implementations are allowed to cause inference breakage.
Seems reasonable. I would be interested in seeing a PR that implements this.
Change:
cfg_checker.check_cleanup_control_flow(); // Also run the TypeChecker. <del> for (location, msg) in validate_types(tcx, self.mir_phase, param_env, body) { </del> <ins> for (location, msg) in validate_types(tcx, self.mir_phase, param_env, body, body) { </ins> cfg_checker.fail(location, msg); }

Discussion:
on commit If you don't set a you will OOM while optimizing syn with these very silly flags. I also have another example of this that produces a "but found ConstICE. They look similar, I'll post the other one later if someone wants.
I've been able to minimize to this:
Here is a further minimized -only repro: The came out of the innards of . The use of is not critical, but the use of a type with both a lifetime and a type generic is; for example, will do too. Tested with the above RUSTFLAGS, under . T/ <details<summaryBacktrace</summary</details
Change:
<ins> // min-llvm-version: 15.0.0 // compile-flags: -O #![crate_type = "lib"] #[no_mangle] pub fn u16_be_to_arch(mut data: [u8; 2]) -> [u8; 2] { // CHECK-LABEL: @u16_be_to_arch // CHECK: @llvm.bswap.i16 data.reverse(); data } #[no_mangle] pub fn u32_be_to_arch(mut data: [u8; 4]) -> [u8; 4] { // CHECK-LABEL: @u32_be_to_arch // CHECK: @llvm.bswap.i32 data.reverse(); data } </ins>

Discussion:
I was experimenting with some code on godbolt, when encountering this: with produces the expected assembly: However, when adding (into the same file) this function: The previous function's codegen changes to The issue: it stores the result on the stack, and then immediately discards that. (which it didn't do previously) The second potential issue I'm unsure about is, that here a function's codegen changes by just adding removing seemingly unrelated functions. I was told on discord this is because the two functions use the same , and adding the second one forces to be generalized to and as opposed to just . But I by far don't know enough to judge whether this is a problem or not, or what it's caused by, but I wanted to mention it.
label +A-codegen +I-slow +T-compiler
What's really weird is that on , it looks like this: But for , we get this:
The reason why the second call makes a difference is that IPSCCP is no longer able to propagate the slice length into various functions early.
I would probably blame this one a LoopDeletion/SROA interaction. LoopDeletion leaves behind this code: And SROA runs directly afterwards, before the phi has been folded, so we don't know that the GEPs actually access constant offsets. Possibly the backedge-breaking in LoopDeletion should also perform some folding, or we need a phase ordering change.
Or possibly IndVars should already be replacing the PHI. Just remembered that we have the replaceLoopPHINodesWithPreheaderValues() transform, which seems like it should be taking care of this.
and together should fix this.
Change:
= note: the only supported types are integers, `bool` and `char` = help: more complex types are supported with `#![feature(adt_const_params)]` <del> error[E0015]: cannot call non-const fn `Foo::{constant#0}::Foo::<17_usize>::value` in constants --> $DIR/nested-type.rs:15:5 | LL |     Foo::<17>::value() |     ^^^^^^^^^^^^^^^^^^ | = note: calls in constants are limited to constant functions, tuple structs and tuple variants error: aborting due to 2 previous errors </del> <ins> error: aborting due to previous error </ins> <del> For more information about this error, try `rustc --explain E0015`. </del>

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:
ObligationCauseCode::BinOp { rhs_span: Some(span), is_lit, .. } if *is_lit => span, _ => return, }; <del> match ( trait_ref.skip_binder().self_ty().kind(), trait_ref.skip_binder().substs.type_at(1).kind(), ) { (ty::Float(_), ty::Infer(InferTy::IntVar(_))) => { err.span_suggestion_verbose( rhs_span.shrink_to_hi(), "consider using a floating-point literal by writing it with `.0`", ".0", Applicability::MaybeIncorrect, ); } _ => {} </del> <ins> if let ty::Float(_) = trait_ref.skip_binder().self_ty().kind() && let ty::Infer(InferTy::IntVar(_)) = trait_ref.skip_binder().substs.type_at(1).kind() { err.span_suggestion_verbose( rhs_span.shrink_to_hi(), "consider using a floating-point literal by writing it with `.0`", ".0", Applicability::MaybeIncorrect, ); </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. --found via fuzzing <!-- 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
It seems that the ICE does not need and no_core feature. A little bit smaller example is: