jiebi/CodeConvo huggingface dataset:
Code change:
fn mir_const_qualif(&self, id: DefIndex) -> mir::ConstQualifs { match self.kind(id) { <del> EntryKind::Const(qualif, _) </del> <ins> EntryKind::AnonConst(qualif, _) | EntryKind::Const(qualif, _) </ins> | EntryKind::AssocConst( AssocContainer::ImplDefault | AssocContainer::ImplFinal

Related discussion:
text: Currently with const generics you can create a "specialized" implementation, such as: Which has the following output: (playground link: ) However, when using such a type in another crate this causes a stack overflow in the compiler. For example, with the following code (full example: ): I would expect it to produce the same output as the playground link above, however it produces the following:
A bisect shows this stopped crashing after , marked as needing a test
I was still encountering this in my code with and after trying to minimize it seems that the original example is fixed but the stack overflow still occurs when the const expression in the has braces around it. After experimenting I found some more examples of what works and what doesn't: (see to try it) compiles and runs successfully while and (or ) crash the compiler with the same error as the original: :
Code change:
<ins> error: expected one of `,` or `>`, found `==` --> $DIR/issue-87493.rs:8:22 | LL |     T: MyTrait<Assoc == S::Assoc>, |                      ^^ expected one of `,` or `>` | help: if you meant to use an associated type binding, replace `==` with `=` | LL |     T: MyTrait<Assoc = S::Assoc>, |                      ~ error[E0107]: this trait takes 0 generic arguments but 1 generic argument was supplied --> $DIR/issue-87493.rs:8:8 | LL |     T: MyTrait<Assoc == S::Assoc>, |        ^^^^^^^------------------- help: remove these generics |        | |        expected 0 generic arguments | note: trait defined here, with 0 generic parameters --> $DIR/issue-87493.rs:1:11 | LL | pub trait MyTrait { |           ^^^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0107`. </ins>

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. --I tried this code: Playground: I expected to see this happen: The error message should indicate that the should be a single . Instead, this happened: The error message gives no hint of the correct syntax. It gives two errors, neither of which are helpful: This error is unhelpful because it says "expected one of or ", but is also allowed. Also, the suggestion to use curly braces is a red herring. This error is unhelpful because I am not specifying const arguments; I'm specifying associated types. Rust version according to 1.53.0
cc
Code change:
RUN /tmp/build-cloudabi-toolchain.sh x86_64-unknown-cloudabi COPY dist-various-2/build-fuchsia-toolchain.sh /tmp/ RUN /tmp/build-fuchsia-toolchain.sh <del> # FIXME(#61022) - reenable solaris # COPY dist-various-2/build-solaris-toolchain.sh /tmp/ # RUN /tmp/build-solaris-toolchain.sh x86_64  amd64   solaris-i386 # RUN /tmp/build-solaris-toolchain.sh sparcv9 sparcv9 solaris-sparc </del> <ins> COPY dist-various-2/build-solaris-toolchain.sh /tmp/ RUN /tmp/build-solaris-toolchain.sh x86_64  amd64   solaris-i386 RUN /tmp/build-solaris-toolchain.sh sparcv9 sparcv9 solaris-sparc </ins> COPY dist-various-2/build-x86_64-fortanix-unknown-sgx-toolchain.sh /tmp/ # We pass the commit id of the port of LLVM's libunwind to the build script. # Any update to the commit id here, should cause the container image to be re-built from this point on.

Related discussion:
text: Today's nightly (25-05-2019) is missing rust-std for: : https://rust- : https://rust-
This was pointed out in and looks to be fixed in It seems that flew in under the radar of where the actual change to disable these targets happened. want to send a PR to revert the changes so the targets are built again?
Yes, I will do it today.
Code change:
pub struct DropLogger<'a, T> { extra: T, id: usize, <del> log: &'a panic::AssertUnwindSafe<RefCell<Vec<usize>>> </del> <ins> log: &'a panic::AssertUnwindSafe<RefCell<Vec<usize>>>, </ins> } impl<'a, T> Drop for DropLogger<'a, T> {

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. --I tried this code: I expected to see this happen: both compiles successfully Instead, this happened: fails to compile <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This may have something to do with , as there is something about let_chain drops here as well, but I don't for sure.
The same behaviour happens with an older compiler version. Here goes an example that compiles with . It is not up to me to decide if this behaviour is a blocker that will revert stabilization but in case of such event, I won't have enough free time to investigate and fix stuff in the near future.
Personally and despite the differences, I think that the version is "correct" and the nested version is surprisingly holding a reference of an owned structure () without an explicit bind.
drops the scrutinee after the statement.
cc who have been dealing with dropping stuff related to
Some things that might be helpful to know: The drop order changes for in also had borrow checker impact and made an example compile (see the PR's thread). I'm not a borrow checker expert, so I might be wrong, but this too might be fixed by drop order changes alone. In I'm studying drop order impacts of conditional statements, motivated by let else, but the test that PR adds also includes let chains. There I observed that let chains generally behave drop order wise like when there is a involved, and when it's a bool. I have only studied them regarding the body contained inside though. This table provides a summary of drop orders (disclaimer: it's outdated for let else):
I've locally amended of to add if let chains: And this is the output: Which actually runs counter to what I wrote above, because it predrops.
Code change:
pub struct DropLogger<'a, T> { extra: T, id: usize, <del> log: &'a panic::AssertUnwindSafe<RefCell<Vec<usize>>> </del> <ins> log: &'a panic::AssertUnwindSafe<RefCell<Vec<usize>>>, </ins> } impl<'a, T> Drop for DropLogger<'a, T> {

Related discussion:
text: It seems that it depends on whether the in the chain is preceded by a or not: if you change the line with to , removing the , you get this: So that rule that I wrote above is not correct, but the underlying behaviour is more complicated. Hmmm...
Thanks
claim
pointed this out to me. It may be motivation to revert the stablization of let-chains on beta. Lets try to ensure we talk about this at Thursday triage label I-compiler-nominated
False alarm; pointed out to me that let-chains is already been marked unstable (on beta and nightly). label: -I-compiler-nominated
Code change:
} } <ins> pub fn rustc_lib_paths(&self, compiler: Compiler) -> Vec<PathBuf> { let mut dylib_dirs = vec![self.rustc_libdir(compiler)]; // Ensure that the downloaded LLVM libraries can be found. if self.config.llvm_from_ci { let ci_llvm_lib = self.out.join(&*compiler.host.triple).join("ci-llvm").join("lib"); dylib_dirs.push(ci_llvm_lib); } dylib_dirs } </ins> /// Adds the compiler's directory of dynamic libraries to `cmd`'s dynamic /// library lookup path. pub fn add_rustc_lib_path(&self, compiler: Compiler, cmd: &mut Command) {

Related discussion:
text: Steps: Checkout commit Have in . In particular, this implies Run Output (on the second run):
cc
For what it’s worth is just what I happened to get after running today. I mentioned it in case something changes later, it’s a coincidence that that commit happens to be related to downloading LLVM from Rust CI.
I think this is a duplicate of
That issue is closed, and its final comment points to this issue.
I just hit this on the following sequence. Do a fresh clone of Run Select option (b) "compiler: Contribute to the compiler itself" Run The build finished like so:
IMO the proper fix for this is to remove error-index's dependency on rustdoc, either by moving the relevant code out into a library that doesn't use rustc_private, or by duplicating the code altogether. There are other ways to solve this but they'll be more complicated and take longer to compile for no real benefit.
by making it invoke rustdoc-the-binary (through ), rather than using rustdoc-the-library.
you should be able to work around this by adding --stage 2 I think.
Thanks, that worked
I think you're right that the binary will be easier - parsing the markdown requires parsing doctests so that it can generate the "Run" button, and parsing doctests requires all of .
Code change:
<ins> error[E0408]: variable `v` is not bound in all patterns --> $DIR/tabs-trimming.rs:9:16 | LL | ...   v @ 1 | 2 | 3 => panic!("You gave me too little money {}", v), // Long text here: TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT... |       -       ^   ^ pattern doesn't bind `v` |       |       | |       |       pattern doesn't bind `v` |       variable not in all patterns error: aborting due to previous error For more information about this error, try `rustc --explain E0408`. </ins>

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:
StatementKind::PlaceMention(place) => { self.visit_place( place, <del> PlaceContext::NonUse(NonUseContext::PlaceMention), </del> <ins> PlaceContext::NonMutatingUse(NonMutatingUseContext::PlaceMention), </ins> location ); }

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. --I tried this code: You need edition 2015 or 2018 to reproduce this. `
Looks to me like the problem is that doesn't realize that a makes the place not dead.
The bug is . is a nonuse, but should get the same treatment as a . I feel obligated to mention that I have repeatedly warned that these bugs are going to happen. We should really stop using in optimizations. It was written for borrowck. (To be clear: I am as much at fault for this as anyone, I originally wrote this code).
I was wondering why always has strangely unhelpful information for optimizations...
Why is this not just a bug in PlaceContext assignment?
See my comment in the PR - in general, my understanding is that the definition of placecontext is what it is because that's what makes sense in some other part of the compiler. If we start changing placecontext now to have the information that's useful to optimizations, I worry we'll just end up making those parts of the compiler buggy
Code change:
} }; <del> if self.suggest_constraining_numerical_ty( </del> <ins> if self.suggest_wrapping_range_with_parens( tcx, actual, source, span, item_name, &ty_str, ) || self.suggest_constraining_numerical_ty( </ins> tcx, actual, source, span, item_kind, item_name, &ty_str, ) { return None;

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 something like this: label +D-confusing +D-invalid-suggestion <!-- 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
Code change:
<ins> //@ aux-build:issue-76736-1.rs //@ aux-build:issue-76736-2.rs // https://github.com/rust-lang/rust/issues/124635 #![crate_name = "foo"] #![feature(rustc_private, staged_api)] #![unstable(feature = "rustc_private", issue = "none")] extern crate issue_76736_1; extern crate issue_76736_2; // @has foo/struct.Foo.html // @has - '//*[@class="impl"]//h3[@class="code-header"]' 'MaybeResult' pub struct Foo; // @has foo/struct.Bar.html // @has - '//*[@class="impl"]//h3[@class="code-header"]' 'MaybeResult' pub use issue_76736_2::Bar; </ins>

Related discussion:
text: for example lists implementations of in , which aren't visible anyway and the links are also broken.
Not present in the docs for 1.77.2, regression?
cc getting multiple reports of this:
I believe this regressed in (
This was closed but it's still happening on current stable docs, in various traits, Debug being the one that seems the worst: ! !
What page are you looking at? I do not see those implementations on
stable docs, not nightly I understand this was reported the day 1.78.0 was released and 1.79.0 isn't due for a few weeks more, but I feel it should be possible to apply the fix to the current stable docs at least as published on rust- in the meantime
The stable docs are tied to the release, so we would have to make a new release to update them. The fix for this is in 1.80, and will reach stable on July 25.
There's no way to backport it internally? That's unfortunate. I was hoping it would land for 1.79.0 at least
Closing then.
This can in fact be beta backported.
And it was in
Good to know, thank you
Code change:
generics_of => { table } inferred_outlives_of => { table_defaulted_array } super_predicates_of => { table } <ins> implied_predicates_of => { table } </ins> type_of => { table } type_alias_is_lazy => { cdata.root.tables.type_alias_is_lazy.get(cdata, def_id.index) } variances_of => { table }

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. --I tried this code: This compiles fine, however if crateb is a separate crate instead of a local module_, it errors with: This is not fixed by the next solver (). <!-- 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. --:
I was able to narrow this down even further:
yep yep makes sense i'll fix it, sorry
Code change:
if sess.opts.incremental.is_none() { return; } <ins> // This is going to be deleted in finalize_session_directory, so let's not create it if sess.has_errors_or_delayed_span_bugs() { return; } </ins> debug!("save_work_product_index()"); dep_graph.assert_ignored();

Related discussion:
text: When compiling a testcase (e.g. the last snippet in on the current nightly, or any of the other examples in that issue on older compilers) with (or Cargo which does that by default), only the initial run will ICE. Subsequent runs will succeed without an ICE, in the absence of any regular errors. However, changing the relevant code (e.g. adding a space) can cause the query that calls to be recomputed and bring the ICE back. IIUC, incremental compilation stores diagnostics and replays them on subsequent runs, but that appears to not apply to ICEs. cc
It looks like without incremental we output artifacts (like ). Do we do this in case of errors too? It seems bad to produce artifacts after an ICE.
Nominating and proposing P-high (mostly because of potential annoyance factor). This should possibly also be labeled I-unsound under the assumption that under the general case of this issue, we might produce artifacts under subsequent runs that may produce UB traces. (However, it is probable that the user will notice the ICE at some other point in time and therefore discard the artifact.)
The current expected behavior of the compiler is to not save any incremental state if an error occurs. may slip through the cracks here.
In that case, it seems to me like it's a matter of recording the fact that we did a (which we already do, ) and then have this mean "there was an error" in terms of "should we save incremental state?".
Yep, the following check should also take into account: While we are at it, we could also add a similar check to and , as not to waste time producing values that will then be discarded anyway:
I'd like to start contributing to rustc and I wanted to ask if this is a good issue to start on (I have read the rustc book)
Sure, this is a decently good issue to start on and should be pretty interesting in terms of learning the infrastructure. If you get stuck, need help, and want to talk synchronously you can hop into https://rust- and we'll try to help out.
fixes this issue. It would still be good to have a test case for it.
I have started to write the code making this test possible, I'll open a PR shortly
Code change:
Some(hir::CoroutineKind::Coroutine(_)) | Some(hir::CoroutineKind::Desugared(hir::CoroutineDesugaring::Gen, _)) | None => { <del> return hir::ExprKind::Err(self.dcx().emit_err(AwaitOnlyInAsyncFnAndBlocks { await_kw_span, item_span: self.current_item, })); </del> <ins> // Lower to a block `{ EXPR; <error> }` so that the awaited expr // is not accidentally orphaned. let stmt_id = self.next_id(); let expr_err = self.expr( expr.span, hir::ExprKind::Err(self.dcx().emit_err(AwaitOnlyInAsyncFnAndBlocks { await_kw_span, item_span: self.current_item, })), ); return hir::ExprKind::Block( self.block_all( expr.span, arena_vec![self; hir::Stmt { hir_id: stmt_id, kind: hir::StmtKind::Semi(expr), span: expr.span, }], Some(self.arena.alloc(expr_err)), ), None, ); </ins> } };

Related discussion:
text: <!-- [31mICE[0m: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' 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: [hirownerparent] getting HIR parent of [checkunused_traits] checking unused trait imports in crate [analysis] running analysis passes on this crate --
cc
Minimal:
Code change:
extern crate lint_unused_extern_crate as other; // no error, the use * marks it as used <ins> #[macro_use] extern crate core; // no error, the `#[macro_use]` marks it as used </ins> #[allow(unused_imports)] use rand::isaac::IsaacRng;

Related discussion:
text: When on latest rust nightly , you get an ICE when compiling .
Its a pretty recent regression, it can't be reproduced with .
Okay, managed to minimize it: Looks like a regression of . cc any ideas on this?
Yeah, this was caused by an oversight in -- fixed in .
Code change:
}; if self.can_coerce(ref_ty, expected) { if let Ok(src) = cm.span_to_snippet(sp) { <del> let sugg_expr = match expr.node { // parenthesize if needed (Issue #46756) </del> <ins> let needs_parens = match expr.node { // parenthesize if needed (Issue #46756) </ins> hir::ExprKind::Cast(_, _) | <del> hir::ExprKind::Binary(_, _, _) => format!("({})", src), _ => src, </del> <ins> hir::ExprKind::Binary(_, _, _) => true, // parenthesize borrows of range literals (Issue #54505) _ if self.is_range_literal(expr) => true, _ => false, </ins> }; <ins> let sugg_expr = if needs_parens { format!("({})", src) } else { src }; </ins> if let Some(sugg) = self.can_use_as_ref(expr) { return Some(sugg); }

Related discussion:
text: is an incorrect suggestion because has higher precedence than . It should suggest .
If someone wants to tackle this issue, it should be straightforward to fix. In: there should be another branch for , where the path of the call is . This code is a good reference: This issue affects the other range syntaxes too, so those should also be fixed (although these are not — look at for clues).
Hi I'd like to tackle this and take the plunge into the Rust compiler code :)
great! Let me know if you hit any snags or need any more tips. You'll want to add tests for these (in ). The is a good place for general information about the compiler. When you're done, include in the pull request and I'll review it!
you've anticipated most of my newbie questions already :) Thanks for that info, very useful! I'm now in the process of stressing my PC with lots of compiling to actually get started. Skimming the test code I'm really impressed by how easy it is to add "UI" tests for these sorts of things (compile this, expect this error on this line). Snazzy! That's all great, but do you anticipate I should also add "deeper" tests? I guess I'm trying to understand if the scope of this is just pure UI or do I need to touch some syntax parsing/immediate representations, since you mentioned code in . Because the compiler is emitting a syntax suggestion, we might want to assert that the suggestion is correct syntax in the first place. I don't know if that's how deep the rabbit hole goes and if there's a facility to help out, but my hunch is that since we have all of the compiler at hand, why not use it to validate the suggestion syntax? EDIT: OK, reading up on adding new tests to the compiler I encountered mention of , and it seems to be sort-of what I was after.
The issue here is just a diagnostic issue, so checking that we're getting the updated hint is enough. The code in is just helpful to see what ranges like and are desugared into, so you can catch them in — you shouldn't need to modify anything (apart from the test) outside of . It would technically be possible to do something like this, but it would probably be more trouble than it's worth.