jiebi/CodeConvo huggingface dataset:
Change:
<ins> // check-pass pub trait Backend { type DescriptorSetLayout; } pub struct Back; impl Backend for Back { type DescriptorSetLayout = u32; } pub struct HalSetLayouts { vertex_layout: <Back as Backend>::DescriptorSetLayout, } impl HalSetLayouts { pub fn iter<DSL>(self) -> DSL where Back: Backend<DescriptorSetLayout = DSL>, { self.vertex_layout } } 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</detailsThis came from a workaround for what seems to be an old compiler bug. removing the workaround gets ride of the ICE: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Can you post what your dependencies are? Or include the statements? Ideally with the versions too. Or something that can just be stuck in a that compiles? I'm not sure where the is coming from in the code above (in the struct layout)
Of course, my bad for not providing this upfront. I've been able to repo it with this setup: deps/features:
Ah yes, thank you very much. I can reproduce it (with the feature, so all the other crates can presumably be removed). I'll look into this.
For reference, minimised it down to this: I also bisected this, and it turns out to be the same rollup as in ... So I suspect both these errors were introduced in the same commit. Interesting! Edit: Adjusted the code (edit2: twice!), check comment history for the original.
Here is the MIR for the function when I manually disabled validation (I just noticed, validation doesn't have to be disabled, works anyways)
After looking into this a bit, I got the following: The body is treating the generic type and the concrete associated type to be of the same type. The MIR validator probably thinks that this is very sketchy and bails out (I haven't looked at it closely). This is actually ok though, since in the where bounds is constrained to be equal to . To me, this looks like a bug in the MIR validator.
This was probably regressed by .

cc
Yes, manually reverting the PR fixed the issue for me locally.
While it regressed in that PR, the PR only called validation that wasn't called before. The validation has been broken for longer.
claim
Probably just needs a normalize call somewhere :thinking:
Does not ICE any more after . Test in .
Oooppsss... Sorry, this test still ICE. On the bright side, I was able to reduce the compiler arguments to .
Change:
location: Location, ) { if let mir::Rvalue::Ref(_, kind, ref borrowed_place) = *rvalue { <del> let is_mut = match kind { mir::BorrowKind::Mut { .. } => true, | mir::BorrowKind::Shared | mir::BorrowKind::Shallow | mir::BorrowKind::Unique => { !borrowed_place .ty(self.body, self.tcx) .ty .is_freeze(self.tcx, self.param_env, DUMMY_SP) } }; if is_mut { </del> <ins> if self.borrow_allows_mutation(kind, borrowed_place) { </ins> match borrowed_place.base { mir::PlaceBase::Local(borrowed_local) if !borrowed_place.is_indirect() => self.trans.gen(borrowed_local),

Discussion:
This code: Errors on with this message:
cc
regression in
I'm still building a compiler with graphviz debugging enabled so I can have a closer look, but I have a theory. I believe the problem is that we are too conservative when marking locals as . Because we pessimistically assume that type is , we also assume that type can be mutated through a shared reference. Once a shared reference to it is taken, we assume that all qualifs that could apply to are applied to that local. We should special case zero-sized arrays here, so when the borrow of occurs, it is not marked as indirectly mutable. Perhaps we could assume that zero-sized arrays never actually as well? While this change would solve this particular issue, I believe that this won't solve the problem entirely. What if we take two references to the zero-sized type ()? While the local containing the ZST itself will not be marked as indirectly mutable, the local containing the first borrow will be, which diverges from the old analysis. We may need to base whether a is indirectly mutable on the analysis.
Change:
<ins> // edition:2021 // [next] compile-flags: -Zlower-impl-trait-in-trait-to-assoc-ty // revisions: current next #![feature(return_position_impl_trait_in_trait)] struct Wrapper<T>(T); trait Foo { fn bar() -> Wrapper<Missing<impl Sized>>; //~^ ERROR: cannot find type `Missing` in this scope [E0412] } impl Foo for () { fn bar() -> Wrapper<i32> { Wrapper(0) } } 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
cc
Probably just need to suppress this assertion if the signature of the trait references . This could use a good explanation for why we ICE, though.
Ohh I've just pushed a fix and now read your comment. Your idea is better.
Change:
} </style> <del> Welcome to an overview of the documentation provided by the Rust project. </del> <ins> Welcome to an overview of the documentation provided by the [Rust project]. </ins> All of these projects are managed by the Docs Team; there are other unofficial documentation resources as well!

Discussion:
We have no link from to , and it is not good in terms of usability. I guess this is because is a verbatim copy of the raw output from . See how Python documents are organized: ! I think this is the relevant functionality of the Sphinx documentation tool for Python: We should aim for the same level of usability standard and should be flexible enough to achieve it.
Generally, people come to from But that might be a good thing to add it.
Also, I don't think this can be a rustdoc thing, because many, many rustdoc outputs are not hosted on rust-
(Rustdoc already lets you choose where the logo links to, iiirc, but it's usually the docs rather than another site.)
I'm not saying rustdoc should hard-code a link to If you write a Rust library and publicize its documentation, you might want a backlink from the generated HTML to I'm claiming there should be a general mechanism to realize such designs. Thankfully rustdoc supports these command line options which seem promising: I'll try see how they fit my proposal.
now links to , many times
Oh wait, this is the inverse issue, sorry for the noise! There hasn't been any change here.
Triage: may fix this, but there's been no change
redirects to today, but I think we probably want these links from e.g. as well so leaving open.
Triage: this would be pretty easily fixed by modifying the index page for
Change:
LL | async fn private_future2(rc: Rc<[u8]>, cell: &Cell<usize>) -> bool { |                          ^^ has type `std::rc::Rc<[u8]>` which is not `Send` = note: `std::rc::Rc<[u8]>` doesn't implement `std::marker::Send` <del> note: captured value is not `Send` </del> <ins> note: captured value is not `Send` because `&` references cannot be sent unless their referent is `Sync` </ins> --> $DIR/future_not_send.rs:20:40 | LL | async fn private_future2(rc: Rc<[u8]>, cell: &Cell<usize>) -> bool { <del> |                                        ^^^^ has type `&std::cell::Cell<usize>` which is not `Send` </del> <ins> |                                        ^^^^ has type `&std::cell::Cell<usize>` which is not `Send`, because `std::cell::Cell<usize>` is not `Sync` </ins> = note: `std::cell::Cell<usize>` doesn't implement `std::marker::Sync` error: future cannot be sent between threads safely

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 compiler helpfully points out that is required, but nonetheless and I both got confused by this error for some time before we noticed it. The suggestion was kind of buried by all the other details.
I'm not sure the ideal output, but it might be something like this:
This error can be replicated without any external crates (i.e., without ) like so:
Change:
if let Some(ty::BindByValue(hir::Mutability::Not)) = cx.tables.extract_binding_mode(cx.tcx.sess, p.hir_id, p.span) { <del> let pat_ty = cx.tables.pat_ty(p); </del> <ins> let pat_ty = cx.tables.pat_ty(p).peel_refs(); </ins> if let ty::Adt(edef, _) = pat_ty.kind { if edef.is_enum() && edef.variants.iter().any(|variant| {

Discussion:
<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This lint was generated by : as we can see is just ignored, so the fix is pretty easy, just all the refs in the type of .
claim
Change:
#![allow(non_camel_case_types)] // ignore-emscripten <ins> // ignore-mips       behavior of simd_select_bitmask is endian-specific // ignore-mips64     behavior of simd_select_bitmask is endian-specific // ignore-powerpc    behavior of simd_select_bitmask is endian-specific // ignore-powerpc64  behavior of simd_select_bitmask is endian-specific </ins> // Test that the simd_select intrinsics produces correct results.

Discussion:
This was found while building rustc 1.33.0 on . Test fails at the third test: The LLVM IR generated for this test case on and (respectively) is identical: The test appears to expect that the bitmask is interpreted as bitwise little-endian (in other words, the LSB selects the first element from the vectors). However, the implementation uses a bitcast to a vector of . On big-endian architectures such as powerpc64, the LSB becomes the last element of this vector, not the first. Unfortunately, all of the upstream test cases are symmetrical, so "choosing the wrong vector" and "reading the bitmask backwards" are indistinguishable. I an additional test case: This passes on , but fails on with: The two "unlike" elements were chosen from the wrong place in the vector. Since the vectors are 256 bits, and the POWER VSX registers are only 128 bits wide, LLVM must split each vector across two registers. The following powerpc64 assembly is from the last test case (), and clearly shows that LLVM (not the hardware) picks the first half of and the second half of : So is this a bug in the test, because it should be ensuring that the bitmask is in native vector/endian order? Or in the implementation of , because it should always take a little-endian bitmask and reverse the bits as necessary?
From it looks like that the bitcast is the intended semantics, so that would mean the test is invalid on big-endian targets. Thoughts, ?
This, we should only enable the test for little endian platforms, maybe adding a new test for big endian platforms.
Change:
unnecessary. However, this also relaxes the guarantees that the restriction provides; so if your invariants depend on data stored within `Cell`, you should be careful. <del> This is useful for mutating primitives and other `Copy` types when there is no easy way of </del> <ins> This is useful for mutating primitives and other types when there is no easy way of </ins> doing it in line with the static rules of `&` and `&mut`. `Cell` does not let you obtain interior references to the data, which makes it safe to freely

Discussion:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.
Change:
let graph = create_graph_with_cycle(); assert!(graph.is_node_cyclic(NodeIndex(1))); } <ins> #[test] fn nodes_in_postorder() { let expected = vec![ ("A", vec!["C", "E", "D", "B", "A", "F"]), ("B", vec!["C", "E", "D", "B", "A", "F"]), ("C", vec!["C", "E", "D", "B", "A", "F"]), ("D", vec!["C", "E", "D", "B", "A", "F"]), ("E", vec!["C", "E", "D", "B", "A", "F"]), ("F", vec!["C", "E", "D", "B", "F", "A"]) ]; let graph = create_graph(); for ((idx, node), &(node_name, ref expected)) in graph.enumerated_nodes().zip(&expected) { assert_eq!(node.data, node_name); assert_eq!(expected, &graph.nodes_in_postorder(OUTGOING, idx) .into_iter().map(|idx| *graph.node_data(idx)) .collect::<Vec<&str>>()); } let expected = vec![ ("A", vec!["D", "C", "B", "A"]), ("B", vec!["D", "C", "B", "A"]), ("C", vec!["B", "D", "C", "A"]), ("D", vec!["C", "B", "D", "A"]), ]; let graph = create_graph_with_cycle(); for ((idx, node), &(node_name, ref expected)) in graph.enumerated_nodes().zip(&expected) { assert_eq!(node.data, node_name); assert_eq!(expected, &graph.nodes_in_postorder(OUTGOING, idx) .into_iter().map(|idx| *graph.node_data(idx)) .collect::<Vec<&str>>()); } } </ins>

Discussion:
See . Here is a chart giving time output from with of the lines of the form uncommented. n -------- With this gist I've tried to create a fairly minimal example. It's not as minimal as maybe it could be because it's a little tricky to figure out what's causing the slow compiles and I've spent as much time as I can on this right now. It's very sensitive to seemingly irrelevant changes in the code. If I remove the unused variable, compile times dramatically improve. If I remove the empty loop, compile times dramatically improve. On my actual project, I am getting compile times in excess of 20 minutes. To compile a few thousand lines of code.
cc
Umm this is not an expansion problem but rather a borrowck problem - dataflow somehow takes O(n) iterations to converge.
Change:
} if let ty::Ref(region, t_type, mutability) = trait_ref.skip_binder().self_ty().kind { <ins> if region.is_late_bound() || t_type.has_escaping_bound_vars() { // Avoid debug assertion in `mk_obligation_for_def_id`. // // If the self type has escaping bound vars then it's not // going to be the type of an expression, so the suggestion // probably won't apply anyway. return; } </ins> let trait_type = match mutability { hir::Mutability::Mut => self.tcx.mk_imm_ref(region, t_type), hir::Mutability::Not => self.tcx.mk_mut_ref(region, t_type),

Discussion:
Using a built from commit with debug assertions enabled ( in ), I'm seeing an internal compiler error on the following input (found by ):
: The second error should probably not be emitted as I believe it is caused by a placeholder lifetime used during recovery. We should introduce (or use if it is already there) a lifetime equivalent to .
This only happens in builds with debug assertions. It's not fixed in master.
Assigning as and removing .
Change:
} } } <ins> // Some UI tests trigger behavior in rustc where it reads $CARGO and changes behavior if it exists. // To make the tests work that rely on it not being set, make sure it is not set. cmd.env_remove("CARGO"); </ins> cmd.env("RUSTC_BOOTSTRAP", "1"); // Override the rustc version used in symbol hashes to reduce the amount of normalization // needed when diffing test output.

Discussion:
:warning: for understanding this issue, you can ignore my messages here. they may be seen as funny though :warning:
hm, this might be entangled with the cursed way i set up with my
hm, even directly fails, so mommy is probably innocent~
So, rustc checks whether is defined. The checked-in test results assume that is set. But somehow it's not set when I execute compiletest, since I get the generic flag suggestions.
actually it probably is related to my cargo-mommy shenanigans, I set in my alias to make cargo-mommy pick up x. This does work for builds, but something seems to confuse test execution.
while the compiletest diff tried to tell me that its not set while it should be, the "unexpected errors" bit tells me that the env var is set while it shouldn't be.
I tried running tests in a fresh checkout free of any shenanigans and that worked fine, so this is a me issue. and no, what seems to be happening is that the var ISN'T set for me, I manually checked the stderr dump from compiletest and it suggests . I also inserted a panic when it is set, and that panic is not triggering.
In both my not working run and the working run, is not set inside of compiletest.
and in both runs, is not set in the output of the rustc .. ???
Okay, I resolved most of my confusion, leaving sane behavior that can be debugged: turns out I blessed these tests into wrongness before seeing what's wrong, so all results were the wrong way around and confusing compiletest does caching slightly differently than I imagined it would do caching Now I'm left with the sane behavior of works and doesn't (so my in the alias is causing the problem) which I think I can figure out.
Or rather, there is nothing to debug anymore. is set, which changes the rustc diagnostic. It's as simple as that.
Change:
} let rustfmt_config = t!(std::fs::read_to_string(&rustfmt_config)); let rustfmt_config: RustfmtConfig = t!(toml::from_str(&rustfmt_config)); <del> let mut ignore_fmt = ignore::overrides::OverrideBuilder::new(&build.src); </del> <ins> let mut fmt_override = ignore::overrides::OverrideBuilder::new(&build.src); </ins> for ignore in rustfmt_config.ignore { <del> ignore_fmt.add(&format!("!{ignore}")).expect(&ignore); </del> <ins> fmt_override.add(&format!("!{ignore}")).expect(&ignore); </ins> } let git_available = match Command::new("git") .arg("--version")

Discussion:
The skipped files are files in the repo that are not tracked by git. It looks like they might still get to the "formatted modified file" counter? I have no other changed files in the repo, so I wonder what rustfmt is saying to have formatted here :sweat_smile:
It detects X files modified, but the fact that they are not tracked means that their rustfmt invocation will be skipped.
It's better to give different counts for skipped and formatted files?
Maybe soemthing like "formatted x files, skipped y untracked files" would make more sense.
The number is actually right, but it's the number of the files that have been modified in the current branch compared to the master branch: you have 86 untracked path in this case. Anywa, we can make it more explicit here.
Change:
message = "`{Self}` is not an iterator" )] #[doc(spotlight)] <ins> #[rustc_diagnostic_item = "Iterator"] </ins> #[must_use = "iterators are lazy and do nothing unless consumed"] pub trait Iterator { /// The type of the elements being iterated over.

Discussion:
Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.
Change:
self_ty, deref.hir_id, probe::ProbeScope::AllTraits, <del> ); </del> <ins> ) else { return; }; </ins> let suggestions: Vec<_> = all_methods .into_iter() .filter(|c| c.item.def_id != pick.item.def_id)

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'called on an value: NoMatch(NoMatchData { staticcandidates: [], unsatisfiedpredicates: [], outofscopetraits: [], similarcandidate: None, mode: MethodCall })'', 'thread 'rustc' panicked at 'called on an value: NoMatch(NoMatchData { staticcandidates: [], unsatisfiedpredicates: [], outofscopetraits: [], similarcandidate: None, mode: MethodCall })'' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc ^^
claim