jiebi/CodeConvo huggingface dataset:
Change:
sys::args::init(argc, argv); // Let's run some code! <del> let exit_code = panic::catch_unwind(|| { sys_common::backtrace::__rust_begin_short_backtrace(move || main()) }); </del> <ins> let exit_code = panic::catch_unwind(main); </ins> sys_common::cleanup(); exit_code.unwrap_or(101) as isize

Discussion:
v.s. is less verbose, but I remember it also filtering out some stack frames in some previous compiler versions. (Only frame # 6 is really useful to me here.) Indeed, contains some code that looks for a symbol on the stack to find out what to filter. It looks like some functionality has regressed. Stepping through the program in gdb it looks like the function is called, but despite there’s apparently no stack frame (anymore?) for it. CC and for , , and .
contains a fix for this
Now being worked on in instead afaict?
It is.
This issue hasn't been active in almost two years, and so have the issues linked here. Is there any intention of resuming work on this? It's mostly a small papercut because currently when crashing, programs suggest: run with environment variable to display a backtrace. and after setting that, also claim that: Some details are omitted, run with for a verbose backtrace. even though no details were omitted at all (which is the issue of course)
A simple fix would be to just look for "std::rt::lang_start::{{closure}}" instead until the real solution to the disappearing function is found..
This single fix is likely to have the biggest positive effect on my use of Rust since async/await. Thank you so much!
Awesome! I'm happy to see this finally fixed :D Thanks to everyone who had a part in this fix :)
Change:
<del> Subproject commit 300b5ec61ef38855a07e6bb4955a37aa1c414c00 </del> <ins> Subproject commit 5b2eee7eed72b4894909c5eecbf014ea0b5ad995 </ins>

Discussion:
The 1.66.0 release broke something around the flag to . If I download and extract , and then run, say it errors out with The same thing happens when other components are named in . The install completes successfully when isn't used. It appears the problem is with the new component, because the install is successful with
I think given the workaround this is P-low.
Note that the workaround doesn't work when combined with , so:
also appears to be broken:
Oh: probably not yet:
I think you should reprioritize this issue as this workaround doesn't work when other components are mentioned in argument as mentioned by This issue affects building our internal rust Docker image.
is a potential fix, we'll see if we can get it reviewed. I believe, based on looking at the code, the workaround of passing full names (e.g., rust-analyzer-preview rather than rust-analyzer) or similar should work. makes that required for any effect at all. I'm not quite sure what changed with the addition of rust-docs-json-preview, it might be mostly coincidence that this actually had an effect on your particular invocations.
Should that PR be tagged relnotes? Feels like it may be useful to call out for anyone using
Tagged!
As Rust 1.66.1 still broken, workaround: Other components can be just after the , eg:
We'll aim to backport the PR for 1.67, but we didn't include it in 1.66.1, so that's not surprising that nothing changed.
Change:
resolve_indeterminate = cannot determine resolution for the visibility <ins> resolve_tool_module_imported = cannot use a tool module through an import .note = the tool module imported here </ins> resolve_module_only = visibility must resolve to a module

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
works with any tool attr also compiles but it probably... shouldn't.
label +S-bug-has-mcve
Triaged with . Steps performed: Reproduced: Formatted: No change, already formatted Reduced: Bisected: Regression in nightly-2022-04-17 couldn't nail down the particular commit: <details<summaryDetails</summary<prustc version: Icemelter version: v0.2.0 Icemelter command line: Do you have feedback about this report? Please ! </p</details
another one `
Change:
#[unstable(feature = "vec_split_at_spare", issue = "81944")] #[inline] pub fn split_at_spare_mut(&mut self) -> (&mut [T], &mut [MaybeUninit<T>]) { <ins> // SAFETY: // - len is ignored and so never changed let (init, spare, _) = unsafe { self.split_at_spare_mut_with_len() }; (init, spare) } /// Safety: changing returned .2 (&mut usize) is considered the same as calling `.set_len(_)`. /// /// This method is used to have unique access to all vec parts at once in `extend_from_within`. unsafe fn split_at_spare_mut_with_len( &mut self, ) -> (&mut [T], &mut [MaybeUninit<T>], &mut usize) { </ins> let Range { start: ptr, end: spare_ptr } = self.as_mut_ptr_range(); let spare_ptr = spare_ptr.cast::<MaybeUninit<T>>(); let spare_len = self.buf.capacity() - self.len;

Discussion:
Looking here, the internal length of the vector is only adjusted at the end of the loop This has the caveat that if cloning panics, the Vec will start to unwind and only drop the first elements which doesn't include the most recently appended ones. Something more in line with how the stdlib does things might look like this: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is not unsafe, leaking items is safe:
Sure; never said it was unsafe. This is more about making sure programs who gracefully handle panics don't wind up eventually exhausting resources.
Assigning as part of the .
I would like to fix this claim
The fix seems pretty straight-forward. The Clone specialization just needs a RAII type that handles adjusting the Vec's new len in its Drop implementation, as I've linked in my MiniVec. Copy can't fail so there's no need to adjust that specialization. The only thing that could theoretically panic in that case would be reallocating and in that case, there's no need to worry about the len.
Change:
<ins> // Copyright 2016 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. // aux-build:issue-26606-macro.rs // ignore-cross-compile // build-aux-docs // @has issue_26606_macro/macro.make_item!.html #[macro_use] extern crate issue_26606_macro; // @has issue_26606/constant.FOO.html // @!has - '//a/@href' '../src/' make_item!(FOO); </ins>

Discussion:
The "src" link at the top goes to the incorrect URL:
Can you please file this against instead? This tracker is just for Rust itself. Thanks!
This is a bug in rustdoc afaict.
Ah! Sorry about that
Might be related to
Change:
/// FIXME #4948: Reuse ribs to avoid allocation. ribs: PerNS<Vec<Rib<'a>>>, <ins> /// Previous poped `rib`, only used for diagnostic. last_block_rib: Option<Rib<'a>>, </ins> /// The current set of local scopes, for labels. label_ribs: Vec<Rib<'a, NodeId>>,

Discussion:
When the error should mention bindings that are outside of the scope but within the same item <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Do you think we should suggest in this scenario? My local dev branch will suggest:
I removed it.
Change:
<ins> error[E0431]: `self` import can only appear in an import list with a non-empty prefix --> $DIR/issue-73020.rs:2:6 | LL | use {self}; |      ^^^^ can only appear in an import list with a non-empty prefix error: aborting due to previous error For more information about this error, try `rustc --explain E0431`. </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</detailsThis is a recent regression, since we run this command every day in automation.
Almost certainly a regression from /cc
looks like a duplicate of

<!-- 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. --reduced from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --repo @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Its a regression from but fortunately the fix is relatively easy. I'll provide a PR soon,

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
another one: another one:
I am on it
Same issue happened after upgraded to the latest version today.
Yes the has not landed yet.
Change:
<ins> error: incompatible link kind for `Foo::bar` --> $DIR/field-ice.rs:5:6 | LL | /// [`Foo::bar()`] |      ^^^^^^^^^^^^ help: to link to the field, remove the disambiguator: ``Foo::bar`` | note: the lint level is defined here --> $DIR/field-ice.rs:1:9 | LL | #![deny(rustdoc::broken_intra_doc_links)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = note: this link resolved to a field, which is not a function error: aborting due to previous error </ins>

Discussion:
Unfortunately I don't have an easy-to-repro case. This happened while working on Rocket's docs. I renamed a method which made a previously valid link invalid and I got this ICE. Fixing the doc link fixes the error. Backtrace from rustc 1.54.0-nightly ( 2021-05-21) follows: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If someone can compile a build of rustdoc that comments out this line: you should get a much better error message that says exactly what went wrong (it will start with "incompatible link kind"), and that should give an idea of where the bug is.
can you link to the exact commit of Rocket that caused the ICE?
This is the current tip, You may be able to replicate this by referencing in the struct's docs in and then changing the method's name to something else. If this fails, I will try to create a reproducible case.
MCVE: label -E-needs-mcve
claim
Error: Parsing relabel command in failed: ...'needs-MCVE' '): rs'... Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'needs-mcve' '): rs'... Please let know if you're having trouble with this bot.
Change:
sugar for dynamic allocations via `malloc` and `free`: ```rust,ignore <del> #![feature(lang_items, box_syntax, start, libc)] </del> <ins> #![feature(lang_items, box_syntax, start, libc, core_intrinsics)] </ins> #![no_std] <ins> use core::intrinsics; </ins> extern crate libc; <del> extern { fn abort() -> !; } </del> #[lang = "owned_box"] pub struct Box<T>(*mut T);

Discussion:
The following file, when compiled without optimizations, correctly generates an overflow check in : However, compiling with optimizations plus or generates code without the overflow check. However, if I move to a separate no_core crate like this, the issue disappears and the overflow check is generated:
noticed that my panic implementation () is UB according to LLVM (see ), so it optimizes the overflow check out on the assumption that it can never be triggered (since that would be UB). Replacing it with e.g. fixes the issue.
Change:
}; match info.format { <del> ExpnFormat::MacroAttribute(..) => return true, // definitely a plugin ExpnFormat::CompilerDesugaring(_) => return true, // well, it's "external" ExpnFormat::MacroBang(..) => {} // check below } let def_site = match info.def_site { Some(span) => span, // no span for the def_site means it's an external macro None => return true, }; </del> <ins> ExpnFormat::MacroAttribute(..) => true, // definitely a plugin ExpnFormat::CompilerDesugaring(CompilerDesugaringKind::ForLoop) => false, ExpnFormat::CompilerDesugaring(_) => true, // well, it's "external" ExpnFormat::MacroBang(..) => { let def_site = match info.def_site { Some(span) => span, // no span for the def_site means it's an external macro None => return true, }; </ins> <del> match sess.source_map().span_to_snippet(def_site) { Ok(code) => !code.starts_with("macro_rules"), // no snippet = external macro or compiler-builtin expansion Err(_) => true, </del> <ins> match sess.source_map().span_to_snippet(def_site) { Ok(code) => !code.starts_with("macro_rules"), // no snippet = external macro or compiler-builtin expansion Err(_) => true, } } </ins> } }

Discussion:
since
It is hitting the here: So I'm not quite sure why the error isn't being emitted yet.
It appears to be hitting this line of code which is cancelling the diagnostic:
this appears to be a stable-to-beta regression ()
triage: P-high. Assigning to self.
We need to change to not consider desugarings coming from loops as external. If that has regressions in our test suite, then we can add a new desugaring kind to differentiate between different parts of the for loop desugaring and target it further, but I do not expect that to be needed.
I've opened with a fix, based on comment.
Change:
| = help: consider removing `T`, referring to it in a field, or using a marker such as `PhantomData` <del> error: aborting due to 12 previous errors </del> <ins> error: aborting due to 16 previous errors </ins> For more information about this error, try `rustc --explain E0392`.

Discussion:
I tried this code: I expected to see this happen: compilation failure Instead, this happened: compilation succeeded <!-- 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. --: cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Oops sorry. You can continue with your PR.
Change:
| LL |     let _ = 0x61u32 as char; |             ^^^^^^^^^^^^^^^ invalid cast <ins> | help: try `char::from_u32` instead --> $DIR/cast-rfc0401.rs:41:13 | LL |     let _ = 0x61u32 as char; |             ^^^^^^^^^^^^^^^ </ins> error[E0606]: casting `bool` as `f32` is invalid --> $DIR/cast-rfc0401.rs:43:13

Discussion:
Given the following code: The current output is: This is not very clear. There are two pieces of background information the user needs here: s are Unicode scalar values, which are any integer value from 0 to 0xD7FF and 0xE000 to 0x10FFFF. Only u8 can be statically guaranteed to meet this requirement so only u8 can be cast to char. is probably what the user wants, if they are interested in non-ASCII values. The user is directed to further information available at and , neither of which explains either of those two points. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think a good improvement would be to a) Add more detail about this to b) Add a to this error that suggests are you interested in working on one or both of those? :)
claim
While I was reading the docs I noticed a minor error in : This isn't true; a USV is a Code Point within either of two ranges, not one. It's also a bit cagey about what the ranges are numerically; I don't know if this is intentional. Personally I would re-write it to the below: Would I put that in the same PR (as they're both documentation) or a new issue?
A new PR would be better.
Change:
LL | trait foo6 { |       ^^^^ help: convert the identifier to upper camel case (notice the capitalization): `Foo6` <ins> error: associated type `foo7` should have an upper camel case name --> $DIR/lint-non-camel-case-types.rs:26:10 | LL |     type foo7; |          ^^^^ help: convert the identifier to upper camel case (notice the capitalization): `Foo7` </ins> error: type parameter `ty` should have an upper camel case name <del> --> $DIR/lint-non-camel-case-types.rs:29:6 </del> <ins> --> $DIR/lint-non-camel-case-types.rs:30:6 </ins> | LL | fn f<ty>(_: ty) {} |      ^^ help: convert the identifier to upper camel case: `Ty` <del> error: aborting due to 8 previous errors </del> <ins> error: aborting due to 9 previous errors </ins>

Discussion:
Associated types are types and thus should be capitalized. I think most code also does this. Recently I accidentally didn't capitalize it and was surprised that it doesn't lint for it: I'd expect it to say something. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
checking happens inside , add for , then inspect the kind of inside this checking.
I'd like to put my hand up for this if that's alright? It looks like a good one to get started on. claim
Change:
<ins> error[E0220]: associated type `A` not found for `T` --> $DIR/issue-79465.rs:1:20 | LL | pub fn f1<T>(x: T::A) {} |                    ^ associated type `A` not found error[E0220]: associated type `A` not found for `T` --> $DIR/issue-79465.rs:1:20 | LL | pub fn f1<T>(x: T::A) {} |                    ^ associated type `A` not found error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0220`. </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. --code from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
MCVE: Assigning P-low by the same rationale as , but I expect this to be much easier to fix than the other ICEs that are outside of rustdoc proper.
No longer crashing
Change:
cargo.arg("-p").arg($krate); )+ <del> $(if !$bin { </del> <ins> if !$bin { </ins> cargo.rustdocflag("--document-private-items"); <del> })? </del> <ins> } </ins> cargo.rustdocflag("--enable-index-page"); cargo.rustdocflag("--show-type-layout"); cargo.rustdocflag("-Zunstable-options");

Discussion:
Compare to This is almost certainly caused by <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // https://github.com/rust-lang/rust/issues/92940 // // Show traits implemented on fundamental types that wrap local ones. pub struct MyType; // @has 'impl_box/struct.MyType.html' // @has '-' '//*[@id="impl-Iterator"]' 'impl Iterator for Box<MyType>' impl Iterator for Box<MyType> { type Item = (); fn next(&mut self) -> Option<Self::Item> { todo!() } } </ins>

Discussion:
You'd expect the impl for the boxed type to show up, but it doesn't. I seem to recall rustdoc displays impls anytime the type is contained in the generics, though, so it's odd that it's not happening. Originally reported by (with ) .
also reported a case involving a impl that didn't show up on the trait's page. IIRC this issue is somewhat known already though.
I can't find a case where the impl is if the type is in the generics. Do you have an example maybe?
On Vec's page: !
That one's happening because of this thing. Notice that the generics on the trait count, but the generics on don't. We definitely need to fix this, specifically, for types, because that's how you wind up with impls that aren't actually documented anywhere.
Change:
/// Method has something illegal Method(ast::Name, MethodViolationCode), <ins> /// Associated const AssociatedConst(ast::Name), </ins> } impl ObjectSafetyViolation {

Discussion:
The following code compiles: Furthermore, adding the line to causes an ICE:
I think the code should be legal to compile. It's impossible to get the value of from a variable (there's no such thing as where is a binding of type ).
Well it shouldn't compile
I don't know if this can lead to unsoundness or not. Correct me.
says no
Update on this, the example in the original post compiles today. But this ICEs: AFAICT there are two options here: consts are not object safe, just like associated (static) functions. consts must all be specified, just like associated types. I think its sensible to start with the first. The second makes more sense in the context of a world with const params, but the first can be extended to the second. It might also make sense some day to allow clauses on associated consts just like methods (and on associated types, for that matter, which connects in some degree with the ATC RFC).
Can't associated consts be part of the vtable/fat pointers?
Associated consts are inlined at compiletime, they can't have a value which is determined at runtime. This is a hard requirement for making things like const fn and const generics work. Associated statics could be object safe if they existed.
I think that having to write: instead of just: or is a pain. The value is determined at compile-time, but I am talking about being able to access that value at run-time via dynamic dispatch.
The value is not determined at compile time for the virtually dispatched type (the trait object type). What you want is the fields in traits RFC.
I did not say otherwise (the value is only determined at compile-time for the types that implement , not for itself or trait objects). What I did say is that currently there is no way to access this value at run-time without in my opinion unnecessary boilerplate but there should be one.
Maybe the problem is that traits support associated consts, and associated consts are values, but traits do not support associated values (yet).
Will they be object-safe in the future? I mean if "fn foo() -u8 where Self: Sized;" is already safe why are consts not?
Change:
reg: InlineAsmRegOrRegClass, expr: &hir::Expr<'tcx>, template: &[InlineAsmTemplatePiece], <ins> is_input: bool, </ins> tied_input: Option<(&hir::Expr<'tcx>, Option<InlineAsmType>)>, ) -> Option<InlineAsmType> { // Check the type against the allowed types for inline asm.

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Somewhere during compilation of this code, LLVM's ). Because of that, rustccodegenllvm::asm::inlineasmcall , and the parent function then .
I a statement to log the function type and constraints string passed to LLVM:
claim