jiebi/CodeConvo huggingface dataset:
Change:
let lvalue = self.trans_lvalue(&bcx, location); let drop_fn = glue::get_drop_glue(bcx.ccx(), ty); let drop_ty = glue::get_drop_glue_type(bcx.tcx(), ty); <del> let llvalue = if drop_ty != ty { bcx.pointercast(lvalue.llval, type_of::type_of(bcx.ccx(), drop_ty).ptr_to()) </del> <ins> let is_sized = common::type_is_sized(bcx.tcx(), ty); let llvalue = if is_sized { if drop_ty != ty { bcx.pointercast(lvalue.llval, type_of::type_of(bcx.ccx(), drop_ty).ptr_to()) } else { lvalue.llval } </ins> } else { <del> lvalue.llval </del> <ins> // FIXME(#36457) Currently drop glue takes sized // values as a `*(data, meta)`, but elsewhere in // MIR we pass `(data, meta)` as two separate // arguments. It would be better to fix drop glue, // but I am shooting for a quick fix to #35546 // here that can be cleanly backported to beta, so // I want to avoid touching all of trans. bcx.with_block(|bcx| { let scratch = base::alloc_ty(bcx, ty, "drop"); base::call_lifetime_start(bcx, scratch); build::Store(bcx, lvalue.llval, base::get_dataptr(bcx, scratch)); build::Store(bcx, lvalue.llextra, base::get_meta(bcx, scratch)); scratch }) </ins> }; if let Some(unwind) = unwind { bcx.invoke(drop_fn,

Discussion:
The following successfully typechecks on , but generates an LLVM assertion failure: Error: Note that replacing with (and making mutable) allows compilation to succeed.
First occurs in nightly-2016-08-03 which turns on mir by default, does not occur on nightly-2016-08-03 with -Z orbit=off.
Using this was introduced between and ().
Problem seems to be that we call the with a fat pointer as 2 arguments, but it expects a pointer to a tuple.
I have a fix for this, running the full locally now to see if I broke anything else on the way.
Change:
``` <ins> ##### Byte literals </ins> A _byte literal_ is a single ASCII character (in the `U+0000` to `U+007F` range) enclosed within two `U+0027` (single-quote) characters, with the exception of `U+0027` itself, which must be _escaped_ by a preceding U+005C character (``), or a single _escape_. It is equivalent to a `u8` unsigned 8-bit integer _number literal_. <ins> ##### Byte string literals </ins> A _byte string literal_ is a sequence of ASCII characters and _escapes_ enclosed within two `U+0022` (double-quote) characters, with the exception of `U+0022` itself, which must be _escaped_ by a preceding `U+005C` character

Discussion:
The doesn't document what escape sequences are valid if any. For example, documentation doesn't state whether this will match a newline as would be expected: It also doesn't specify what format these strings are supposed to be written in. Much of the documentation including many escape sequences are documented in the but it is difficult (slow) to parse as it is. I think it would be good to have it in or at least to make the reference more clear. More escape documentation is in (though it's not exactly related). For what it's worth, doesn't seem to document it either (at least, I couldn't find it). Below is my first shot at what it could look like. followed by any number (including zero) of 's followed by and closed in the reverse: A single ASCII character: A sequence of ASCII characters: Note: I'm not really familiar with all the string formats. I'm just to collect them together so they're more obvious. Does it make sense to collect them onto the  page? If so, I can probably submit a PR making something like this but I'm not sure where it should go.
Python , but in the language reference rather than the standard library documentation. Perhaps Rust’s escape sequences should be documented in the reference, where most other language-documenting features go.
Horizontal Tab, AKA t, ASCII/Unicode 9. See .
Oh, I completely misread this as 6 escapes (but it's 3 with their definitions). The .
I'm quite surprised to find that Rust doesn't have (i.e: 'backspace') built in to the language. Is there a particular reason for this?
asking on is a better place than on a three and a half year old issue.
Change:
assert_eq!(size_of::<Option<Option<(&(), bool)>>>(), size_of::<(bool, &())>()); assert_eq!(size_of::<Option<Option2<bool, &()>>>(), size_of::<(bool, &())>()); assert_eq!(size_of::<Option<Option2<&(), bool>>>(), size_of::<(bool, &())>()); <ins> assert_eq!(size_of::<CanBeNicheFilledButShouldnt>(), 8); assert_eq!(size_of::<Option<CanBeNicheFilledButShouldnt>>(), 8); assert_eq!(size_of::<Option<Option<CanBeNicheFilledButShouldnt>>>(), 8); assert_eq!(size_of::<AlwaysTaggedBecauseItHasNoNiche>(), 8); assert_eq!(size_of::<Option<AlwaysTaggedBecauseItHasNoNiche>>(), 8); assert_eq!(size_of::<Option<Option<AlwaysTaggedBecauseItHasNoNiche>>>(), 8); </ins> }

Discussion:
This prints the values in comments: Note that contains strictly more opportunities for optimization, but it's optimized worse. That's because it uses a "niche-filling" layout (using in the field of for ), but the "tag" layout wouldn't be any larger, because it has enough space in bytes to fit the (byte-sized) tag, and . uses the tagged layout since it has no other choice, and ends up with free values in the byte-sized tag, but "jumps the gun" on using a pre-existing niche.
Change:
Applicability::MaybeIncorrect, ) .emit(); <ins> } else if self.eat_keyword(kw::Let) { let span = self.prev_token.span; self.struct_span_err(const_span.to(span), "`const` and `let` are mutually exclusive") .span_suggestion( const_span.to(span), "remove `let`", "const", Applicability::MaybeIncorrect, ) .emit(); </ins> } }

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. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should inform the user that and are mutually exclusive and suggest the user remove the . <!-- 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 --
claim
Change:
specializes: specialize::specializes, subst_and_check_impossible_predicates, check_tys_might_be_eq: misc::check_tys_might_be_eq, <del> is_impossible_method, </del> <ins> is_impossible_associated_item, </ins> ..*providers }; }

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. --The command causes an ICE error. This happens when we use the features of () in different workspaces. workspace- : workspace- : <!-- 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 --<!-- TRIAGEBOT_END --
label T-rustdoc
label -needs-triage A-cross-crate-reexports Ah lol, just noticed that we're also leaking the desugared form of RPITITs (the assoc ty) for a slightly altered non-icing version of this code (still cross-crate tho). Also needs to be addressed at some point, taking a mental note. claim
Change:
Some(r) } <ins> /// Make sure that we are in the condition to suggest the blanket implementation. fn maybe_lint_blanket_trait_impl<T: rustc_errors::EmissionGuarantee>( &self, self_ty: &hir::Ty<'_>, diag: &mut DiagnosticBuilder<'_, T>, ) { let tcx = self.tcx(); let parent_id = tcx.hir().get_parent_item(self_ty.hir_id); if let hir::Node::Item(hir::Item { kind: hir::ItemKind::Impl(hir::Impl { self_ty: impl_self_ty, of_trait: Some(of_trait_ref), generics, .. }), .. }) = tcx.hir().get_by_def_id(parent_id) && self_ty.hir_id == impl_self_ty.hir_id { if !of_trait_ref.trait_def_id().map_or(false, |def_id| def_id.is_local()) { return; } let of_trait_span = of_trait_ref.path.span; // make sure that we are not calling unwrap to abort during the compilation let Ok(impl_trait_name) = tcx.sess.source_map().span_to_snippet(self_ty.span) else { return; }; let Ok(of_trait_name) = tcx.sess.source_map().span_to_snippet(of_trait_span) else { return; }; // check if the trait has generics, to make a correct suggestion let param_name = generics.params.next_type_param_name(None); let add_generic_sugg = if let Some(span) = generics.span_for_param_suggestion() { (span, format!(", {}: {}", param_name, impl_trait_name)) } else { (generics.span, format!("<{}: {}>", param_name, impl_trait_name)) }; diag.multipart_suggestion( format!("alternatively use a blanket  implementation to implement `{of_trait_name}` for  all types that also implement `{impl_trait_name}`"), vec![ (self_ty.span, param_name), add_generic_sugg, ], Applicability::MaybeIncorrect, ); } } </ins> fn maybe_lint_bare_trait(&self, self_ty: &hir::Ty<'_>, in_path: bool) { let tcx = self.tcx(); if let hir::TyKind::TraitObject([poly_trait_ref, ..], _, TraitObjectSyntax::None) =

Discussion:
One of the big problems with the 2015-style trait object syntax (no ) was that users often write things like when what they really meant was . Back then, the error message would more often than not be some inscrutable message about , which would send them on a wild goose chase of adding bounds everywhere they could think of, leading to even more inscrutable messages. Now, the error message is clearer: it tells users they need to add for a trait object type. However, I find in many cases (most cases?) this is not what users actually want - what they actually want is the blanket impl. It would be helpful to have a note suggesting the correct syntax for a blanket impl, or better yet just presenting both correct syntaxes (impl for trait object and blanket impl) on equal footing and making it clear the difference between them. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I work to reproduce this issue and start to understand what type of check we need to do, and in particular the work that we need to do is the following one: If the traits are local traits we can perform the suggestion of the blanket impls, for example in the following code But we need to skip the following suggestion in case we are using not local traits, like the following code here
Change:
} infer::CheckAssociatedTypeBounds { impl_item_def_id, trait_item_def_id, parent } => { let mut err = self.report_concrete_failure(*parent, sub, sup); <del> let trait_item_span = self.tcx.def_span(trait_item_def_id); let item_name = self.tcx.item_name(impl_item_def_id.to_def_id()); err.span_label( trait_item_span, format!("definition of `{}` from trait", item_name), ); </del> <ins> // Don't mention the item name if it's an RPITIT, since that'll just confuse // folks. if !self.tcx.is_impl_trait_in_trait(impl_item_def_id.to_def_id()) { let trait_item_span = self.tcx.def_span(trait_item_def_id); let item_name = self.tcx.item_name(impl_item_def_id.to_def_id()); err.span_label( trait_item_span, format!("definition of `{}` from trait", item_name), ); } </ins> self.suggest_copy_trait_method_bounds( trait_item_def_id, impl_item_def_id,

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
This needs detailed investigation, and I'd prefer we fully understand why this is resulting in a region error over just adding an check to (or feeding the query).... This probably has to do with the fact that we have a due to the missing region .
Change:
#[stable(feature = "rust1", since = "1.0.0")] #[rustc_promotable] #[rustc_const_stable(feature = "const_ptr_null", since = "1.24.0")] <ins> #[rustc_diagnostic_item = "ptr_null_mut"] </ins> pub const fn null_mut<T>() -> *mut T { 0 as *mut T }

Discussion:
I propose we add a lint that detects code like Some people seem to think that this is okay in contexts like or , but that is not the case -- on a NULL pointer is UB even as a place expression. To implement this, you can use the lint as a template: should check for  expressions with a operator, and then check the operand to be either a cast of to a pointer type, or a call to one of the methods. To detect the methods, make them "diagnostic items"; the lint does that e.g. for so it can again serve as a template here. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Ah, turns out clippy already has a lint for this: . So maybe we should just move that to rustc? Cc
claim
awesome. :) Let me know if you need any help.
Thanks :)
Did you mean something slightly different with your "okay in contexts like" examples, perhaps? Neither of those two actually compile as written, since they're just attempts to deference something that isn't even a pointer. You get: in both cases.
oops I screwed up the casts, should be fixed now.
Yeah, happy to have Clippy lints upstreamed to rust, let us know when it's done so we can deprecate it on our end
for detecting a call like you said to use . However I do not know what to use for the symbol argument. There is that defines symbol but nothing looks like creating a null ptr. Should I add one what should it look like ?
You first need to add the diagnostic item attribute to the relevant function inside , like so: This name must be globally unique, e.g. and . Then you add those names to the list in (please keep it alphabetically sorted), and then you can use them for .
Change:
while true { //~^ WARN denote infinite loops //~| HELP use `loop` <del> let mut a = (1); </del> <ins> let mut registry_no = (format!("NX-{}", 74205)); </ins> //~^ WARN does not need to be mutable //~| HELP remove this `mut` //~| WARN unnecessary parentheses

Discussion:
This code snippet () results in the following lint output: The should contain the literal string , not the expanded macro that it repreesnts.
Ah, I think this is because we should be using (to get the code the user actually wrote) (to render the AST); I could PR this tonight.
Change:
<ins> error[E0552]: incorrect `repr(packed)` attribute format: `packed` takes exactly one parenthesized argument, or no parentheses at all --> $DIR/malformed-repr-hints.rs:6:8 | LL | #[repr(packed())] |        ^^^^^^^^ error[E0589]: invalid `repr(align)` attribute: `align` needs an argument --> $DIR/malformed-repr-hints.rs:10:8 | LL | #[repr(align)] |        ^^^^^ help: supply an argument here: `align(...)` error[E0693]: incorrect `repr(align)` attribute format: `align` takes exactly one argument in parentheses --> $DIR/malformed-repr-hints.rs:14:8 | LL | #[repr(align(2, 4))] |        ^^^^^^^^^^^ error[E0693]: incorrect `repr(align)` attribute format: `align` takes exactly one argument in parentheses --> $DIR/malformed-repr-hints.rs:18:8 | LL | #[repr(align())] |        ^^^^^^^ error[E0552]: invalid representation hint: `Rust` does not take a parenthesized argument list --> $DIR/malformed-repr-hints.rs:23:8 | LL | #[repr(Rust(u8))] |        ^^^^^^^^ error[E0552]: invalid representation hint: `Rust` does not take a parenthesized argument list --> $DIR/malformed-repr-hints.rs:25:8 | LL | #[repr(Rust(0))] |        ^^^^^^^ error[E0552]: invalid representation hint: `Rust` does not take a value --> $DIR/malformed-repr-hints.rs:27:8 | LL | #[repr(Rust = 0)] |        ^^^^^^^^ error[E0552]: invalid representation hint: `i8` does not take a parenthesized argument list --> $DIR/malformed-repr-hints.rs:31:8 | LL | #[repr(i8())] |        ^^^^ error[E0552]: invalid representation hint: `u32` does not take a parenthesized argument list --> $DIR/malformed-repr-hints.rs:35:8 | LL | #[repr(u32(42))] |        ^^^^^^^ error[E0552]: invalid representation hint: `i64` does not take a value --> $DIR/malformed-repr-hints.rs:39:8 | LL | #[repr(i64 = 2)] |        ^^^^^^^ error: aborting due to 10 previous errors Some errors have detailed explanations: E0552, E0589, E0693. For more information about an error, try `rustc --explain E0552`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unrecognized representation hint', 'error: internal compiler error: unrecognized representation hint' File: --snippet: Version 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: --
Regression in nightly-2023-08-26
Change:
argc: isize, argv: *const *const u8, ) -> isize { <del> lang_start_internal(&move || main().report(), argc, argv) </del> <ins> lang_start_internal( &move || crate::sys_common::backtrace::__rust_begin_short_backtrace(main).report(), argc, argv, ) </ins> }

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:
var i, from, to, match = window.location.hash.match(/^#?(d+)(?:-(d+))?$/); if (match) { from = parseInt(match[1], 10); <del> to = Math.min(50000, parseInt(match[2] || match[1], 10)); from = Math.min(from, to); </del> <ins> to = from; if (typeof match[2] !== "undefined") { to = parseInt(match[2], 10); } if (to < from) { var tmp = to; to = from; from = tmp; } </ins> elem = document.getElementById(from); if (!elem) { return;

Discussion:
When I click on the link of a function in the rendered documentation, if the function's line number is greater than , the browser navigates to line instead of the proper location. I found the relevant code here: What's the rationale behind this limitation? Can it be lifted?
Interestingly, it looks like if this limit were removed, the for loop might be a problem. Then, maybe, someone could link to a url such as which would make the page freeze up, since the loop won't exit early if the line doesn't exist. I don't know if this would be considered harmful, however. The edit would simply be to change the line to , obviously
The freeze in that loop can be avoided with something like this:
Wo, super strange old code as it seems. Good catch!
Change:
| clean::MacroItem(..) | clean::ForeignTypeItem => { let item_id = i.item_id; <del> if item_id.is_local() && !self.is_item_reachable(item_id) { </del> <ins> if item_id.is_local() && !is_item_reachable(self.is_json_output, self.access_levels, item_id) { </ins> debug!("Stripper: stripping {:?} {:?}", i.type_(), i.name); return None; }

Discussion:
cc label +A-docs +A-rustdoc-ui +C-enhancement +T-rustdoc This is technically a regression, but it doesn't feel appropriate to label it as such.
Here is an example of a block that should be hidden when is not passed:
Change:
pub span: Span, } <ins> #[derive(Diagnostic)] #[diag(expand_glob_delegation_traitless_qpath)] pub(crate) struct GlobDelegationTraitlessQpath { #[primary_span] pub span: Span, } </ins> // This used to be the `proc_macro_back_compat` lint (#83125). It was later // turned into a hard error. #[derive(Diagnostic)]

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'internal error: entered unreachable code'', 'thread 'rustc' panicked at 'internal error: entered unreachable code'' File: --auto-reduced (treereduce-rust): original: Version 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: [resolverforloweringraw] getting the resolver for lowering -- label +F-fndelegation
^_^
Fixed in
Change:
// See if we can toss out `victim` based on specialization. // This requires us to know *for sure* that the `other` impl applies // i.e., `EvaluatedToOk`. <ins> // // FIXME(@lcnr): Using `modulo_regions` here seems kind of scary // to me but is required for `std` to compile, so I didn't change it // for now. let tcx = self.tcx(); </ins> if other.evaluation.must_apply_modulo_regions() { <del> let tcx = self.tcx(); </del> if tcx.specializes((other_def, victim_def)) { return true; } <del> return match tcx.impls_are_allowed_to_overlap(other_def, victim_def) { </del> <ins> } if other.evaluation.must_apply_considering_regions() { match tcx.impls_are_allowed_to_overlap(other_def, victim_def) { </ins> Some(ty::ImplOverlapKind::Permitted { marker: true }) => { // Subtle: If the predicate we are evaluating has inference // variables, do *not* allow discarding candidates due to

Discussion:
() same code with an additional line of whitespace/comments where indicated: however, the playground seems to behave different from my local nightly here Tested on label T-compiler requires-nightly F-markertraitattr A-traits A-typesystem and someone please add “I-unsound ”
ACTUALLY… the error after adding the whitespace disappears again with . Which would explain why it isn’t reproducable in the playground. Might be related to label A-incr-comp.
This test doesn't seem to compile with the most recent nightly but I don't think the underlying issue has been fixed. Not sure how to retrigger this issue
Change:
<ins> // exact-check // This test ensures that methods from blanket impls of not available foreign traits // don't show up in the search results. const EXPECTED = { 'query': 'equivalent', 'others': [], }; </ins>

Discussion:
I was checking if exposed  and found these seemingly non existent methods
It looks like the search results are present on (and after), but not on (or before)
Seems that's when std's hashbrown was upgraded to that the trait -