jiebi/CodeConvo huggingface dataset:
Code change:
impl EmptyTrait2 for HasEmptyTraits {} #[doc(cfg(feature = "some-feature"))] impl EmptyTrait3 for HasEmptyTraits {} <ins> mod macros; pub use macros::*; </ins>

Related discussion:
text: Hey! Ran into what appears to be a bug - crate's exported macros each appear twice in the left sidebar: ! Toolchain versions (per log): rustc 1.60.0-nightly ( 2022-02-09), docsrs 0.6.0 ( 2022-02-01) Please let me know if I can provide additional info.
Thank you for the report! This is definitely not an issue with itself, but with rustdoc. is this known? Should a rustdoc issue be created?
Not known afaik. Please do file an issue (or transfer this one)!
Seems similar to
Thanks for transferring the issue. One difference between this and - both macros are exported using a wildcard in crate root (not rename):
Well, just another reexport issue. It's common around here. :laughing: I'll try to take a look in the next days.
This is what I have on currently nightly: ! So I guess it's fixed?
Trying locally with the latest nightly (, more current than that of issue open) I get the same initial landing page for but if I click on one of the macros listed (e.g. "drill down") duplicates still appear on the sidebar: ! So the tiny bug is still there, just deeper/hidden on the latest nightly?
Ah indeed! I can also reproduce it now. Will take another look tomorrow then.
Code change:
<ins> // This test ensures that there is no macro duplicates in the sidebar. goto: file://|DOC_PATH|/test_docs/macro.a.html // Waiting for the elements in the sidebar to be rendered. wait-for: ".sidebar-elems .others .macro" // Check there is only one macro named "a" listed in the sidebar. assert-count: ( "//*[@class='sidebar-elems']//*[@class='others']/*[@class='block macro']//li/a[text()='a']", 1, ) // Check there is only one macro named "b" listed in the sidebar. assert-count: ( "//*[@class='sidebar-elems']//*[@class='others']/*[@class='block macro']//li/a[text()='b']", 1, ) </ins>

Related discussion:
text: Hey! Ran into what appears to be a bug - crate's exported macros each appear twice in the left sidebar: ! Toolchain versions (per log): rustc 1.60.0-nightly ( 2022-02-09), docsrs 0.6.0 ( 2022-02-01) Please let me know if I can provide additional info.
Thank you for the report! This is definitely not an issue with itself, but with rustdoc. is this known? Should a rustdoc issue be created?
Not known afaik. Please do file an issue (or transfer this one)!
Seems similar to
Thanks for transferring the issue. One difference between this and - both macros are exported using a wildcard in crate root (not rename):
Well, just another reexport issue. It's common around here. :laughing: I'll try to take a look in the next days.
This is what I have on currently nightly: ! So I guess it's fixed?
Trying locally with the latest nightly (, more current than that of issue open) I get the same initial landing page for but if I click on one of the macros listed (e.g. "drill down") duplicates still appear on the sidebar: ! So the tiny bug is still there, just deeper/hidden on the latest nightly?
Ah indeed! I can also reproduce it now. Will take another look tomorrow then.
Code change:
let parent = tcx.map.get_parent(param.id); <del> if space != TypeSpace && default.is_some() { </del> <ins> if !allow_defaults && default.is_some() { </ins> if !tcx.sess.features.borrow().default_type_parameter_fallback { tcx.sess.add_lint( lint::builtin::INVALID_TYPE_PARAM_DEFAULT,

Related discussion:
text: If I understand correctly, type parameter defaults have no effect in the block . Just like in PR , this should have a warning and then an error. Example cc
Argh, I guess I failed to cover those?
Nominating for triage.
triage: P-high
Code change:
<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_derive(ICE)] pub fn derive(_: TokenStream) -> TokenStream { r#"#[allow(missing_docs)] struct X { }"#.parse().unwrap() } </ins>

Related discussion:
text: <!-- 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. --I encountered an ICE while incorrectly inserting a outer attribute above deriving or inside of a proc-macro. This did not happen with any other derive I tried. <!-- 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
can you please also provide the configuration to reproduce an for your issue? thanks
Sure, sorry for forgetting, here is the mcve: But incase you dont want to see the entire project the for the macro was just: And the of the project to use the macro (and trigger the ICE) was:
Cool, thank you! Here's the result of a bisection: seems to point to PR cc searched nightlies: from nightly-2021-01-01 to nightly-2021-08-11 regressed nightly: nightly-2021-04-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Code change:
//~^^^ ERROR: function takes 1 generic argument but 2 generic arguments were supplied //~^^^^ ERROR: unconstrained generic constant //~^^^^^ ERROR: unconstrained generic constant `{const expr}` <ins> //~^^^^^^ ERROR: unconstrained generic constant `{const expr}` </ins> } fn main() {}

Related discussion:
text: we should change the following function to use a instead of Using a walker causes the control-flow to be a lot more complicated and given that this code is soundness-critical, we should make sure it's as easy to understand as possible <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
}); if check_params && let Some(args) = path.segments.last().unwrap().args { let params_in_repr = tcx.params_in_repr(def_id); <del> for (i, arg) in args.args.iter().enumerate() { </del> <ins> // the domain size check is needed because the HIR may not be well-formed at this point for (i, arg) in args.args.iter().enumerate().take(params_in_repr.domain_size()) { </ins> if let hir::GenericArg::Type(ty) = arg && params_in_repr.contains(i as u32) { find_item_ty_spans(tcx, ty, needle, spans, seen_representable); }

Related discussion:
text: <details<summary<strongFull output including backtrace</strong</summary<p</p</detailsRegression from () <details<summaryBisection details</summarybisected with <a href=''cargo-bisect-rustc</av0.6.4 searched nightlies: from nightly-2022-10-06 to nightly-2022-10-28 regressed nightly: nightly-2022-10-09 searched commit range: regressed commit: Host triple: x8664-apple-darwin </details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
this function call crash for the assertion fail, from the log, is with count = 1, and is also 1 when crashing. Do you have any clue? is implemented at here, I'm still not quite familar with the query part:
It looks like the parens are parsed as generic parameters for a type that doesn't have generic parameters? The simple fix is just check .
I think a reasonable fix is modifying the API for , It reasonable to add assertion for , but it's better to return false for outside of expected range?
Have a test on C++'s , which also has this assertion: emm, it's better to keep it for .
claim
I'd be curious to know if we can maintain an invariant in the HIR that it does not contain generics that do not align with . That was what I assumed when writing that code, but that may be too optimistic.
I considered removing the assert too, but I think it's better to have it since it exposes invalid assumptions as in this case.
We should (replacing the assertion) -- that's probably fine as long as it's understood why the does not line up here, and it's understood why we can't fix it somewhere upstream (e.g. in parsing or lowering instead)
I have a general question for , why we just exit when we find a fatal error in parsing (which can not recover by simply autofix).
Code change:
}); if check_params && let Some(args) = path.segments.last().unwrap().args { let params_in_repr = tcx.params_in_repr(def_id); <del> for (i, arg) in args.args.iter().enumerate() { </del> <ins> // the domain size check is needed because the HIR may not be well-formed at this point for (i, arg) in args.args.iter().enumerate().take(params_in_repr.domain_size()) { </ins> if let hir::GenericArg::Type(ty) = arg && params_in_repr.contains(i as u32) { find_item_ty_spans(tcx, ty, needle, spans, seen_representable); }

Related discussion:
text: I have a real Dev experience when working on , I was editing an file with 3k+ lines of code, and I forgetted remove an extra '{', then the compiler give about 20+ errors, the first two are from parsing: But there are many many other errors from later phases... I need to scroll up several pages to the beginning of error to find the rootcause.
If we can not get valid AST in parsing, later phases such as analysising will report out extra (mostly unhelpful) errors?
The assertion is inside of the data structure. I generally expect data structures to simply assert on pre-conditions. We could put a delay-bug before the call, but that also seems like overkill since that is already on the error-reporting path. I agree there are cases where rustc should quit sooner. But in general I think we have to err on the side of recover-and-continue if there is some possibility that more helpful errors may be emitted.
This can happen. The parser should be more realistic on what it recovers and avoid errors from later passes that do not make sense. A few years back we would stop as soon as any error occurred in a given pass and avoid trying any further evaluation, and that was also a usability issue, because people would get a false sense of "how much work is left to fix". We shouldn't have a blanket evaluation stop, but maybe be more aggressive about pruning the AST when multiple parse errors have occurred.
do you want to take over this issue? I currently don't have any clue about the rootcause. Or we give it an simple fix now.
I can take a look.
Code change:
builder.info(&format!("Assembling stage{} compiler ({})", stage, host)); // Link in all dylibs to the libdir <ins> let stamp = librustc_stamp(builder, build_compiler, target_compiler.host); let proc_macros = builder .read_stamp_file(&stamp) .into_iter() .filter_map(|(path, dependency_type)| { if dependency_type == DependencyType::Host { Some(path.file_name().unwrap().to_owned().into_string().unwrap()) } else { None } }) .collect::<HashSet<_>>(); </ins> let sysroot = builder.sysroot(target_compiler); let rustc_libdir = builder.rustc_libdir(target_compiler); t!(fs::create_dir_all(&rustc_libdir)); let src_libdir = builder.sysroot_libdir(build_compiler, host); for f in builder.read_dir(&src_libdir) { let filename = f.file_name().into_string().unwrap(); <del> if is_dylib(&filename) { </del> <ins> if is_dylib(&filename) && !proc_macros.contains(&filename) { </ins> builder.copy(&f.path(), &rustc_libdir.join(&filename)); } }

Related discussion:
text: do you have the component installed? That adds a bunch more crates to the sysroot.
I believe these are required in rustc-dev as part of the need for (). I'll admit, I still don't fully understand the need for that, as it is quite mind-bending.
They are included in both rustc component and rustc-dev component. The latter are definitely used for example to build clippy, but I don't see reason for inclusion in rustc.
Code change:
<ins> // Copyright 2017 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. struct A; impl A { fn take_mutably(&mut self) {} } fn identity<T>(t: T) -> T { t } // Issue 46095 // Built-in indexing should be used even when the index is not // trivially an integer // Overloaded indexing would cause wrapped to be borrowed mutably fn main() { let mut a1 = A; let mut a2 = A; let wrapped = [&mut a1, &mut a2]; { wrapped[0 + 1 - 1].take_mutably(); } { wrapped[identity(0)].take_mutably(); } } </ins>

Related discussion:
text: Hello, today we've found some weird behaviour of array indexing. Here is the Code snippet: The question is, why is the indexing operator behaves depending on whether we evaluate in place or not.
Highly related question :
Moreover, does not compile too.
points to this being a difference in how builtin indexing works vs overloaded indexing. My cleaned up version of the transcript: Highly related to , which will cause these types of situations to occur more frequently.
As a workaround, you can write an explicit type of which will then allow builtin indexing to happen:
Code change:
<ins> // Copyright 2017 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. struct A; impl A { fn take_mutably(&mut self) {} } fn identity<T>(t: T) -> T { t } // Issue 46095 // Built-in indexing should be used even when the index is not // trivially an integer // Overloaded indexing would cause wrapped to be borrowed mutably fn main() { let mut a1 = A; let mut a2 = A; let wrapped = [&mut a1, &mut a2]; { wrapped[0 + 1 - 1].take_mutably(); } { wrapped[identity(0)].take_mutably(); } } </ins>

Related discussion:
text: It appears that when it's not obvious the index type is , we fall back to overloaded indexing: Fails in constant checking, : And also with the new MIR-based constant checker, :
Code change:
code_offset: usize, margin: Margin, ) { <ins> // Tabs are assumed to have been replaced by spaces in calling code. assert!(!source_string.contains('t')); </ins> let line_len = source_string.len(); // Create the source line we will highlight. let left = margin.left(line_len);

Related discussion:
text: The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim
Code change:
// #55810: Type check patterns first so we get types for all bindings. let scrut_span = scrut.span.find_ancestor_inside(expr.span).unwrap_or(scrut.span); for arm in arms { <del> self.check_pat_top(&arm.pat, scrutinee_ty, Some(scrut_span), true); </del> <ins> self.check_pat_top(&arm.pat, scrutinee_ty, Some(scrut_span), Some(scrut)); </ins> } // Now typecheck the blocks.

Related discussion:
text: <!-- 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 suggest to the user that they need to initialize the enum variant's value in order to use 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 --
Can you give the output of what it should look like?
It should probably look similar to the suggestion given for and So I guess sth. like: Edit: Or instead of saying “to instantiate this tuple variant” we could say “to call this function” like it's done for the erroneous snippet (where is a ).
claim
commit the fix
Code change:
<ins> // GVN may create indirect constants with higher alignment than their type requires. Verify that we // do not ICE during codegen, and that the LLVM constant has the higher alignment. // // compile-flags: -Zmir-opt-level=0 -Zmir-enable-passes=+GVN // compile-flags: -Cno-prepopulate-passes // only-64bit struct S(i32); struct SmallStruct(f32, Option<S>, &'static [f32]); // CHECK: @0 = private unnamed_addr constant // CHECK-SAME: , align 8 fn main() { // CHECK-LABEL: @_ZN20overaligned_constant4main // CHECK: [[full:%_.*]] = alloca %SmallStruct, align 8 // CHECK: call void @llvm.memcpy.p0.p0.i64(ptr align 8 [[full]], ptr align 8 @0, i64 32, i1 false) // CHECK: %b.0 = load i32, ptr @0, align 4, // CHECK: %b.1 = load i32, ptr getelementptr inbounds ({ i32, i32 }, ptr @0, i32 0, i32 1), align 4 let mut s = S(1); s.0 = 3; // SMALL_VAL corresponds to a MIR allocation with alignment 8. const SMALL_VAL: SmallStruct = SmallStruct(4., Some(S(1)), &[]); // In pre-codegen MIR: // `a` is a scalar 4. // `b` is an indirect constant at `SMALL_VAL`'s alloc with 0 offset. // `c` is the empty slice. // // As a consequence, during codegen, we create a LLVM allocation for `SMALL_VAL`, with // alignment 8, but only use the `Option<S>` field, at offset 0 with alignment 4. let SmallStruct(a, b, c) = SMALL_VAL; } </ins>

Related discussion:
text: TBH, the simplest solution is a codegen test, and check that the generated constant has the right over-alignment.
I don't have confidence in my ability to do that, so I think it would unblock you faster if you took this issue. I feel like just this diff is a fix for this ICE: But I don't understand why the assertion was exact in the first place, or what the hazard would be from over-aligning the allocation.
Code change:
<ins> // revisions: cfail #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] // regression test for #79251 #[derive(Debug)] struct Node<K, const D: usize> where SmallVec<K, { D * 2 }>: , { keys: SmallVec<K, { D * 2 }>, } impl<K, const D: usize> Node<K, D> where SmallVec<K, { D * 2 }>: , { fn new() -> Self { panic!() } #[inline(never)] fn split(&mut self, i: usize, k: K, right: bool) -> Node<K, D> { let mut node = Node::new(); node.keys.push(k); //~^ error: no method named node } } #[derive(Debug)] struct SmallVec<T, const D: usize> { data: [T; D], } impl<T, const D: usize> SmallVec<T, D> { fn new() -> Self { panic!() } } fn main() {} </ins>

Related discussion:
text: <!-- 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. --I'm creating this issue mainly because it seems to be a different one than the ones listed in <!-- 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
What command are you running? I tried this code , but I encountered an error that doesn't have a method.
how strange, for me just causes the ice and it doesn't even come to notice that the function is missing. I just ran , and with the newest rustc () I still get the same error as above (in a new cargo project with the code copied from the playground link above).
Just ran again today and still get an ICE. Made the example a bit smaller: Output of (build also fails with the same message): Considering the rustc versions it should be the same that is currently on the playground, however there it does not cause an ICE. Maybe someone could try to reproduce this in a local environment?
can reproduce this locally, not sure why it doesn't ICE on the playground
cc -- it ICEs locally, but not on the playground
Try with ?
That indeed removes the ICE, let me just check which one of the options it is. Adding to the (or profile.release in release mode) section causes the ice to disappear.
That's even weirder. Seems like this is partly an incr-comp bug then.
Note that the ICE occurs in the incr-comp hasher (ICH): So this seems to be an incr-comp bug.
Reposting : So I removed .
Code change:
<ins> // revisions: cfail #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] // regression test for #79251 #[derive(Debug)] struct Node<K, const D: usize> where SmallVec<K, { D * 2 }>: , { keys: SmallVec<K, { D * 2 }>, } impl<K, const D: usize> Node<K, D> where SmallVec<K, { D * 2 }>: , { fn new() -> Self { panic!() } #[inline(never)] fn split(&mut self, i: usize, k: K, right: bool) -> Node<K, D> { let mut node = Node::new(); node.keys.push(k); //~^ error: no method named node } } #[derive(Debug)] struct SmallVec<T, const D: usize> { data: [T; D], } impl<T, const D: usize> SmallVec<T, D> { fn new() -> Self { panic!() } } fn main() {} </ins>

Related discussion:
text: <!-- 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<details<summary<strongQuery Stack</strong</summary<p</p</details
modify labels to +requires-nightly
The following snippet gives the same ICE. The types are intentionally wrong. <details<summary<strongBacktrace</strong</summary<p</p</details<details<summary<strongQuery Stack</strong</summary<p</p</details
Triage: This is now fixed on the recent nightly, marking as E-needs-test.