jiebi/CodeConvo huggingface dataset:
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // run-rustfix </del> #![allow(dead_code)] fn missing_discourses() -> Result<isize, ()> {

Discussion:
Reproduced on versions: - Isolated example to reproduce: Actual error: Mentioned suggestion about "wrap into " is incorrect at all. There we should deref the value from the . - - Expected error: (something like this)
Here's where the suggestion gets issued: The motivation was to solve (where a -expression appears in tail position, which seemed likely to be a common mistake), but it turns out that there are other situations where we run into a type mismatch between match arms of a desugared expression. We regret the error.
Here's another case of this:
I see what's happening, we're only checking wether the error came from a desugaring, disregarding the types involved. It should be possible to check that information as well, even if the suggestion is only provided when it's a where everything but the error type matches. (I think it's ok if the supplied error cannot be converted to the expected error, as this suggestion exposes newcomers to a non-obvious construct at least.)
Clippy to detect this that we might want to uplift ...
(But for now I'm just going to remove the suggestion.)
Change:
target_region, referent_region); <del> check_object_safety(fcx.tcx(), object_trait, source_expr.span); </del> <ins> check_object_safety(fcx.tcx(), &object_trait.principal, source_expr.span); </ins> } }

Discussion:
The following code either aborts or segfaults for me, depending on if I'm in gdb or not, on Linux: With optimizations, becomes Which means we're doing something very bad when translating this code.
Still reducing...
FWIW, I can confirm that behaviour on Windows.
cc me
Reduced: And that makes it clear the issue is not broken codegen, but rather that is mistakenly treated as object-safe (while it inherits from the non-object-safe ).
nice. cc
P-backcompat-lang, 1.0.
Hint: iterate with
takes/creates s but needs a . I'm not sure how to make these agree.
checkobjectsafety should use to enumerate the trait_ref, I think. Annoyingly this does require a right now (harder to fix than you might think).
On I get , which is an unwrap in in the supertraits iterator.
Change:
<ins> // @has issue_108925/enum.MyThing.html // @has - '//code' 'Shown' // @!has - '//code' 'NotShown' // @!has - '//code' '// some variants omitted' #[non_exhaustive] pub enum MyThing { Shown, #[doc(hidden)] NotShown, } </ins>

Discussion:
<table<tr<thcode</th<thrustdoc</th</tr<tr<td</td<td<img src="https://user-" width="400"</td</tr<tr<td</td<td<img src="https://user-" width="400"</td</tr<tr<td</td<td<img src="https://user-" width="400"</td</tr</tableWould it be reasonable for Rustdoc to produce exactly the same output for and ? I think so. These two types have an identical public API. Separately, would it be reasonable for Rustdoc to produce exactly the same output for and ? Whether that means printing a synthetic attribute on instead of the comment, or some other approach that unifies all three of these outputs. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
IMHO, for both is more clear. It better conveys meaning. I'm happy to work on this but I've never touched rustdoc before so I might need some help. claim EDIT: is it acceptable to literally a new attribute onto ?
I think it's important that the docs not disagree with behavior users can observe from the compiler. So we shouldn't document a attribute when none exists because a user could write an exhaustive match and not get a compile error (even though they might have had to look at the source to do so). I think it would be reasonable for Enum2 and Enum3 to render as Enum2 is today: <img width=300 src="https://user-"For Enum1, I think there should be a doc lint warning if there is a variant without the enum being marked .
I agree, a doc lint sounds like the best idea because semantically is even if not technically so. I see that you are the reviewer on the linked PR, I've marked it as a draft for now and will re-implement with your suggestion. I assume that broadly agrees from the OP?
Change:
discr: &Expr<'_>, discr_place: PlaceWithHirId<'tcx>, pats: impl Iterator<Item = &'t hir::Pat<'t>>, <del> ) { </del> <ins> ) -> Result<(), ()> { </ins> // Matching should not always be considered a use of the place, hence // discr does not necessarily need to be borrowed. // We only want to borrow discr if the pattern contain something other

Discussion:
<details</summary</details<!-- 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 will try to reduce this to an MCVE.
Changing to appears to avoid the ICE, so that may be a useful place to focus.
Minimized it down to 60 lines without any dependencies. Maybe it can be minimized further but it's getting really hard. I've also left a few comments to say what's going on. <details<summary"Minimized" </summary</details
This appears to have regressed in Rust 1.64
This continues to ICE on beta and nightly
I bisected the regression, here is the output of : searched nightlies: from nightly-2022-06-24 to nightly-2022-08-05 regressed nightly: nightly-2022-07-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
Out of these seems the most likely, cc
Zooming onto changeset.
Found MVCE: <details<summaryOutput from Rust Playground</summary</details
Change:
// run-pass <del> #![feature(saturating_neg)] </del> #![feature(const_checked_int_methods)] #![feature(const_euclidean_int_methods)] #![feature(const_overflowing_int_methods)]

Discussion:
It would be great to have and functions for signed integer types. The current work-around is using a pattern like but having explicit functions would lift the corner-case knowledge "burden" from the user.
What do you expect them to return? Just for the two values that can't be expressed? IMHO you should prefer the instead and explicitly handle that.
The and functions both have a corner case when the negative minimum value is used (e.g. -128 for type i8). The result cannot be represented within the bounds of the output type. The / variants shall return a best-effort value (like 127 in case of -128 i8 input), similar to the existing functions. asserteq!(127i8.saturatingabs(), 127); asserteq!(-127i8.saturatingabs(), 127); asserteq!(-128i8.saturatingabs(), 127); asserteq!(127i8.saturatingneg(), -127); asserteq!(-127i8.saturatingneg(), 127); asserteq!(-128i8.saturating_neg(), 127);
These seems reasonable. I'd suggest just making a PR with them unstable and seeing what libs says. By using they'll automatically get the new saturating implementation, too, which should be better for optimization and codegen than the approach.
Haven't done a PR for Rust yet so will take a look at the contribution guidelines and try to get along.
What's holding up stabilization on this? It seems relatively simple.
In my opinion there is nothing specific holding this up from being stabilized. Initially I wanted to give it some time for others to comment, then forgot about. Added a PR for stabilization now.
Change:
// for simple cases like `fn foo(x: Trait)`, // where we would error once on the parameter as a whole, and once on the binding `x`. if param.pat.simple_ident().is_none() && !params_can_be_unsized { <del> fcx.require_type_is_sized(param_ty, param.pat.span, traits::SizedArgumentType(ty_span)); </del> <ins> fcx.require_type_is_sized( param_ty, param.pat.span, // ty_span == binding_span iff this is a closure parameter with no type ascription, // or if it's an implicit `self` parameter traits::SizedArgumentType( if ty_span == Some(param.span) && tcx.is_closure(fn_def_id.into()) { None } else { ty_span }, ), ); </ins> } fcx.write_ty(param.hir_id, param_ty);

Discussion:
Notice how the last 2 suggestions aren't valid in such a closure: The suggestions given in should help me get closer to fixing the error, or at least not have invalid syntax. No response No response Output of :
(if is used in the snippet, comes up again with leaking implementation details)
Change:
submit_post_lto_module_to_llvm, submit_pre_lto_module_to_llvm, ComputedLtoType, OngoingCodegen, }; use crate::common::{self, IntPredicate, RealPredicate, TypeKind}; <ins> use crate::meth::load_vtable; </ins> use crate::mir::operand::OperandValue; use crate::mir::place::PlaceRef; use crate::traits::*;

Discussion:
<!-- [31mICE[0m: Rustc ./subtyping-impacts-selection-2.rs '-Zvirtual-function-elimination=true -Clto=true -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'expected principal trait object'', 'thread 'rustc' panicked at 'expected principal trait object'' File: /tmp/im/subtyping-impacts-selection-2.rs --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: --
Seems to be a duplicate of
Regression in nightly-2022-06-16 commit[0] 2022-06-14: Auto merge of - b-naber:transition-to-valtrees-in-type-system, r=lcnr commit[1] 2022-06-14: Auto merge of - flip1995:pk-vfe, r=nagisa commit[2] 2022-06-15: Auto merge of - compiler-errors:if-cond-and-block, r=oli-obk commit[3] 2022-06-15: Auto merge of - JohnTitor:rollup-rfg1a4s, r=JohnTitor commit[4] 2022-06-15: Auto merge of - nnethercote:rm-thread-local-IGNORED_ATTRIBUTES, r=michaelwoerister commit[5] 2022-06-15: Auto merge of - JohnTitor:rollup-c17vjdy, r=JohnTitor commit[6] 2022-06-15: Auto merge of - AzureMarker:feature/horizon-std, r=nagisa commit[7] 2022-06-15: Auto merge of - c410-f3r:assert-compiler, r=oli-obk commit[8] 2022-06-15: Auto merge of - sunfishcode:ownedfd-and-dup, r=joshtriplett looks like this has been broken eversince

This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:
Change:
/// Used to detect possible `if let` written without `let` and to provide structured suggestion. in_if_condition: Option<&'ast Expr>, <ins> /// Used to detect possible new binding written without `let` and to provide structured suggestion. in_assignment: Option<&'ast Expr>, </ins> /// If we are currently in a trait object definition. Used to point at the bounds when /// encountering a struct or enum. current_trait_object: Option<&'ast [ast::GenericBound]>,

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:
param_env, projection, )); <del> if ocx.select_where_possible().is_empty() { // `ty_var` now holds the type that `Item` is for `ExprTy`. let ty_var = self.resolve_vars_if_possible(ty_var); assocs_in_this_method.push(Some((span, (proj.def_id, ty_var)))); </del> <ins> if ocx.select_where_possible().is_empty() && let ty = self.resolve_vars_if_possible(ty) && !ty.is_ty_var() { assocs_in_this_method.push(Some((span, (proj.def_id, ty)))); </ins> } else { // `<ExprTy as Iterator>` didn't select, so likely we've // reached the end of the iterator chain, like the originating <del> // `Vec<_>`. </del> <ins> // `Vec<_>` or the `ty` couldn't be determined. </ins> // Keep the space consistent for later zipping. assocs_in_this_method.push(None); }

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. --issue appeared when going from 1 -2, was able to fix it by adding 3 <!-- 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
I've only skimmed the code but this is very likely due to the diagnostic method constructing a projection, more precisely an , with created for the trait item, not the associated type (with (pseudo) ), so we're missing the own generic arguments for the GAT.
Change:
[[package]] name = "hashbrown" <del> version = "0.14.0" </del> <ins> version = "0.14.2" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "2c6201b9ff9fd90a5a3bac2e56a830d0caa509576f0e503818ee82c181b3437a" </del> <ins> checksum = "f93e7192158dbcda357bdec5fb5788eebf8bbac027f3f33e719d29135ae84156" </ins> dependencies = [ "ahash", "allocator-api2",

Discussion:
I tried this code: I expected to see this happen: map = {1: "a"} Instead, error happened: Sometimes it causes Segmentation fault: <!-- 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<summaryBacktrace</summary<p</p</details
Miri reports UB with the target in question: (sorry for reflexively blaming LLVM, it didn't deserve that)
The root cause is that the stdarch SIMD intrinsics are broken on big-endian targets. For now I've disabled the use of NEON in hashbrown on big-endian ARM: We should probably disable/de-stabilize the NEON intrinsics on big-endian targets. They are currently all producing incorrect results.
All of them, or specifically for ARM? (Not sure if we have stdarch support for any other big-endian target.) Is there an issue tracking that and explaining in a bit more detail how they are broken?
This only applies to arm & aarch64 targets. Here is the issue in stdarch:
Miri doesn't support the NEON SIMD intrinsics though. So if Miri reports UB then it seems there are other problems as well?
Some are implemented using the same intrinsics as portable-simd.
It's a combination of a few things: We are missing a check for the NEON implementation. All the NEON intrinsics we happen to use in hashbrown are implemented without LLVM builtins.
Ah so I guess what happens is that Miri correctly implements the portable SIMD intrinsics, but stdarch implements the NEON intrinsics on top of them and it's doing that incorrectly? Miri and codegen/LLVM are fine?
Yes, that's my understanding.
Change:
LL | fn unused_parens_around_return_type() -> (u32) { |                                          ^^^^^ help: remove these parentheses <ins> error: unnecessary parentheses around block return value --> $DIR/lint-unnecessary-parens.rs:22:9 | LL |         (5) |         ^^^ help: remove these parentheses error: unnecessary parentheses around block return value --> $DIR/lint-unnecessary-parens.rs:24:5 | LL |     (5) |     ^^^ help: remove these parentheses </ins> error: unnecessary parentheses around function argument <del> --> $DIR/lint-unnecessary-parens.rs:36:9 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:43:9 </ins> | LL |     bar((true)); |         ^^^^^^ help: remove these parentheses error: unnecessary parentheses around `if` condition <del> --> $DIR/lint-unnecessary-parens.rs:38:8 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:45:8 </ins> | LL |     if (true) {} |        ^^^^^^ help: remove these parentheses error: unnecessary parentheses around `while` condition <del> --> $DIR/lint-unnecessary-parens.rs:39:11 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:46:11 </ins> | LL |     while (true) {} |           ^^^^^^ help: remove these parentheses warning: denote infinite loops with `loop { ... }` <del> --> $DIR/lint-unnecessary-parens.rs:39:5 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:46:5 </ins> | LL |     while (true) {} |     ^^^^^^^^^^^^ help: use `loop`

Discussion:
I'd be interested in handling this. Looking at , it looks fairly straightforward -- however it does look like there could be some ambiguity with return values in blocks (e.g. ) Would we want to disambiguate lints, or would it be fine to use the same lint diagnostic for both cases?
what sort of ambiguity do you mean? I'd expect a single lint on in your example (note that we about unused ).
To use your original example, Both and are , since they represent the implicit return at the end of a block. I was wondering if we'd care about the case, and if we did, if it made sense to treat it the same as . If you naively add a match arm to the visitor, you get the same diagnostic for both.
Yes, both and should be linted here.
Change:
<ins> error[E0624]: associated type `P` is private --> $DIR/assoc-inherent-private.rs:10:10 | LL |         type P = (); |         ------ associated type defined here ... LL | type U = m::T::P; |          ^^^^^^^ private associated type error[E0624]: associated type `P` is private --> $DIR/assoc-inherent-private.rs:21:10 | LL |             pub(super) type P = bool; |             ----------------- associated type defined here ... LL | type V = n::n::T::P; |          ^^^^^^^^^^ private associated type error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0624`. </ins>

Discussion:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
ConstVal::Value(Value::ByVal(PrimVal::Bytes(sz))) => { write!(f, "{}", sz)?; } <del> ConstVal::Unevaluated(_def_id, substs) => { write!(f, "<unevaluated{:?}>", &substs[..])?; </del> <ins> ConstVal::Unevaluated(_def_id, _substs) => { write!(f, "_")?; </ins> } _ => { write!(f, "{:?}", sz)?;

Discussion:
After , when a trait bound fails and the trait was implemented by fixed-size arrays, the compiler will display an error like: Which is pretty unhelpful. A solution would be to evaluate these and/or to show evaluated bounds preferably.
I can't reproduce triggering an error with these messages, do you have an example? I need it for a regression test, the fix was indeed as simple
It only appears if you explicitly disambiguate the trait, like . .
are you displaying these as ? I feel that'd be a reasonable output for this.
that would be a better fallback than , but I'm currently trying to get at the actual value (though that triggers cycle errors atm when building libcore's array impls ^^)
That's better in some ways, but kinda implies that
Change:
<ins> // build-fail //~^ overflow evaluating fn main() { let mut iter = 0u8..1; func(&mut iter) } fn func<T: Iterator<Item = u8>>(iter: &mut T) { func(&mut iter.map(|x| x + 1)) } </ins>

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: program either compiled successful or compiler generate an error Instead, this happened: rustc eats 100% CPU for several minutes, but nothing generated. I compile this code using both and before I began to write this issue, but compiler do not compile even after this issue is submitted. <!-- 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<summaryBacktrace</summary<p</p</details
Slightly smaller:
Actually, I am very curious that, why rustc do not reach the recursion limit.
Oh sorry, you're right, it does hit the recursion limit if I let it run long enough (about 10 seconds).
Here's a proper minimization:
Partial backtrace of the hang: <details</details
So it actually hangs while trying to print the overflow error :laughing:
Bisected:
looks suspicious.
hang but generate a failed massage:
Assigning and removing .
Change:
if let Some(backchain) = backchain_attr(cx) { to_add.push(backchain); } <del> to_add.extend(sanitize_attrs(cx, codegen_fn_attrs.no_sanitize)); </del> to_add.extend(patchable_function_entry_attrs(cx, codegen_fn_attrs.patchable_function_entry)); // Always annotate functions with the target-cpu they are compiled for.

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 : And compiled it with . I expected to see this happen: The compiler should generate a function which only contains the instruction. Instead, this happened: The compiler crashes with . <!-- 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. --: As requested in
This is an LLVM assertion
It was noted in that this comes from sanitizer annotations being to naked functions. Seems like we might not want to do that? Cc
Almost certainly, but is not supposed to be used in places where user input can cause it to be reached.
Reported at
To clarify, the fix that landed is just to make this an IR verification failure rather than a backend crash. The underlying issue with the kasan + naked combination still needs to be fixed.
Should we file an issue upstream to handle this in sanitizers as well, or is there one already opened?
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() { let v = &[]; //~ ERROR cannot determine a type for this local variable: unconstrained type let it = v.iter(); } </ins>

Discussion:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

(Doesn't happen with .)
Paging
Here's a truly minimal test case:
cc me
Variation: This gives a different error message:
Fixed in Can be closed.