jiebi/CodeConvo huggingface dataset:
Change:
use crate::any::Any; use crate::cell::UnsafeCell; <ins> use crate::collections; </ins> use crate::fmt; use crate::future::Future; use crate::pin::Pin;

Discussion:
Successfully compiles on stable 1.35, fails on beta/pre 1.36.
First reported to FireFox ESR and shared on irlo here:
The impl for requires , but the one for requires .
is a possible fix.
Change:
match self.code { CompareImplMethodObligation { .. } => Error0308("method not compatible with trait"), MatchExpressionArm { source, .. } => Error0308(match source { <del> hir::MatchSource::IfLetDesugar { .. } => "`if let` arms have incompatible types", </del> <ins> hir::MatchSource::IfLetDesugar { .. } => { "`if let` arms have incompatible types" }, hir::MatchSource::TryDesugar => { "try expression alternatives have incompatible types" }, </ins> _ => "match arms have incompatible types", }), IfExpression => Error0308("if and else have incompatible types"),

Discussion:
Given this example: I get this error (): It seems like it should not be talking about =)
Ideally, I would think it should say something like "missing ", but that may be a separate bug -- i.e., maybe we should strive to just produce the same error you would get if you did
Change:
use rustc_errors::ErrorGuaranteed; use rustc_errors::IntoDiagnostic; use rustc_macros::{Diagnostic, LintDiagnostic}; <del> use rustc_span::Span; </del> <ins> use rustc_span::{Span, Symbol}; </ins> #[derive(Diagnostic)] #[diag(monomorphize_recursion_limit)]

Discussion:
The following scenario used to work fine 1.25.0: This would create two .bc files that could be linked together into a program, but when I try this on 1.26.{0,1,2} the compiler crashes like so:
Possibly dupe/related to ?
Yea I think this is a dupe, handling over there
The issue you mention seems to have something to do with impl trait (and looks like it goes away when the use is removed?) , whereas the issue I posted here crashes with even the simplest rust code. Are they really the same?
Hmm... you're right. I mean impl Trait in the other issue is just the trigger, the cause is in a normal function calling another one, but here you have another crate
I've discovered that if I tell the compiler to emit another type along with like this issue goes away. It makes me suspect this piece of code in : I'm wondering if by not running the code-gen or linking when outputting the metadata is causing this.
Triage: still repros:
Since , doesn't include optimized MIR, so produced rlib cannot be used to perform codegen. It would be nice to detect that particular situtation and produce more meaningful error describing that this is unsupported.
PR with fix:
Change:
as the `.rs` file. `--crate-name` lets you override this assumption with whatever name you choose. <ins> ## `--document-private-items`: Show items that are not public Using this flag looks like this: ```bash $ rustdoc src/lib.rs --document-private-items ``` By default, `rustdoc` only documents items that are publicly reachable. ```rust pub fn public() {} // this item is public and will documented mod private { // this item is private and will not be documented pub fn unreachable() {} // this item is public, but unreachable, so it will not be documented } ``` `--document-private-items` documents all items, even if they're not public. </ins> ## `-L`/`--library-path`: where to look for dependencies Using this flag looks like this:

Discussion:
From So not sure which way seems better? What do you think ?
Yeah I think we should document the new stuff and remove the docs for the deprecated stuff (perhaps mention that these deprecated features exist, but not document them in depth)
I've felt confused about this before: Why do we even let people customize which passes are run? That seems like unnecessary entanglement with rustdoc internals.
Also, there doesn't seem to be a flag. Are you thinking of ? If so, rustdoc says that's deprecated. Edit: It looks like is deprecated as well.
What is "the new stuff"? Do you mean things like ? Other than my confusion about that, I agree with Manish here. I think we should mention the deprecated features, but not document them extensively since they shouldn't be used anyway. If we extensively document deprecated features, we are wasting our time and our readers' time.
Yes. I do think the pass infra should stay mostly internal, with specific options being exposed via specific attributes. How we construct it internally should not be something the user should ever have to care about.
Change:
($e: expr) => { $e.x } } <ins> // regression test for #77088 #[stable(feature = "stable", since = "1.0.0")] #[allow_internal_unstable(struct_field)] #[allow_internal_unstable(struct2_field)] #[macro_export] macro_rules! access_field_allow2 { ($e: expr) => { $e.x } } </ins> #[stable(feature = "stable", since = "1.0.0")] #[allow_internal_unstable()] #[macro_export]

Discussion:
Discussed in zulip: https://rust- The problem is that compiler doesn't accept code like this: But it accepts code when merging mutiple annotations into one: : Version 1.48.0-nightly ( 2020-09-22) cc which modified some const stability checks. modify labels: E-mentor
Error: Label P-low can only be set by Rust team members Please let know if you're having trouble with this bot.
just refactored a few individual calls to into a single helper function. only looks for the first attribute it seems. Shouldn't be hard to fix.
assign
Error: Parsing assign command in failed: ...'n bugadani' ''... Please let know if you're having trouble with this bot.
The PR did not actually fix the issue. The test case to the PR also works without the PR. A test case that would fail would actually check whether a second attribute would be honored. Adding a second attribute was silently ignored, and it still is after the PR. Edit: nevermind, all is good:
It doesn't hurt to double check, just takes some time :)
Change:
use rustc_hir::lang_items::{ FutureTraitLangItem, PinTypeLangItem, SizedTraitLangItem, VaListTypeLangItem, }; <del> use rustc_hir::{ExprKind, GenericArg, HirIdMap, Item, ItemKind, Node, PatKind, QPath}; </del> <ins> use rustc_hir::{ExprKind, GenericArg, HirIdMap, ItemKind, Node, PatKind, QPath}; </ins> use rustc_index::bit_set::BitSet; use rustc_index::vec::Idx; use rustc_infer::infer;

Discussion:
I was writing some code that does some x86 page table configuration, but then I noticed that Rust compiler started to panic with this code: And I did realize that I cannot use in since has attribute. If I rewrite the above code without crate: (Note that this is basically same thing as 's struct) This compiler error is displayed, which is normal: And here's output from (In this case, I'm trying to compile the first code): Looking at the backtrace, there's function and : While there's no line number(since the compiler is installed using ), thankfully there are only two calls to inside . And it seems like the first one is panicking since normal output has nothing more than , but I might be wrong. I ran about five minutes ago before submitting this issue, but result was the same. BTW: I initially found this bug in Clippy, but then I noticed that Rustc was doing the same thing.
Assigning [as discussed as part of the Prioritization WG procedure][link]. [link]: https://rust-(in.20some.20cases).20when.20repr(al
Would you please try this again for us?
The second one is one that does not panic rustc(The code that panics rustc is the first one). It is very similar to the first one except that it does not use external crate, and compiling it shows the error I was expecting. Also, the second code was one of my attempts to reproduce the same panic without external crate, but for some reason, it didn't panic the compiler. Only the first code does.
Change:
|             ~~~~~~~~~~~~~~~ error: called `.get().unwrap()` on a slice <del> --> tests/ui-toml/unwrap_used/unwrap_used.rs:93:17 </del> <ins> --> tests/ui-toml/unwrap_used/unwrap_used.rs:94:17 </ins> | LL |         let _ = Box::new([0]).get(1).unwrap(); |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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. --I tried this code: I expected to see this happen: Instead, this happened: Apparently, taking a shared reference of will suppress the lint. This seems like a false negative. While false negatives can't be avoided entirely, this case seems to be avoidable as taking a shared reference shouldn't change the type of (which is ) or modify any data in this example. Note that will trigger the lint properly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
See also .
claim
Note this is a problem because which is supposed to fail to compile but this bug makes it fail at runtime instead
In case no one has dug into it yet, the error is suppressed in but not in and before:
label +regression-from-stable-to-stable
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This is caused by . It only ever worked because the lint ran after optimizations. I made a fix . It specializes the length of arrays as constant, even if the array isn't. I'm going to open a PR when I have time, probably tomorrow. In the long term, I'd like to implement some more extensive tracking of "what parts of a value are constant". For example, the compiler currently assumes that anything that had its reference taken can change, but actually, this can only happen inside (as I understand it).
Labels from the closed duplicate , label A-diagnostics, A-lint, A-mir-opt, T-compiler.
Fixed on stable label E-needs-test
I claim the add test part
This lint only appears on full builds (not check), but this will be fixed once lands.
Reopening because I feel this is not yet solved, see on . As per the , should nail down this issue?
MRE: Also, duplicate of
Another variant of this same issue:
Change:
<ins> //@ compile-flags: -O //@ min-llvm-version: 19 #![crate_type = "lib"] pub enum State { A([u8; 753]), B([u8; 753]), } // CHECK-LABEL: @update #[no_mangle] pub unsafe fn update(s: *mut State) { // CHECK-NEXT: start: // CHECK-NEXT: store i8 // CHECK-NEXT: ret let State::A(v) = s.read() else { std::hint::unreachable_unchecked() }; s.write(State::B(v)); } </ins>

Discussion:
The following code should optimize to a single store of the new discriminant, but doesn't (). Instead, LLVM copies the value to the stack, copies it again and then writes it back. Interestingly, LLVM optimizes this correctly if a third state without value is . : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
lol, looks like this optimizes with but fails to with anything equals or above 2, I think 2 or 3 is the default for builds?
Replacing with also optimizes better: Presumably some issue with MIR inlining; produces the optimal code
The problem is not MIR inlining per se. I think this is the problem was trying to fix in ; if you write your own function without a runtime check, it optimizes fine:
Upstream issue: claim :p
Error: Parsing assign command in failed: ...' claim' ' :p'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
label +llvm-fixed-upstream
Confirmed fixed by , needs codegen test.
Change:
"{}", &len.try_to_scalar() .unwrap() <del> .to_u64() .unwrap_or_else(|_| panic!("failed to convert length to u64")) </del> <ins> .to_target_usize(&tcx.data_layout) .expect("Array lens are defined in usize") </ins> ); s.push_str(&encode_ty(tcx, *ty0, dict, options)); compress(dict, DictKey::Ty(ty, TyQ::None), &mut s);

Discussion:
This is with built as a dev branch, so it's possible this is already fixed in nightly. I locally computed the command it was running, and it's: Since the input file is , this shouldn't technically require more information than what I've gathered, but I'll try to minimize this soon if nobody else immediately knows the answer.
Attached the ICE txt in case someone gets to it before I do.
We shouldn't be unwrapping the array size as a , but actually respect the size of machine.
Change:
<ins> // run-pass // compile-flags: -C overflow_checks=false #![feature(cfg_overflow_checks)] fn main() { assert!(!cfg!(overflow_checks)); assert!(!compiles_differently()); } #[cfg(overflow_checks)] fn compiles_differently()->bool { true } #[cfg(not(overflow_checks))] fn compiles_differently()->bool { false } </ins>

Discussion:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:
Change:
<ins> // Regression test for the ICE described in #95665. // Ensure that the expected error is output (and thus that there is no ICE) pub trait Trait: {} pub struct Struct<T: Trait> { member: T, } // uncomment and bug goes away // impl Trait for u8 {} extern "C" { static VAR: Struct<u8>; //~^ 14:17: 14:27: the trait bound `u8: Trait` is not satisfied [E0277] } 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. --: Also reproduces on 1.58.0 and 1.59.0. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
}) } else if self.eat_keyword(kw::Unsafe) { self.parse_block_expr(None, lo, BlockCheckMode::Unsafe(ast::UserProvided), attrs) <del> } else if self.check_inline_const() { self.parse_const_expr(lo.to(self.token.span)) </del> <ins> } else if self.check_inline_const(0) { self.parse_const_block(lo.to(self.token.span)) </ins> } else if self.is_do_catch_block() { self.recover_do_catch(attrs) } else if self.is_try_block() {

Discussion:
As soon as I've seen the new inline_const feature, I've tried to find some use cases for it in my code, and I did find only very few of them, unfortunately, and one of the two uses cases could be reduced to this: That gives errors: So I am not sure if this is a bug report or an enhancement request.
Note that this does work in expressions ():
Support for ranges in patterns ( or ) needs to be separately, to and respectively.
Ohh I've just realized that we had this issue opened, I've fixed this in Going to adjust description of the PR accordingly so it closes this issue when merged.
Change:
} /* <ins> Function: from_cstr_len Create a Rust string from a C string of the given length */ unsafe fn from_cstr_len(cstr: sbuf, len: uint) -> str { let res = []; let start = cstr; let curr = start; let i = 0u; while i < len { vec::push(res, *curr); i += 1u; curr = ptr::offset(start, i); } ret from_bytes(res); } /* </ins> Function: concat Concatenate a vector of strings

Discussion:
We have a function str::fromcstr but it assumes that C string is null-terminated. The only way I see to build a string from a non-null-terminated buffer is using str::frombytes(vec::from_buf()) which requires an extra copy of the string.
Change:
let a = &Plus(@Minus(@Val(3u), @Val(10u)), @Plus(@Val(22u), @Val(5u))); test_ebml(a); <del> //    let a = &Spanned {lo: 0u, hi: 5u, node: 22u}; //    test_ebml(a); </del> <ins> let a = &Spanned {lo: 0u, hi: 5u, node: 22u}; test_ebml(a); </ins> <del> //    let a = &Point {x: 3u, y: 5u}; //    test_ebml(a); // //    let a = &@[1u, 2u, 3u]; //    test_ebml(a); // //    let a = &Top(22u); //    test_ebml(a); // //    let a = &Bottom(222u); //    test_ebml(a); // //    let a = &A; //    test_ebml(a); // //    let a = &B; //    test_ebml(a); </del> <ins> let a = &Point {x: 3u, y: 5u}; test_ebml(a); let a = &@[1u, 2u, 3u]; test_ebml(a); let a = &Top(22u); test_ebml(a); let a = &Bottom(222u); test_ebml(a); let a = &A; test_ebml(a); let a = &B; test_ebml(a); </ins> <del> println("Hi1"); </del> let a = &time::now(); test_ebml(a); <del> println("Hi2"); //    test_ebml(&1.0f32); //    test_ebml(&1.0f64); test_ebml(&1.0f); //    println("Hi3"); //    test_ebml(&'a'); </del> <ins> test_ebml(&1.0f32); test_ebml(&1.0f64); test_ebml(&'a'); </ins> <del> println("Hi4"); </del> let mut a = HashMap::new(); test_ebml(&a); a.insert(1, 2); <del> println("Hi4"); </del> test_ebml(&a); <del> //    let mut a = HashSet::new(); //    test_ebml(&a); //    a.insert(1); //    test_ebml(&a); </del> <ins> let mut a = HashSet::new(); test_ebml(&a); a.insert(1); test_ebml(&a); </ins> }

Discussion:
The bots are currently failing like so I bisected to , which changes how works.
Closing since I'm almost certain that test is either gone, or passes.
This continues to be a source of breakage on incoming. Right now the failure is in rpass/auto-encode
run-pass/auto-encode is xfailed now
my branch contains a reduced test case under run-pass/issue-6122
incoming has been poofed, so I'm not sure what the status of this is. Bors has been churning away and the tree is green, so does the problem still arise?
The test passes locally for me with some updating. Pushed it to try, will see how it falls.
Change:
<ins> error: expected expression, found keyword `mut` --> $DIR/issue-103529.rs:5:6 | LL | m! { mut x } |      ^^^ expected expression error: expected a statement --> $DIR/issue-103529.rs:5:10 | LL |     ($s:stmt) => {} |      ------- while parsing argument for this `stmt` macro fragment ... LL | m! { mut x } |          ^ error: invalid variable declaration --> $DIR/issue-103529.rs:8:6 | LL | m! { auto x } |      ^^^^ | help: write `let` instead of `auto` to introduce a new variable | LL | m! { let x } |      ~~~ error: invalid variable declaration --> $DIR/issue-103529.rs:10:6 | LL | m! { var x } |      ^^^ | help: write `let` instead of `var` to introduce a new variable | LL | m! { let x } |      ~~~ error: aborting due to 4 previous errors </ins>

Discussion:
<!-- 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</strong</summary<p</p</details label A-parser A-macros <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
cc this should probably be gated with your "may eagerly recover" work as well
This code is actually already mentioned in ;)
claim
Yeah, gating this recovery behind a is the correct fix here.
Also very fun that these things can ICE sometimes.
Found these also panic: Since these are highly related to the case, one pull request can fix all of these (maybe).
Change:
} } <del> fn add_constraints_from_trait_ref( &mut self, current: &CurrentItem, trait_ref: ty::TraitRef<'tcx>, variance: VarianceTermPtr<'a>, ) { debug!("add_constraints_from_trait_ref: trait_ref={:?} variance={:?}", trait_ref, variance); self.add_constraints_from_invariant_substs(current, trait_ref.substs, variance); } </del> <ins> #[instrument(skip(self, current))] </ins> fn add_constraints_from_invariant_substs( &mut self, current: &CurrentItem, substs: SubstsRef<'tcx>, variance: VarianceTermPtr<'a>, ) { <del> debug!( "add_constraints_from_invariant_substs: substs={:?} variance={:?}", substs, variance ); </del> // Trait are always invariant so we can take advantage of that. let variance_i = self.invariant(variance);

Discussion:
This is a follow up on , which now works. The following doesn't (): Error is: however, this lifetime clearly is used and is required.
The variance code in is: It seems to me that this is disregarding the substitutions for if I'm understanding what does here wrt. the substitutions (this pretty poorly documented right now). cc
BTW how long do we need to keep this warning around? I understand that this is basically a given when using nightly features. (It puts me off using it in my normal build path — but presumably that's exactly what is wanted, in order to detect bugs like the one reported here.)
We only use for those that have been ICE-prone in the past or are generally not in a "considered implemented modulo bugs" state. It's quite a small set of features that are incomplete like this. GATs specifically are to my knowledge nowhere near ready to be "implemented modulo bugs".
On this topic, the following builds, but the bound fails with:
Also, the following fails: with: This bound may not make much sense (since there is another lifetime parameter), but I believe it should be valid to specify here.
I'm running into a similar issue which I believe is the same as this:
Change:
func(&mut iter) } <del> fn func<T: Iterator<Item = u8>>(iter: &mut T) { </del> <ins> fn func<T: Iterator<Item = u8>>(iter: &mut T) { //~ WARN function cannot return without recursing </ins> func(&mut iter.map(|x| x + 1)) }

Discussion:
<!-- 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 which causes a stack overflow due to a recursive call of I mistakenly . I expected to see the warning. However, the compiler didn't complain it. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.43.0 showed the warning. (ref. ) The warning isn't shown on 1.44.0 or later, including the current stable 1.47.0. <!-- Provide the version you are using that has the regression. --<!-- Did the compiler crash? If so, please provide a backtrace. --<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
I think this was caused by , but it looks like expected behavior: If diverges, the self-recursion never happens.
Though maybe the lint should assume that functions returning an inhabited type won't diverge (since otherwise they should be marked ). I can definitely see why people would write code like this, so linting on it makes sense.
I personally feel that we should lint for functions if they don't return an uninhabited type. Even if someone wants to exit recursion by unwinding I do feel that a lint is still appropriate here as it is really bad style imo.
Thanks for the quick response. Yeah, it'd be natural to expect a function whose return type is not to return eventually. Probably, we might want to have the following rules?: for self-recursion unless a function returning an uninhabited type is called in advance. a non-diverge function is called before a self-recursion, show a message like "if this diverges, please annotate it." in addition to the warning. 1 would help my case and 2 would help the case of . (2 is not necessary, though.)
Assigning as and removing .