jiebi/CodeConvo huggingface dataset:
Change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Rebase over , then run . I think this is the test. cc but I think this is an issue with rustcerrors, not clippy itself. <!-- 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 is from a diagnostic constructed in a pre-expansion pass. Maybe this has something to do with the ICE
I'm able to reproduce this by running with the following contents: And it needs .
I thought this had been solved by a recent PR :(
No, I just avoided a malformed span that was hitting the same ICE The ICE itself will occur for any multi line span where the end is to the left of the start:

Discussion:
}); buf.push_str(&part.snippet); let cur_hi = sm.lookup_char_pos(part.span.hi()); <del> if prev_hi.line == cur_lo.line { </del> <ins> if prev_hi.line == cur_lo.line && cur_hi.line == cur_lo.line { </ins> // Account for the difference between the width of the current code and the // snippet being suggested, so that the *later* suggestions are correctly // aligned on the screen.

<ins> // check-pass trait X { fn test(x: u32, ( //~^ WARN anonymous parameters are deprecated and will be removed in the next edition //~^^ WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2018! )) {} } fn main() {} </ins>

<ins> warning: anonymous parameters are deprecated and will be removed in the next edition --> $DIR/issue-89280-emitter-overflow-splice-lines.rs:4:21 | LL |       fn test(x: u32, ( |  _____________________^ LL | | LL | | LL | |     )) {} | |_____^ | = note: `#[warn(anonymous_parameters)]` on by default = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2018! = note: for more information, see issue #41686 <https://github.com/rust-lang/rust/issues/41686> help: try naming the parameter or explicitly ignoring it | LL ~     fn test(x: u32, _: ( LL + LL + LL ~     )) {} | warning: 1 warning emitted </ins>
Change:
Functions using the calling convention return values in one of three ways (): 32 bits or smaller: in register 33-64 bits: in and registers 65 bits or larger: by a pointer passed into the function from the calling code In the third case, the pointer is not considered to be part of the argument list size for the purposes of the name mangling suffix. For example: However, if we try to link to this function from Rust: Then we get a linker error because the argument list size is incorrectly calculated as instead of : Thanks to for the !
Does this only affect or does it also affect on 32-bit Windows? Probably not the place to ask, but: and on both follow the x64 default calling convention (which functionally extends the convention), as it is the default calling convention for the platform, right?
I think on 32-bit Windows would be the which doesn't append the parameter size in bytes to the decorated name so there should be no issue there. I believe the affected calling conventions are , and . That should be the case, yes. AFAIK, the only supported calling conventions on x8664-pc-windows-msvc are and .
Probably need to update LLVM here: I imagine something like this in the loop would work:
Based on the LLVM Lang Ref, it read to me like just the presence of the attribute would be sufficient to indicate the parameter size should not be included. Therefore my patch looks like this: Does that seem reasonable to you or do you think we should include the additional check for ?
Ah, you're right, just checking for sret should suffice.

Discussion:
<del> Subproject commit cba558df777a045b5657d56c29944e9e8fd3a776 </del> <ins> Subproject commit 522c3e3d9c097b53ede7682cc28544b461597b20 </ins>
Change:
Here's a minimized version of the code I'm working with: Compiling this on stable or nightly gives a warning on the indicated line, despite the attribute on . A similar issue was reported before in , and addressed in a follow-up PR , but it seems to be cropping up again here, maybe because a non-ASCII field name is involved. It was agreed in that punning of non-snake-case fields in patterns should not produce an additional warning, so I think this is a bona fide bug. (Incidentally, on stable the same warning appears twice in the compiler output, but this duplication seems to be fixed on nightly.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It's actually unrelated to the non-ASCII field names; reduced: claim
Thanks

Discussion:
if let hir::Node::Pat(parent_pat) = cx.tcx.hir().get(cx.tcx.hir().get_parent_node(hid)) { if let PatKind::Struct(_, field_pats, _) = &parent_pat.kind { <del> for field in field_pats.iter() { if field.ident != ident { // Only check if a new name has been introduced, to avoid warning // on both the struct definition and this pattern. self.check_snake_case(cx, "variable", &ident); } </del> <ins> if field_pats .iter() .any(|field| !field.is_shorthand && field.pat.hir_id == p.hir_id) { // Only check if a new name has been introduced, to avoid warning // on both the struct definition and this pattern. self.check_snake_case(cx, "variable", &ident); </ins> } return; }

<ins> // Regression test for #89469, where an extra non_snake_case warning was // reported for a shorthand field binding. // check-pass #![deny(non_snake_case)] #[allow(non_snake_case)] struct Entry { A: u16, a: u16 } fn foo() -> Entry {todo!()} pub fn f() { let Entry { A, a } = foo(); let _ = (A, a); } fn main() {} </ins>
Change:
If they are significant, we can't be merging functions completely with , it would have to leave behind stubs. If they aren't significant, we should be marking all of them as so that will be allowed to merge them without leaving stubs.
Nominating for the backwards compatible milestone (well defined would work too).
Accepted backwards-compatible

Discussion:
}; lib::llvm::SetFunctionCallConv(llfn, cc); <ins> // Function addresses in Rust are never significant, allowing functions to be merged. lib::llvm::SetUnnamedAddr(llfn, true); </ins> return llfn; }
Change:
Otherwise, if too long we can't read them: ! With rule: !
You probs want so that it tries to not wrap mid-word (but still does if it can't do otherwise).
With your suggestion it gives: ! It's weird but in a different way haha.
We can tell the browser where to break words by inserting in the right places. E.g. . Together with some other CSS properties that should give us full control where it'll do the breaking.
it's not clear to me that makes wrapping word-aware (that would be quite a task!) In other words, vs differ only in whether the wrap : Emphasis mine. We don't explicitly use min-content in our CSS as far as I can tell, but looking at the screenshots shared, perhaps it is introduced somewhere by browser intrinsics? Long story short, I think we should use . It produces nicer results in these screenshots, and isn't documented to provide benefits that we care about.
I'm certainly not a CSS expert, I just meant "let's not break idents in the middle" and assumed would be enough for that. It seems like gave the proper answer for breaking correctly around instead of in the middle of the words.

Discussion:
.docblock { margin-left: 12px; } <ins> .docblock code { overflow-wrap: anywhere; } </ins> }

<ins> // If we have a long `<code>`, we need to ensure that it'll be fully displayed on mobile, meaning // that it'll be on two lines. emulate: "iPhone 8" // it has the following size: (375, 667) goto: file://|DOC_PATH|/test_docs/long_code_block/index.html // We now check that the block is on two lines: show-text: true // We need to enable text draw to be able to have the "real" size // Little explanations for this test: if the text wasn't displayed on two lines, it would take // around 20px (which is the font size). assert-property: (".docblock p > code", {"offsetHeight": "42"}) </ins>

pub mod huge_amount_of_consts { include!(concat!(env!("OUT_DIR"), "/huge_amount_of_consts.rs")); } <ins> /// Very long code text `hereIgoWithLongTextBecauseWhyNotAndWhyWouldntI`. pub mod long_code_block {} </ins>
Change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: Both assertions succeed. Instead, this happened: The second assertion fails, likely due to : Although adding a separator when pushing an empty path is debatable, the behavior should probably be consistent for verbatim and non-verbatim paths. This change caused to . I can add an inefficient workaround, but is this change intentional? <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.56.0-beta.4 <!-- Provide the version you are using that has the regression. --: modify labels: +regression-from-stable-to-nightly -regression-untriaged +O-windows cc
This is an interesting case. The normpath crate has its own path push function to work around the issue of verbatim paths not working with PathBuf::push(), which is exactly the same issue that my PR was trying to solve upstream. The normpath push() function uses pathbuf push function to append a directory separator by calling . Since the pathbuf push now already returns normalized paths (for verbatim paths) this no longer works. I've created a PR on normpath to fix the issue there: So since verbatim paths have special handling to ensure the returned path normalized, yes there are differences. If you call on a verbatim path, then the path will remain unchanged, otherwise it would not be valid any more. We cannot expect push to work the same on verbatim paths as on non-verbatim paths, verbatim paths must be normalized.
Hm, should this not be special cased so that it works the same for all paths? Otherwise the only way to push a trailing separator is to convert to an , push the separator and then convert back to a . IMHO, ideally this would be fixed in so that trailing slashes are never normalized away but I'm uncertain if that change will be accepted.
We could special case it so that is a no-op in all cases.
Would this break existing code though?
on second thought, maybe you are right. Let me see what I can do.

Discussion:
/// * if `path` has a root but no prefix (e.g., `windows`), it ///   replaces everything except for the prefix (if any) of `self`. /// * if `path` has a prefix but no root, it replaces `self`. <ins> /// * if `self` has a verbatim prefix (e.g. `?C:windows`) ///   and `path` is not empty, the new path is normalized: all references ///   to `.` and `..` are removed. </ins> /// /// # Examples ///

self.as_mut_vec().truncate(0); // verbatim paths need . and .. removed <del> } else if comps.prefix_verbatim() { </del> <ins> } else if comps.prefix_verbatim() && !path.inner.is_empty() { </ins> let mut buf: Vec<_> = comps.collect(); for c in path.components() { match c {

tp!(r"?A:xy", "/foo", r"?A:foo"); tp!(r"?A:", r"..foo.", r"?A:foo"); tp!(r"?A:xy", r".foo.", r"?A:xyfoo"); <ins> tp!(r"?A:xy", r"", r"?A:xy"); </ins> } }
Change:
shows this annotation: This doesn't seem very useful for an end-user, and this annotation shows for every page in the documentation. This issue also affects crate.
the fix is to add to the crate root; it would be a good first PR :)

Discussion:
)] #![cfg_attr( not(bootstrap), <del> doc(cfg_hide(not(test), not(any(test, bootstrap)), target_has_atomic = "ptr")) </del> <ins> doc(cfg_hide( not(test), not(any(test, bootstrap)), any(not(feature = "miri-test-libstd"), test, doctest), target_has_atomic = "ptr" )) </ins> )] #![no_std] #![needs_allocator]

not(bootstrap), doc(cfg_hide( not(test), <ins> any(not(feature = "miri-test-libstd"), test, doctest), </ins> target_pointer_width = "16", target_pointer_width = "32", target_pointer_width = "64",
Change:
Interpreter calls on zero variant enum, when asked unsafely to do so :-). label: +requires-nightly +A-const-eval
cc
Ah, nasty unsafe code is nasty. ;) This reminds me of discussions I had with a while ago about the for 0-variant enums. Basically the bad code is like but is this really the only part of the compiler that assumes that for , we can use ?
FTR this is the layout of the empty enum: The fix could be to make return for 0-variant enums (treating them basically like any other type that does not actually have a discriminant) to add some logic in that avoids calling for 0-variant enums I haven't made up my mind yet about which one seems better... but I am leaning towards the first option.
As pointed out at , our codegen backend actually says that on any uninhabited type is UB. If we want to stick to that, this limits our options, at least for Miri (CTFE does not have to do all the same checks): pretty much the only clean solution I can think of is to require the place to contain data that satisfies the validity invariant. CTFE does not check validity invariants, so this does not clearly say what we should do there; we could still treat all types without discriminants the same (by returning 0).
In release mode returns an undef (look at llvm IR) even though from all docs it should be sound. At least as long as is sound, which I don't know if it has been decided yet.
I have not been able to weaponize it, but we should probably just make the codegen backend return 0
In my book is not sound, but indeed it has not been decided yet.
In , things look like we should properly check full validity of a value when reading its discriminant. However, that on its own cannot fix this ICE since the first thing validity checking will do is of course read the discriminant...

Discussion:
) -> Option<Discr<'tcx>> { match self.kind() { TyKind::Adt(adt, _) if adt.variants.is_empty() => { <del> bug!("discriminant_for_variant called on zero variant enum"); </del> <ins> // This can actually happen during CTFE, see // https://github.com/rust-lang/rust/issues/89765. None </ins> } TyKind::Adt(adt, _) if adt.is_enum() => { Some(adt.discriminant_for_variant(tcx, variant_index))

const TEST_V: Discriminant<SingleVariant> = discriminant(&SingleVariant::V); <ins> pub const TEST_VOID: () = { // This is UB, but CTFE does not check validity so it does not detect this. // This is a regression test for https://github.com/rust-lang/rust/issues/89765. unsafe { std::mem::discriminant(&*(&() as *const () as *const Void)); }; }; </ins> fn main() { assert_eq!(TEST_A, TEST_A_OTHER); assert_eq!(TEST_A, discriminant(black_box(&Test::A(17))));
Change:
I came across this while working on . Sadly I wasn't really able to minimize this. this branch: and go to (but other commits will likely work too). to and paste in the following:
See also
Slightly minimized: place in Then run: will produce the ICE.
Caused by , cc That PR renames a lot of diagnostic items, but didn't use to gate the name change, so causes breakage when compiling stage 0 std or stage 1 compiler.
Oops, sorry!

Discussion:
.filter_map(|lang_item| self.tcx.lang_items().require(*lang_item).ok()) .collect(); <del> never_suggest_borrow.push(self.tcx.get_diagnostic_item(sym::Send).unwrap()); </del> <ins> if let Some(def_id) = self.tcx.get_diagnostic_item(sym::Send) { never_suggest_borrow.push(def_id); } </ins> let param_env = obligation.param_env; let trait_ref = poly_trait_ref.skip_binder();

/// [arc]: ../../std/sync/struct.Arc.html /// [ub]: ../../reference/behavior-considered-undefined.html #[stable(feature = "rust1", since = "1.0.0")] <del> #[cfg_attr(not(test), rustc_diagnostic_item = "Send")] </del> <ins> #[cfg_attr(all(not(test), bootstrap), rustc_diagnostic_item = "send_trait")] #[cfg_attr(all(not(test), not(bootstrap)), rustc_diagnostic_item = "Send")] </ins> #[rustc_on_unimplemented( message = "`{Self}` cannot be sent between threads safely", label = "`{Self}` cannot be sent between threads safely"
Change:
's stm32f4 is failing:
I suspect this is caused by , merged in (rollup) and root PR -- is this expected breakage (i.e., code in stm32f4 is unsound/should never have been accepted)?

Discussion:
.collect::<SmallVec<[RegionId; 8]>>(); // Sort the id list so that the algorithm is deterministic ids.sort_unstable(); <ins> ids.dedup(); </ins> let ids = ids; match &ids[..] { // Create a new connected region

impl Bar<A> { fn foo() {} } impl Bar<B> { fn foo() {} } <ins> // Regression test for issue #89820: impl Bar<u8> { pub fn a() {} pub fn aa() {} } impl Bar<u16> { pub fn b() {} pub fn bb() {} } impl Bar<u32> { pub fn a() {} pub fn aa() {} pub fn bb() {} pub fn b() {} } </ins> fn main() {}
Change:
<brIn current stable, and nightly-2021-08-28: ! <brIn current beta, current nightly, and nightly-2021-08-29: ! <brNotice that appears twice in the sidebar under the list of macros exported by the crate. Bisects to .
searched nightlies: from nightly-2021-08-10 to nightly-2021-09-26 regressed nightly: nightly-2021-08-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It looks like in both versions there's also a bug where is not shown.
I think the fix here is to show "pub use repro as repro2" in the crate root - it sounds like currently it's being unconditionally inlined and then on top of that using the original name instead of the new one.
This also affect the unstable json output of rustdoc. If we take the example given by there are 3 items (1 reexport + 2 macro) instead of only two: The bug seems that the macro appears for whatever reason 2 times instead of only one.

Discussion:
// the rexport defines the path that a user will actually see. Accordingly, // we add the rexport as an item here, and then skip over the original // definition in `visit_item()` below. <ins> // // We also skip `#[macro_export] macro_rules!` that have already been inserted, // it can happen if within the same module a `#[macro_export] macro_rules!` // is declared but also a reexport of itself producing two exports of the same // macro in the same module. let mut inserted = FxHashSet::default(); </ins> for export in self.cx.tcx.module_exports(CRATE_DEF_ID).unwrap_or(&[]) { if let Res::Def(DefKind::Macro(_), def_id) = export.res { if let Some(local_def_id) = def_id.as_local() { if self.cx.tcx.has_attr(def_id, sym::macro_export) { <del> let hir_id = self.cx.tcx.hir().local_def_id_to_hir_id(local_def_id); let item = self.cx.tcx.hir().expect_item(hir_id); top_level_module.items.push((item, None)); </del> <ins> if inserted.insert(def_id) { let hir_id = self.cx.tcx.hir().local_def_id_to_hir_id(local_def_id); let item = self.cx.tcx.hir().expect_item(hir_id); top_level_module.items.push((item, None)); } </ins> } } }

<ins> // edition:2018 #![no_core] #![feature(no_core)] // @count macro.json "$.index[*][?(@.name=='macro')].inner.items[*]" 2 // @set repro_id = macro.json "$.index[*][?(@.name=='repro')].id" // @has - "$.index[*][?(@.name=='macro')].inner.items[*]" $repro_id #[macro_export] macro_rules! repro { () => {}; } // @set repro2_id = macro.json "$.index[*][?(@.inner.name=='repro2')].id" // @has - "$.index[*][?(@.name=='macro')].inner.items[*]" $repro2_id pub use crate::repro as repro2; </ins>

<ins> // edition:2018 #![no_core] #![feature(no_core)] // @matches 'issue_89852/sidebar-items.js' '"repro"' // @!matches 'issue_89852/sidebar-items.js' '"repro".*"repro"' #[macro_export] macro_rules! repro { () => {}; } pub use crate::repro as repro2; </ins>
Change:
I tried this code: I expected to see this happen: code compiles successfully Instead, this happened: : : modify labels: +requires-nightly +F-typealiasimpl_trait
This is fixed now

Discussion:
<ins> #![feature(type_alias_impl_trait)] type Foo = impl Fn() -> Foo; fn foo() -> Foo { foo //~ ERROR: overflow evaluating the requirement `fn() -> Foo {foo}: Sized` } fn main() {} </ins>

<ins> error[E0275]: overflow evaluating the requirement `fn() -> Foo {foo}: Sized` --> $DIR/issue-53398-cyclic-types.rs:6:5 | LL |     foo |     ^^^ | = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`issue_53398_cyclic_types`) error: aborting due to previous error For more information about this error, try `rustc --explain E0275`. </ins>

<ins> // check-pass #![feature(generators, generator_trait)] #![feature(type_alias_impl_trait)] use std::ops::{Generator, GeneratorState}; use std::pin::Pin; type RandGenerator<'a> = impl Generator<Return = (), Yield = u64> + 'a; fn rand_generator<'a>(rng: &'a ()) -> RandGenerator<'a> { move || { let _rng = rng; loop { yield 0; } } } pub type RandGeneratorWithIndirection<'a> = impl Generator<Return = (), Yield = u64> + 'a; pub fn rand_generator_with_indirection<'a>(rng: &'a ()) -> RandGeneratorWithIndirection<'a> { fn helper<'b>(rng: &'b ()) -> impl 'b + Generator<Return = (), Yield = u64> { move || { let _rng = rng; loop { yield 0; } } } helper(rng) } fn main() { let mut gen = rand_generator(&()); match unsafe { Pin::new_unchecked(&mut gen) }.resume(()) { GeneratorState::Yielded(_) => {} GeneratorState::Complete(_) => {} }; } </ins>

<ins> // check-pass #![feature(type_alias_impl_trait)] trait SomeTrait {} impl SomeTrait for () {} trait MyFuture { type Output; } impl<T> MyFuture for T { type Output = T; } trait ReturnsFuture { type Output: SomeTrait; type Future: MyFuture<Output = Result<Self::Output, ()>>; fn func() -> Self::Future; } struct Foo; impl ReturnsFuture for Foo { type Output = impl SomeTrait; type Future = impl MyFuture<Output = Result<Self::Output, ()>>; fn func() -> Self::Future { Result::<(), ()>::Err(()) } } fn main() {} </ins>

<ins> #![feature(type_alias_impl_trait, generator_trait, generators)] use std::ops::Generator; trait Runnable { type Gen: Generator<Yield = (), Return = ()>; fn run(&mut self) -> Self::Gen; } struct Implementor {} impl Runnable for Implementor { type Gen = impl Generator<Yield = (), Return = ()>; fn run(&mut self) -> Self::Gen { move || { //~ ERROR: type mismatch resolving yield 1; } } } fn main() {} </ins>

<ins> error[E0271]: type mismatch resolving `<[generator@$DIR/issue-94429.rs:16:9: 18:10] as Generator>::Yield == ()` --> $DIR/issue-94429.rs:16:9 | LL | /         move || { LL | |             yield 1; LL | |         } | |_________^ expected integer, found `()` error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </ins>