jiebi/CodeConvo huggingface dataset:
Change:
// @has add_docs/struct.MyStruct.html <del> // @has add_docs/struct.MyStruct.html "Doc comment from 'pub use', Doc comment from definition" </del> <ins> // @has add_docs/struct.MyStruct.html "Doc comment from ‘pub use’, Doc comment from definition" </ins> /// Doc comment from 'pub use', pub use inner::MyStruct;

Discussion:
Split off from . modify labels: T-rustdoc C-enhancement <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Uh, it looks like rustbot is editing my message and adding weird comments:
Cc
It looks like smart punctuation doesn't work in headers: ! wasn't able to reproduce this in pulldown itself; I'm guessing rustdoc is doing something special with headers. Cc
Triagebot does that as a way of easily storing data per-issue (we could do it in the database now, we didn't have one back then). But it's expected and shouldn't really be a problem.
Is this a good thing? Wouldn't keeping things as it is is better?
I think if you want to argue against doing this, giving reasons would be helpful. I personally think given that we already use emoji and otherwise non-ASCII characters readily, it should be reasonable for us to generate smart quotes as well.
I do think emoji and other non-ASCII characters if specified would be good except for smart quote. It's like saying to use greek question mark which is the same as semi-colon when a semi-colon was seen in documentation to make it look a bit cooler. One thing is copying, when others are copying the text, it will copy the utf-8 version of smart quotes which when displayed in terminals which in turn will make it look ugly and hard for text processing. Auto changing text to emoji I am okay with that. But not automatically changing single quotes, double quotes and semi-colons. Personally I don't see much benefit to that, usually if users want it they would specifically type it out but otherwise it would be similar. In my humble opinion, looks wise the smart quotes are more ugly, but easier to distinguish opening and closing quotes, but still when copied and pasted it may not look so good.
Change:
_ => false, }; <ins> let find_span = |source: &PathSource<'_>, err: &mut DiagnosticBuilder<'_>| { match source { PathSource::Expr(Some(Expr { span, kind: ExprKind::Call(_, _), .. })) | PathSource::TupleStruct(span, _) => { // We want the main underline to cover the suggested code as well for // cleaner output. err.set_span(*span); *span } _ => span, } }; </ins> let mut bad_struct_syntax_suggestion = |def_id: DefId| { let (followed_by_brace, closing_brace) = self.followed_by_brace(span);

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. -- The current output is: Ideally the output should look like: I'd like it to say "try to use a unit variant like "FarmAnimal::Cow" instead". For example, here's what happens if you use Tuple syntax instead of Struct syntax: So I'd like the new diagnostic to look something like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is an example Ferrous Systems uses in our trainings, and some of our participants have tripped over this lack of suggestion here. The compiler DOES provide diagnostics when you use a struct syntax instead of a tuple syntax.
Alternatively the help could suggest a more direct: "Remove the parenthesis here".
claim
I just wanted to mention , and I wanted to thank you personally for implementing this diagnostics improvement so quickly! Let me know if you have a blog or twitter you'd like us to link to (rather than your GH profile).
Hello, linking to my GH profile is fine. I did not know I would contribute to such an interesting learning experience. Anyway thank you for mentioning me in your blog post .
Change:
<ins> // check-pass #![feature(associated_type_bounds, return_position_impl_trait_in_trait)] trait Trait { type Type; fn method(&self) -> impl Trait<Type: '_>; } impl Trait for () { type Type = (); fn method(&self) -> impl Trait<Type: '_> { () } } fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2023-08-29 Regression in cc
Change:
} } <ins> #[stable(feature = "ipv6_from_octets", since = "1.9.0")] impl From<[u8; 16]> for Ipv6Addr { fn from(octets: [u8; 16]) -> Ipv6Addr { let mut inner: c::in6_addr = unsafe { mem::zeroed() }; inner.s6_addr = octets; Ipv6Addr::from_inner(inner) } } </ins> // Tests for this module #[cfg(test)] mod tests {

Discussion:
Tracking issue for First needs to be implemented, then go through an FCP! Looks like the is being implemented over at
This issue is now entering a cycle-long final comment period for stabilization
Discussed recently, the libs team decided to stabilize.
Change:
} } <ins> // If this was a missing `@` in a binding pattern // bail with a suggestion // https://github.com/rust-lang/rust/issues/72373 if self.prev_token.is_ident() && &self.token.kind == &token::DotDot { let msg = format!( "if you meant to bind the contents of  the rest of the array pattern into `{}`, use `@`", pprust::token_to_string(&self.prev_token) ); expect_err .span_suggestion_verbose( self.prev_token.span.shrink_to_hi().until(self.token.span), &msg, " @ ".to_string(), Applicability::MaybeIncorrect, ) .emit(); break; } </ins> // Attempt to keep parsing if it was an omitted separator. match f(self) { Ok(t) => {

Discussion:
Gives: I think a better error message should suggest the usage of . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This gets us to:
Format and help message revised to:
Merged. Thanks for the report!
Change:
// force-host <del> #[feature(globs, macro_registrar, macro_rules, quote_expr)]; </del> <ins> #[feature(globs, macro_registrar, macro_rules, quote)]; </ins> extern mod syntax;

Discussion:
These all are only useful in the compiler, aren't hygienic, etc. Nominating.
What hygiene issues do they still have? The hygiene issue I'm aware of was fixed by . They'll be very useful for externally defined syntax extensions. I'm okay with feature gating it though.
The only thing I recall is that they require an to be in scope. Perhaps that's not technically a hygiene problem.
Accepted for 1.0, P-backcompat-lang.
I would like to look at this, but I am not familiar to quasi-quoting. Can you list some quasi-quoting macros, or point out the directory of the source tree to look up? What I have found related to quasi-quoting lies on .
All of the quasi-quoting macros live there.
Their .
Change:
let variants = def.discriminants(cx.tcx()).try_fold( Self::uninhabited(), |variants, (idx, ref discriminant)| { <del> let variant = layout_of_variant(idx)?; </del> <ins> let variant = layout_of_variant(idx, Some(tag_encoding.clone()))?; </ins> Result::<Self, Err>::Ok(variants.or(variant)) }, )?;

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'Size::sub: 0 - 1 would result in negative size'', 'thread 'rustc' panicked at 'Size::sub: 0 - 1 would result in negative size'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [evaluateobligation] evaluating trait selection obligation [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
On it! Thanks for the report.
Further minimized:
The cause here is neat. here is niche optimizable, with its second variant being subject to niche optimization. Typically, a niche-optimized enum has one tagless variant, and zero or more tagged variants laid out in the usual manner: the tag is placed, and then the rest of the fields follow. But reveals that's not what happens here. Because is a ZST, is placed at offset , rather than (following the tag). In other words: the tag is co-located with the field. This produces an ICE, because our assumption that fields follow tag is violated (a checked sub panics).
claim
Change:
], Applicability::MachineApplicable, ); <ins> } else { // FIXME: we may suggest array::repeat instead err.help("consider using `core::array::from_fn` to initialize the array"); err.help("see https://doc.rust-lang.org/stable/std/array/fn.from_fn.html# for more information"); </ins> } if self.tcx.sess.is_nightly_build()

Discussion:
For this snippet (): rustc gives: Since , for const-able values, rustc suggests the creation of a constant binding. Here this is not possible because is not const fn. However, we can suggest instead.
Personally, I prefer over a separate binding. Even in the case, the generated code will call the initialization function many times. Maybe in the case where bindings are possible, we can suggest both? Where they are not possible, we don't suggest anything right now, so at the least we should suggest there. what do you think?
Once is stable we can suggest that :3. But until then sounds reasonable.
Agreed, good point about . It seems to have a stabilization PR open with an FCP, which is blocked: . Maybe there might be progress on it this month: . Even if we stabilize inline const, it might make sense to wait with suggesting it for a while so that we don't make code depend on the latest MSRV immediately. So therefore, I think that it might still make sense to implement this in the meantime.
I think this should (in the future) suggest  instead, since the function would only be called once if were , whereas calls it for every element.
Change:
use snap::write::FrameEncoder; <ins> use object::elf::NT_GNU_PROPERTY_TYPE_0; </ins> use rustc_data_structures::memmap::Mmap; use rustc_data_structures::owned_slice::try_slice_owned; use rustc_data_structures::sync::MetadataRef;

Discussion:
I noticed that the synthetic object files in will disable the IBT (on x86, enabled by ) and BTI (on AArch64, enabled by ) features because the object files are missing sections indicating that the object file is compatible with those features. Normally, if an object file is missing a section, the linker will disable all such features, on the assumption that the object file is not compatible. This issue is reproducible on the master branch (slightly awkwardly because many distros don't ship IBT-enabled files, and neither is it enabled in Rust's standard library by default): In another directory: After commenting out the line of code that adds to the link: the binary has the correct property note: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I can think of three possible solutions: the appropriate GNU property section into the synthetic object file according to the passed flags. This would work, but it could easily get out of sync with the GNU properties produced by the compiler. a change in linker behavior so that the GNU properties are not affected by object files that do not contain sections. This would make sense because an object file without sections cannot on its own affect the contents of the final binary, which means that it cannot cause the binary to become {BTI,IBT}-incompatible. a linker feature that implements equivalent behavior to the synthetic object file, e.g. a flag that is equivalent to but does not inhibit , and then use that on ELF platforms instead of the synthetic object file if the linker supports it. may have thoughts on this.
Option 3 is not enough to solve this. The crate metadata object is also produced without these properties and can't be replaced with a linker option. Option 2 will take a long time before everyone has a new linker and needs coordination with , , and As such option 1 makes most sense to me.
Option 2 needs coordination among linker maintainers and it does impose some complexity to linkers. And as mentioned, it requires very new linkers. If Rust is open to 1, I think it is a great direction.
claim
Change:
cc = "1.0.67" [features] <ins> # Only applies for Linux and Fuchsia targets # Static link to the in-tree build of llvm libunwind </ins> llvm-libunwind = [] <ins> # Only applies for Linux and Fuchsia targets # If crt-static is enabled, static link to `libunwind.a` provided by system # If crt-static is disabled, dynamic link to `libunwind.so` provided by system </ins> system-llvm-libunwind = []

Discussion:
Hello, I'm trying to build a pure-LLVM Rust (no linking to at all). Building rust with set as in returns failure since Clang (the C compiler) doesn't allow . Here's my : Here are the relevant bits of the log: Thanks. A complete log is available here:
I think I may have found the culprit. I'm not well-versed in building rustc (I particularly don't know why rust can build its own LLVM instance, but I assume this is to accommodate systems where LLVM doesn't even exist?), but isn't the choice between and is pretty much irrelevant per libc? And by the way, using gcc as , while it does accept the command, it warns (instead of erroring out like clang-9) because isn't supported in the C compiler.
Change:
{ debug!("note_issue_32330: terr={:?}", terr); match *terr { <del> TypeError::RegionsInsufficientlyPolymorphic(_, &Region::ReVar(vid)) | TypeError::RegionsOverlyPolymorphic(_, &Region::ReVar(vid)) => { match self.region_vars.var_origin(vid) { RegionVariableOrigin::EarlyBoundRegion(_, _, Some(Issue32330 { fn_def_id, region_name })) => { diag.note( &format!("lifetime parameter `{0}` declared on fn `{1}`  appears only in the return type,  but here is required to be higher-ranked,  which means that `{0}` must appear in both  argument and return types", region_name, self.tcx.item_path_str(fn_def_id))); diag.note( &format!("this error is the result of a recent bug fix;  for more information, see issue #33685  <https://github.com/rust-lang/rust/issues/33685>")); } _ => { } } </del> <ins> TypeError::RegionsInsufficientlyPolymorphic(_, _, Some(box Issue32330 { fn_def_id, region_name })) | TypeError::RegionsOverlyPolymorphic(_, _, Some(box Issue32330 { fn_def_id, region_name })) => { diag.note( &format!("lifetime parameter `{0}` declared on fn `{1}`  appears only in the return type,  but here is required to be higher-ranked,  which means that `{0}` must appear in both  argument and return types", region_name, self.tcx.item_path_str(fn_def_id))); diag.note( &format!("this error is the result of a recent bug fix;  for more information, see issue #33685  <https://github.com/rust-lang/rust/issues/33685>")); </ins> } <del> _ => { } </del> <ins> _ => {} </ins> } }

Discussion:
This code: Produces this internal compiler error: Interestingly, changing to or causes the code compile fine (modulo unused variable warnings). : Backtrace:
This is a regression in 1.17.0-beta. Earlier versions give:
Duplicate of .

Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.
Change:
} } <ins> /// Check whether a `ty` has a negative `Copy` implementation, ignoring outlives constraints. fn type_implements_negative_copy_modulo_regions<'tcx>( tcx: TyCtxt<'tcx>, ty: Ty<'tcx>, param_env: ty::ParamEnv<'tcx>, ) -> bool { let trait_ref = ty::TraitRef::new(tcx, tcx.require_lang_item(hir::LangItem::Copy, None), [ty]); let pred = ty::TraitPredicate { trait_ref, polarity: ty::ImplPolarity::Negative }; let obligation = traits::Obligation { cause: traits::ObligationCause::dummy(), param_env, recursion_depth: 0, predicate: ty::Binder::dummy(pred).to_predicate(tcx), }; tcx.infer_ctxt().build().predicate_must_hold_modulo_regions(&obligation) } </ins> declare_lint! { /// The `missing_debug_implementations` lint detects missing /// implementations of [`fmt::Debug`] for public types.

Discussion:
I would expect the following code to compile successfully since we explicitly opt out of implementing : However, the code fails to compile with the following error message: label C-bug A-lint F-negativeimpls <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The compiler only checks if the type implements already to return early and not emit the lint diagnostic but it doesn't check if the type implements :
I think this makes the trick, you are right! the last think is to explore what is the code of the method The code of the method looks not so trivial :) If you did not find already I can play with your on it by mentoring you, I had some experience in "git archeology" :) label +E-mentor
claim
Change:
pixels to avoid overflowing the topbar when the user sets a bigger font size. */ font-size: 24px; <del> } .mobile-topbar h2 a { display: block; text-overflow: ellipsis; overflow: hidden; </del> white-space: nowrap; <ins> text-overflow: ellipsis; </ins> } .mobile-topbar .logo-container > img {

Discussion:
On mobile using both firefox and Brave. !
This is presumably a rustdoc issue, unless our css somehow affects it, but I doubt it.
Taking a look.
Change:
proj_ty: Ty<'tcx>, #[label(lint::specifically)] assoc_pred_span: Span, <del> #[suggestion_verbose(applicability = "machine-applicable", code = "{suggestion}")] suggest_span: Option<Span>, suggestion: String, </del> <ins> #[subdiagnostic] add_bound: Option<AddBound<'tcx>>, } #[derive(Subdiagnostic)] #[suggestion_verbose( lint::opaque_hidden_inferred_bound_sugg, applicability = "machine-applicable", code = " + {trait_ref}" )] struct AddBound<'tcx> { #[primary_span] suggest_span: Span, #[skip_arg] trait_ref: TraitPredPrintModifiersAndPath<'tcx>, </ins> }

Discussion:
Note: Switching back to 1.65 compiles fine : </p</details
label +E-needs-mcve
Sorry for the noise on this issue, but I just realized what I had done which apparently got around this issue. I fixed a new warning in my web server library by turning this.. into this
I caused this. Let me put up a fix.
Change:
# An optional number to put after the label, e.g. '.2' -> '-beta.2' # NB Make sure it starts with a dot to conform to semver pre-release # versions (section 9) <del> CFG_PRERELEASE_VERSION=.2 </del> <ins> CFG_PRERELEASE_VERSION=.3 </ins> # Append a version-dependent hash to each library, so we can install different # versions in the same place

Discussion:
Testcase currently relying on the most recent ncollide and nphysics3d from When I get some time later today I'll try to reduce it more. Code: Error:
I investigated this further and ended up with the following test case independent from ncollide/nphysics. It causes an ICE on both beta (rustc 1.9.0-beta.2 ( 2016-05-04)) and nigthly (rustc 1.10.0-nightly ( 2016-04-28))( and compiles fine on stable. The ICE will appear with and without . This might be related to . I can try to compile this on master but it will take some time before I can download the repo and compile rustc manually. This will compile fine, without any ICE if we do at least one of the following: Implement the method explicitly on :Remove the associated type in the impl, i.e., replace with (or anything else, including itself instead of ). Remove the cast to a trait-object at the end of the .
Fixed by .
Change:
<ins> // Copyright 2018 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. pub trait Signal { type Item; } pub trait Signal2 { type Item2; } impl<B, C> Signal2 for B where B: Signal<Item = C> { type Item2 = C; } // @has issue_50159/struct.Switch.html // @has - '//code' 'impl<B> Send for Switch<B> where <B as Signal>::Item: Send' // @has - '//code' 'impl<B> Sync for Switch<B> where <B as Signal>::Item: Sync' // @count - '//*[@id="implementations-list"]/*[@class="impl"]' 0 // @count - '//*[@id="synthetic-implementations-list"]/*[@class="impl"]' 2 pub struct Switch<B: Signal> { pub inner: <B as Signal2>::Item2, } </ins>

Discussion:
When I tried to build docs for , I got a panic. Here is the reduced test case: With the above code, when I run I get this panic: rustc 1.27.0-nightly ( 2018-04-18) binary: rustc commit-hash: commit-date: 2018-04-18 host: x86_64-pc-windows-msvc release: 1.27.0-nightly LLVM version: 6.0
Strange... Will take a look as soon as possible.
So the call is performed . I'll need help from (or anyone in the team who knows about the type) in order to fix this issue.
Reduced further:
I'd like to work on this.
Thank you so much! I verified that with the latest Rust Nightly I no longer get any errors.