jiebi/CodeConvo huggingface dataset:
Change:
Path { global: path.global, res: path.res, segments } } <del> crate fn qpath_to_string(p: &hir::QPath<'_>) -> String { let segments = match *p { hir::QPath::Resolved(_, ref path) => &path.segments, hir::QPath::TypeRelative(_, ref segment) => return segment.ident.to_string(), hir::QPath::LangItem(lang_item, ..) => return lang_item.name().to_string(), }; let mut s = String::new(); for (i, seg) in segments.iter().enumerate() { if i > 0 { s.push_str("::"); } if seg.ident.name != kw::PathRoot { s.push_str(&seg.ident.as_str()); } } s } </del> crate fn build_deref_target_impls(cx: &DocContext<'_>, items: &[Item], ret: &mut Vec<Item>) { let tcx = cx.tcx;

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. --code is from <!-- 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
label -T-compiler +T-rustdoc
The playground's nightly compiler doesn't ICE on this example. Are you able to confirm this with the latest nightly?
rustdoc is crashing, not the compiler itself. Playground doesn't have a button for running rustdoc.
MCVE: Marking as P-medium since this happens on valid code.

<!-- 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. --Hi, I hit a strange build failure in CI where fails to build for . Here's a reduced reproducer: <!-- 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'm using current nightly, but this is a regression from stable () to beta (). : points to (in ), but this feels like an LLVM bug. I can't trigger it via and though. The LLVM version matches, but I'm probably not reproducing 's interactions with LLVM faithfully.. Sorry for the noise with obscure target architectures, but I'm reporting the issue here because I don't know how to reproduce it on LLVM's side :slightlysmilingface:
It's fine. We may not offer the best support for them due to technical and resource constraints, but we still want people to have the option to run Rust code on their OpenWRT router or their PlayStation or whatever.
i hit the same problem. build failed for
May be caused by a trigger for
FYI, this can be worked around by enabling optimization. The same workaround works for error from when using build-std in the latest nightly. (, , , )
Maybe its relocation is too far then that has been truncated?
This issue should be fixed by . Initially, the cause of the issue and the solution are explained in , but more elegant solution is just to remove derived isBlockOnlyReachableByFallthrough for Mips architecture.
label llvm-fixed-upstream
Can someone confirm that this is fixed on nightly?
Yep. My initial reproducer fails with but compiles on . :chartwithupwards_trend:
Change:
/// The difference between [`unimplemented!`] and `todo!` is that while `todo!` conveys /// an intent of implementing the functionality later and the message is "not yet /// implemented", `unimplemented!` makes no such claims. Its message is "not implemented". <del> /// Also some IDEs will mark `todo!`s. </del> <ins> /// /// Also, some IDEs will mark `todo!`s. </ins> /// /// # Panics /// <del> /// This will always [`panic!`]. </del> <ins> /// This will always [`panic!`] because `todo!` is just a shorthand for `panic!` with a /// fixed, specific message. /// /// Like `panic!`, this macro has a second form for displaying custom values. </ins> /// /// # Examples ///

Discussion:
The documentation of the macro currently does not mention at all that it also accepts optional format arguments, for example: Other macros like at least have the following sentence under "Panics": So maybe it would be good to do the following? [ ] Update the "Panics" section to be similar to [ ] Extend / adjust example to also show usage of custom message <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Any ? I mostly drew from the docs for , and I also took the liberty of cleaning up some of the formatting/typography.
Thanks! To me this looks good, but I don't know what the maintainers think.
Change:
<ins> // Copyright 2014 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. fn main() {} </ins>

Discussion:
I don't think this has been reported yet. I think better error handling in would make this go away.
Change:
#[unwind(aborts)] // FIXME(#58794) pub unsafe extern "C" fn use_foreign_c_variadic_0() { // Ensure that we correctly call foreign C-variadic functions. <del> // CHECK: invoke void (i32, ...) @foreign_c_variadic_0([[PARAM:i32( signext)?]] 0) </del> <ins> // CHECK: call void (i32, ...) @foreign_c_variadic_0([[PARAM:i32( signext)?]] 0) </ins> foreign_c_variadic_0(0); <del> // CHECK: invoke void (i32, ...) @foreign_c_variadic_0([[PARAM]] 0, [[PARAM]] 42) </del> <ins> // CHECK: call void (i32, ...) @foreign_c_variadic_0([[PARAM]] 0, [[PARAM]] 42) </ins> foreign_c_variadic_0(0, 42i32); <del> // CHECK: invoke void (i32, ...) @foreign_c_variadic_0([[PARAM]] 0, [[PARAM]] 42, [[PARAM]] 1024) </del> <ins> // CHECK: call void (i32, ...) @foreign_c_variadic_0([[PARAM]] 0, [[PARAM]] 42, [[PARAM]] 1024) </ins> foreign_c_variadic_0(0, 42i32, 1024i32); <del> // CHECK: invoke void (i32, ...) @foreign_c_variadic_0([[PARAM]] 0, [[PARAM]] 42, [[PARAM]] 1024, [[PARAM]] 0) </del> <ins> // CHECK: call void (i32, ...) @foreign_c_variadic_0([[PARAM]] 0, [[PARAM]] 42, [[PARAM]] 1024, [[PARAM]] 0) </ins> foreign_c_variadic_0(0, 42i32, 1024i32, 0i32); }

Discussion:
I guess intrinsics need to be ed and not d? Maybe the MIR inliner is inlining the intrinsic's wrapper, but keeps the target intact when it shouldn't. Or this should be handled in codegen, not sure.
The implementation ends up calling pause intrinsic declared as follows: The rustc codegen is completely unaware that it is dealing with an intrinsic, it just changes the symbol name. Looks like the whole feature was introduced by accident, and feature gate was introduced after the fact to make it unstable.
Change:
// when the no_global_oom_handling feature is turned on. // See https://github.com/rust-lang/rust/pull/110649 <del> use run_make_support::{rustc, tmp_dir}; </del> <ins> use run_make_support::{rustc, source_root, tmp_dir}; </ins> fn main() { rustc() .edition("2021") .arg("-Dwarnings") .crate_type("rlib") <del> .input("../../../library/core/src/lib.rs") </del> <ins> .input(source_root().join("library/core/src/lib.rs")) </ins> .sysroot(tmp_dir().join("fakeroot")) .cfg("no_global_oom_handling") .run();

Discussion:
Some run-make tests refer to stdlib sources with which seems not ideal. suggested that we should introduce a helper to make this less fragile.
There is already the env var set by compiletest for the source root.
I'm actually dumb, we even already have in the support library:
That's a very descriptive environment variable name, lol
Change:
<ins> // run-pass struct S<T> { t : T, s : Box<S<fn(u : T)>> } fn f(x : S<u32>) {} fn main () {} </ins>

Discussion:
The following program triggers a stack overflow in rustc: My version of rustc: The problem also appears when replacing with .
Interestingly, I don't see a stack trace with Same version of
Well oddly than not it does look to see if there is about half a GB left on disk and if there is not updating would not work. Which is bad because there actually is enough space if I have an older version of it.
This also happens that sometimes it actually uses over than 1 GB of RAM as well for some insanely small code for some unknown reason.
I don't know what you mean by this, but I do no think this is the problem here. The following program also reveals the problem: rust But the following is accepted: Recursive structs are a well-known and important feature of Rust.
contains an , which contains an , which contains an , which contains...
: it does not /contain/ it. It /refers/ to it. Again, recursive structs are a well-known, important feature of Rust. For example, you cannot define linked lists without them.
The issue is not the storage of the struct. The issue is that you are asking the compiler to generate code for an infinite number of instantiations of . Is a very different thing than
Well, but I am not asking the compiler to generate any code here... Or at least, the code that is generated is not used anywhere.
I'm confused then - why is it valuable for it to be possible to define but never use this type?
Btw, now I understand better why my code provokes a stack overflow. But still, there is no reason this code is generated if the code is never used, and even then, this is not an excuse for rustc to do a stack overflow.
Yes there should be some reasonable recursion limit here.
More importantly, rustc should issue a diagnostic instead of overflowing its stack.
This is no longer reproducible with rustc 1.26.0-nightly ( 2018-03-06).
The phenomenon that is describing [above][] is technically known as "polymorphic recursion." [above]: cc But, as noted by above, this particular instance of the diagnostic issue with polymorphic recursion (that I believe persists to this day) no longer seems to replicate. Marking as E-needstest.
Change:
<ins> fn foo(x: &mut u32) { let bar = || { foo(x); }; bar(); //~ ERROR cannot borrow } fn main() {} </ins>

Discussion:
Compiled with gives:
This was caused by prioritize edit: in beta, this gives the following error: `
Assigning as discussed as part of the and removing .
Looks likely that is the cause. cc
Re-prioritizing as and removing as in the prioritization working group. label: +regression-from-stable-to-nightly +P-high -P-medium -I-prioritize
Change:
<ins> pub trait Trait<'a> { type Assoc; } pub struct Type; impl<'a> Trait<'a> for Type { type Assoc = (); } pub fn break_me<T, F>(f: F) where T: for<'b> Trait<'b>, F: for<'b> FnMut(<T as Trait<'b>>::Assoc) { break_me::<Type, fn(_)>; //~^ ERROR: type mismatch in function arguments //~| ERROR: type mismatch resolving } fn main() {} </ins>

Discussion:
The compiler ices with error "Failed to unify obligation" when I try to compile the following code: I get the following error: : Backtrace:
Another version:
triage: p-medium
minimal version Note that if you pass in the closure to it doesn't ICE the compiler when I used , bud did ICE the compiler when I used /. i.e.
none of the programs provided seem to ICE with the latest nightly.
Change:
<ins> error: unreachable statement --> $DIR/unreachable-lint-1.rs:5:13 | LL |     return; bar().await; |     ------  ^^^^^^^^^^^^ unreachable statement |     | |     any code following this expression is unreachable | note: lint level defined here --> $DIR/unreachable-lint-1.rs:2:9 | LL | #![deny(unreachable_code)] |         ^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
I tried this code: I expected to see this happen: no build warn Instead, this happened: :
We . The likely cause is that parts of the await desugaring are being linted against. We can likely check the span to see if the code that is being linted against is part of the desugaring, but we do want to be careful to ensure that still gets a lint warning.
Marking as deferred as this doesn't seem like a problem that needs to block stabilization.
cc who has done some work on the inhabited logic stuff.
I'm now getting this warning even for functions that loop but eventually return. It worked fine with nightly-2019-08-21, but the latest nightly (2019-09-17) is broken. For example, this code generates a warning: with the warning repeated twice:
Can confirm. I believe this regressed somewhere after nightly 09-09-2019.
I think I have this in my code here: Can somebody confirm this? If not I'll file another bug report.
yeah that's the same, the function can "never" return from the unconditional loop.
Change:
let ty_vars = infcx_inner.type_variables(); let var_origin = ty_vars.var_origin(ty_vid); if let TypeVariableOriginKind::TypeParameterDefinition(name, def_id) = var_origin.kind <del> && !var_origin.span.from_expansion() </del> <ins> && name != kw::SelfUpper && !var_origin.span.from_expansion() </ins> { let generics = infcx.tcx.generics_of(infcx.tcx.parent(def_id)); let idx = generics.param_def_id_to_index(infcx.tcx, def_id).unwrap();

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
Thanks for the ping. It seems to be that here it's not always the parent which has , sometimes its on the as-is. I'm not entirely sure when we need the (IIRC it doesn't work for my test case if I don't add ).
Now if I stick to only using and not its parent, the line ICEs on my PR's test case because it can't find the param index for the . cc sorry for the ping, but do you know if here is special somehow? The debug path for my PR's test case seems to have another layer compared to this issue's ICE example, namely . I think this is why getting for my PR test case's parent worked but not for this ICE?
going to look into this, I think using is correct and the bug is somewhere else :sweat_smile:
Change:
self.resolve_expr(elem, Some(expr)); self.visit_expr(idx); } <ins> ExprKind::Assign(..) => { let old = self.diagnostic_metadata.in_assignment.replace(expr); visit::walk_expr(self, expr); self.diagnostic_metadata.in_assignment = old; } </ins> _ => { visit::walk_expr(self, expr); }

Discussion:
As a python programmer, forgetting a in an assignment to a variable that didn't exist before is an easy mistake to make. () Rust sees two uses of an undefined variable here (E0425 twice): While the second one is fine, in the first case I would have really appreciated a sentence like this: This would helped me as a newcomer to the language, because it does an educated guess what the problem might be and tells me how to fix it. I think the hint should be if the value is assigned to (first error), but not if it is used as an argument (second error). I hope this is the right place and format to file this suggestion, I would appreciate hints if this is not the case. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is the right place, however you should use the "diagnostic" template when creating issues like this. Thanks for the issue though. label +T-compiler +A-diagnostics
claim
Change:
<tr> <td>Stack smashing protection </td> <del> <td>No </del> <ins> <td>Yes </ins> </td> <del> <td> </del> <ins> <td>Nightly </ins> </td> </tr> <tr>

Discussion:
Stack smashing protection was in , but  was never updated. label A-docs
Have you started on this already? I'm available to take this on. I came across the docs before the PR, and was misled about the current state of this feature.
Not yet. Sorry about the confusion caused by it. If you'd have time to and would like to contribute, it'd be much appreciated. Feel free to CC me in the PR and I'd be happy to help reviewing it.
Change:
region_scope_tree: fcx.tcx.region_scope_tree(def_id), expr_count: 0, kind, <ins> prev_unresolved_span: None, </ins> }; intravisit::walk_body(&mut visitor, body);

Discussion:
Consider for example this code (using ): This code will fail to compile due to types which cannot be fully inferred, with an error like this: However neither of these spans are anywhere near to the real problem which is the fact that variant is not inferred for . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
assign will do some investigation here and see if they can get an idea what's going on (and maybe fix)
Change:
<ins> error[E0428]: the name `A` is defined multiple times --> $DIR/issue-69396-const-no-type-in-macro.rs:4:13 | LL |               const A = "A".$fn(); |               ^^^^^^^^^^^^^^^^^^^^ |               | |               `A` redefined here |               previous definition of the value `A` here ... LL | / suite! { LL | |     len; LL | |     is_empty; LL | | } | |_- in this macro invocation | = note: `A` must be defined only once in the value namespace of this module = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: missing type for `const` item --> $DIR/issue-69396-const-no-type-in-macro.rs:4:19 | LL |               const A = "A".$fn(); |                     ^ help: provide a type for the item: `A: usize` ... LL | / suite! { LL | |     len; LL | |     is_empty; LL | | } | |_- in this macro invocation | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> $DIR/issue-69396-const-no-type-in-macro.rs:4:19 | LL |               const A = "A".$fn(); |                     ^ |                     | |                     not allowed in type signatures |                     help: replace `_` with the correct type: `bool` ... LL | / suite! { LL | |     len; LL | |     is_empty; LL | | } | |_- in this macro invocation | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to 3 previous errors Some errors have detailed explanations: E0121, E0428. For more information about an error, try `rustc --explain E0121`. </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
I ran : That's a rollup commit. Of the components of the rollup, looks to me to be most likely to be related. (cc
Hmm, bummer. It looks like they are getting the same span and so the stashed error is overwritten. We might need to insert a there to handle the possibility of span reuse from different things.
triage: P-high. Removing nomination. Added regression stable-to-stable tag.
Fixed in
Change:
ifn!("llvm.is.constant.isize", fn(t_isize) -> i1); ifn!("llvm.is.constant.f32", fn(t_f32) -> i1); ifn!("llvm.is.constant.f64", fn(t_f64) -> i1); <ins> ifn!("llvm.is.constant.ptr", fn(ptr) -> i1); </ins> ifn!("llvm.expect.i1", fn(i1, i1) -> i1); ifn!("llvm.eh.typeid.for", fn(ptr) -> t_i32);

Discussion:
Code 2 Few ICEs with new intrinsic <!-- 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. --: <details<summary<strongBacktrace 1</strong</summary<p</p</details<details<summary<strongBacktrace 2</strong</summary<p</p, so cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
like the intrinsic wasn't to the list at 2 Appears to be the same crash, just panicking at different points. label +F-core_intrinsics -needs-triage
claim
Would that check if the pointer address is constant or the referenced value is constant? I think for , one would expect the reference to be coerced to a . I don't know what to do for slices though.
I think checks for whether or not the the pointer address is statically known. I don't think mutable variables in function bodies can be statically known and references to globals are guaranteed to fold to false. That covers all the cases I thought about but I'm fairly confident I missed something.
They can be. It is usually the result of inlineing. Detecting that is kind of the point of the intrinsic.
Change:
// edition:2018 <ins> #![feature(min_const_generics)] </ins> // @has async_fn/fn.foo.html '//pre[@class="rust fn"]' 'pub async fn foo() -> Option<Foo>' pub async fn foo() -> Option<Foo> {

Discussion:
<img width="1016" alt="rustdoc output screenshot" src="https://user-"This example was tested on Rust 1.46.0, but it has been broken for quite a while. For example, see ).
Relevant code: Not sure what's going wrong.
Thanks for the helpful hint, However, I'm not convinced this is the root cause because it's happening to all mutable by-value function arguments, not just to functions with as the first argument. For example, this free function emits similar results: <img width="1004" alt="Screen Shot 2020-09-15 at 9 56 26 AM" src="https://user-"I think the actual root cause may be deeper than the interpretation of types, but I can't tell for sure.
This example confirms that the behavior appears to be per-argument instead of per-function. It's not like one bad argument ruins the formatting of the entire function. <img width="983" alt="Screen Shot 2020-09-15 at 10 04 39 AM" src="https://user-"Perhaps we could investigate where in the code the text is being generated and work our way backwards to see what is triggering it?
Hmm, the only relevant location I could find through GitHub search is in in : Is operating on a desugared form of the AST? I don't think this is the case, since is being successfully displayed here. Is there something else I'm missing?
Here's the issue: Looks like it should use  instead. Are you interested in making a PR? ;)
Yes, rustdoc works on a desugared version and has to reconstruct the by hand.
Sure, I will prepare one right away. Thanks for investigating with me.