jiebi/CodeConvo huggingface dataset:
Change:
struct_span_err!( self.tcx.sess, span, E0133, "{} requires unsafe function or block", description) <del> .span_label(span, &format!("unsafe call requires unsafe function or block")) </del> <ins> .span_label(span, &description) </ins> .emit(); } UnsafeBlock(block_id) => {

Discussion:
Label message always mention "unsafe call", even when nothing is actually called. It should duplicate the main message instead, or use some paraphrase of it. cc
How about this :
I've made a , please check the error messages again :)
Fix in , should be closed.
Change:
} array_impl_default!{32, T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T} <del> macro_rules! array_impl_clone { {$n:expr, $i:expr, $($idx:expr,)*} => { #[stable(feature = "rust1", since = "1.0.0")] impl<T: Clone> Clone for [T; $n] { fn clone(&self) -> [T; $n] { [self[$i-$i].clone(), $(self[$i-$idx].clone()),*] } } array_impl_clone!{$i, $($idx,)*} }; {$n:expr,} => { #[stable(feature = "rust1", since = "1.0.0")] impl<T: Clone> Clone for [T; 0] { fn clone(&self) -> [T; 0] { [] } } }; } array_impl_clone! { 32, 31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9,  8,  7,  6,  5,  4,  3,  2,  1,  0, } </del>

Discussion:
broke this code:
Clone is not implemented for anymore, because it now requires (previously ), which doesn't hold for arrays bigger than 32.
I'm assuming that trying to call on an would previously ICE the compiler?
In certain contexts, such as it would / will ICE yes, issue
Ah, the bound was before.
If only we had type level integers so we could just properly implement Clone for all fixed size array sizes without massive bloat.
It doesn't even requires actual numbers, most of impls act on "size-erased" arrays. Something like would be enough.
how would that work? Don't you need to loop N times to do the actual clone?
Something like: So is not used explicitly in the implementation, although it is still needed by internally. Whether it is easier to implement than type level integers or not is a separate question.
Change:
#[inline(always)] fn raw_waker<W: Wake + Send + Sync + 'static>(waker: Arc<W>) -> RawWaker { // Increment the reference count of the arc to clone it. <ins> // // The #[inline(always)] is to ensure that raw_waker and clone_waker are // always generated in the same code generation unit as one another, and // therefore that the structurally identical const-promoted RawWakerVTable // within both functions is deduplicated at LLVM IR code generation time. // This allows optimizing Waker::will_wake to a single pointer comparison of // the vtable pointers, rather than comparing all four function pointers // within the vtables. #[inline(always)] </ins> unsafe fn clone_waker<W: Wake + Send + Sync + 'static>(waker: *const ()) -> RawWaker { unsafe { Arc::increment_strong_count(waker as *const W) }; RawWaker::new(

Discussion:
I would expect this to run to completion: On stable, it does: But not on current nightly: Interestingly, it works ok without cargo: The cargo project isn't special though: OS: macOS 13.6.3
cc I guess?
The internal function uses const promotion for the vtable in two places, once at initial construction and another when cloning. Maybe that results in two differently-addressed vtables.
I gave this a shot in . But without a language feature for statics with type parameters, we are not seeing a reliable way to restore 's functionality. Let's consider reverting . Having be a handful of CPU instructions faster but way more often wrong is not useful.
Change:
} } } <del> PatKind::Lit(_) => { // If the PatKind is a Lit then we want </del> <ins> PatKind::Lit(_) | PatKind::Range(..) => { // If the PatKind is a Lit or a Range then we want </ins> // to borrow discr. needs_to_be_read = true; } <del> _ => {} </del> <ins> PatKind::Or(_) | PatKind::Box(_) | PatKind::Slice(..) | PatKind::Ref(..) | PatKind::Wild => { // If the PatKind is Or, Box, Slice or Ref, the decision is made later // as these patterns contains subpatterns // If the PatKind is Wild, the decision is made based on the other patterns being // examined } </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. --Regarding a minimal example I am afraid I'm not quite able to provide one, this bug occured when i was migrating to Rust 2021 as part of the testing efforts. The branch/PR with the Rust 2021 modifications can be found here I did cfgment all modules except the ones that are required to trigger the bug out: And removed most code and modules from the rcc module: , nailing the bug down to (as the error message suggested). Then i minized further in (its 200 lines now, the rest is just tests) And I was in fact able to pin point the panic to this piece of code: , if I comment it out the ICE doesn't occur anymore so I would guess that this is what the compiler is having issues 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. --: Compilation command I used was: <!-- 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 --
Thanks for the report! Here's a somewhat minimized reproduction:
cc
claim
Change:
} /// Fills a `CrateCheckConfig` with well-known configuration values. <del> fn fill_well_known_values(&mut self) { </del> <ins> fn fill_well_known_values(&mut self, current_target: &Target) { </ins> if !self.well_known_values { return; }

Discussion:
doesn't seem to know that custom targets can extend the set of values. The following creates a custom spec with a . No warning Got the warning: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
#[cfg(not(test))] use cmp::{Eq, Ord, Equiv, TotalEq}; /* <ins> Section: Conditions */ condition! { not_utf8: (~str) -> ~str; } /* </ins> Section: Creating a string */

Discussion:
It seems to me that returning a Result would be more appropriate than failing.
See discussion on -- the right thing to do here would be to use conditions, I think.
This should be pretty simple -- working on it.
Fixed pending
fixes.
Change:
<del> Subproject commit cf633d0e897c065381b7b7d14984830176caf8b2 </del> <ins> Subproject commit 1edd231065c8eb75abf42bb375adda2120c9a6bf </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.
Is the failure at issue?
No, that builder is in the auto-fallible section. The problem is here: We probably want to put a on the llvmasm in blackbox. I presume that's fine for miri? We don't want some sort of "black box intrinsic" I think since there's nothing for miri to really do
Okay, thanks. (For future reference, where did you see that log? All the other CI tests that I can see passed.)
Issues like this one are "toolstate" issues; they're autofiled when tools break in the tools builders. That breakage, however, does not actually fail the builder, instead it just files this issue. This is because miri (and the other tools using this system) are out-of-tree, managed via submodules, and we don't want to be updating the submodules in more than one PR at a time generally speaking (that just causes pain for everyone involved).
Got it, thanks.
There is no way Miri can support inline assembly, so yeah, a sounds about right. I will submit a PR. I hope that black_box was not for soundness reasons; see for a discussion on why that does not work.
If by that you mean "to avoid UB", then no it certainly wasn't. TCO of the frame is sound, one just gets a full rather than short backtrace.
Yes that looks like a valid use of black_box, good. :)
Change:
<ins> // compile-flags: -Zsave-analysis </ins> // check-pass #![feature(type_alias_impl_trait)]

Discussion:
When running in the subdirectory, a call to with causes the following ICE: I'm not exactly sure what additional information to provide? I filed an issue with , and was forwarded here since it is an ICE.
I've minimized it a bit: It still uses external crates but the example itself is very small.
compile it with: Although is behind a feature gate it will ICE without the feature gate! modify labels: F-typealiasimpltrait ICE code:
Change:
<ins> error: expected `{`, found `=>` --> $DIR/eq-gt-to-gt-eq.rs:8:10 | LL |     if a => b {} |          ^^ expected `{` | note: the `if` expression is missing a block after this condition --> $DIR/eq-gt-to-gt-eq.rs:8:8 | LL |     if a => b {} |        ^ help: you might have meant to write a "greater than or equal to" comparison | LL |     if a >= b {} |          ~~ error: expected `{`, found `=>` --> $DIR/eq-gt-to-gt-eq.rs:13:10 | LL |     if a => 1 {} |          ^^ expected `{` | note: the `if` expression is missing a block after this condition --> $DIR/eq-gt-to-gt-eq.rs:13:8 | LL |     if a => 1 {} |        ^ help: you might have meant to write a "greater than or equal to" comparison | LL |     if a >= 1 {} |          ~~ error: expected `{`, found `=>` --> $DIR/eq-gt-to-gt-eq.rs:18:10 | LL |     if 1 => a {} |          ^^ expected `{` | note: the `if` expression is missing a block after this condition --> $DIR/eq-gt-to-gt-eq.rs:18:8 | LL |     if 1 => a {} |        ^ help: you might have meant to write a "greater than or equal to" comparison | LL |     if 1 >= a {} |          ~~ error: expected `{`, found `=>` --> $DIR/eq-gt-to-gt-eq.rs:24:10 | LL |     if a => b && a != b {} |          ^^ expected `{` | note: the `if` expression is missing a block after this condition --> $DIR/eq-gt-to-gt-eq.rs:24:8 | LL |     if a => b && a != b {} |        ^ help: you might have meant to write a "greater than or equal to" comparison | LL |     if a >= b && a != b {} |          ~~ error: expected `{`, found `=>` --> $DIR/eq-gt-to-gt-eq.rs:30:20 | LL |     if a != b && a => b {} |                    ^^ expected `{` | note: the `if` expression is missing a block after this condition --> $DIR/eq-gt-to-gt-eq.rs:30:8 | LL |     if a != b && a => b {} |        ^^^^^^^^^^^ help: you might have meant to write a "greater than or equal to" comparison | LL |     if a != b && a >= b {} |                    ~~ error: expected one of `!`, `.`, `::`, `;`, `?`, `else`, `{`, or an operator, found `=>` --> $DIR/eq-gt-to-gt-eq.rs:36:15 | LL |     let _ = a => b; |               ^^ expected one of 8 possible tokens | help: you might have meant to write a "greater than or equal to" comparison | LL |     let _ = a >= b; |               ~~ error: expected one of `!`, `.`, `::`, `?`, `{`, or an operator, found `=>` --> $DIR/eq-gt-to-gt-eq.rs:42:13 | LL |     match a => b { |     -----   ^^ expected one of `!`, `.`, `::`, `?`, `{`, or an operator |     | |     while parsing this `match` expression | help: you might have meant to write a "greater than or equal to" comparison | LL |     match a >= b { |             ~~ error: aborting due to 7 previous errors </ins>

Discussion:
When encountering code like , we currently emit But it should be closer to <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hi! I'd like to try working on this issue if nobody else is currently. claim
Change:
} /// Inserts or updates an environment variable mapping. <ins> /// /// Note that environment variable names are case-insensitive (but case-preserving) on Windows, /// and case-sensitive on all other platforms. </ins> pub fn env<'a, T: ToCStr, U: ToCStr>(&'a mut self, key: T, val: U) -> &'a mut Command { <del> self.get_env_map().insert(key.to_c_str(), val.to_c_str()); </del> <ins> self.get_env_map().insert(EnvKey(key.to_c_str()), val.to_c_str()); </ins> self } /// Removes an environment variable mapping. pub fn env_remove<'a, T: ToCStr>(&'a mut self, key: T) -> &'a mut Command { <del> self.get_env_map().remove(&key.to_c_str()); </del> <ins> self.get_env_map().remove(&EnvKey(key.to_c_str())); </ins> self }

Discussion:
The following program demonstrates the problem: When compiled and executed on WIndows, it randomly displays either 'foo' or 'BAR'. This happens because process::Command represents environment block as a HasMap<CString, CString, so it treats "foo" and "FOO" as different variables, whereas Windows considers them to be the same one. When child process is spawned, both get into the environment block, however Windows keeps only the last one.
Change:
// std testing crates, okay for now at least "src/libcore/tests", "src/liballoc/tests/lib.rs", <ins> "src/liballoc/benches/lib.rs", </ins> // The `VaList` implementation must have platform specific code. // The Windows implementation of a `va_list` is always a character // pointer regardless of the target architecture. As a result,

Discussion:
Recently enabled benchmarks () frequently fail on arm-android builder on GitHub Actions: The issue looks similar to previously reported .
I'm sorry, I noticed this during my local testing, but figured it was due to my hardware which had a very high parallel count, and it seemed to go away when I lowered the parallel test threads. I also had great difficulty running these tests at -j32 on android as well: They either seemed to hang, or took a very long time to finish. Would people prefer to just disable the bench tests on android, or should we do more investigation?
Again? cc
Looks like didn't fix the "died due to signal 11" errors either :(
hm, yeah if these keep coming back I guess that's reason enough for me to allocate time for it again.
will open a PR disabling collectionsbench on Android for the time being.
Change:
<del> print-vtable-sizes { "crate_name": "<UNKNOWN_CRATE>", "trait_name": "D", "entries": "7", "entries_ignoring_upcasting": "4", "entries_for_upcasting": "3", "upcasting_cost_percent": "75" } </del> print-vtable-sizes { "crate_name": "<UNKNOWN_CRATE>", "trait_name": "E", "entries": "6", "entries_ignoring_upcasting": "4", "entries_for_upcasting": "2", "upcasting_cost_percent": "50" } print-vtable-sizes { "crate_name": "<UNKNOWN_CRATE>", "trait_name": "G", "entries": "14", "entries_ignoring_upcasting": "11", "entries_for_upcasting": "3", "upcasting_cost_percent": "27.27272727272727" } print-vtable-sizes { "crate_name": "<UNKNOWN_CRATE>", "trait_name": "A", "entries": "6", "entries_ignoring_upcasting": "5", "entries_for_upcasting": "1", "upcasting_cost_percent": "20" } print-vtable-sizes { "crate_name": "<UNKNOWN_CRATE>", "trait_name": "B", "entries": "4", "entries_ignoring_upcasting": "4", "entries_for_upcasting": "0", "upcasting_cost_percent": "0" } <ins> print-vtable-sizes { "crate_name": "<UNKNOWN_CRATE>", "trait_name": "D", "entries": "4", "entries_ignoring_upcasting": "4", "entries_for_upcasting": "0", "upcasting_cost_percent": "0" } </ins> print-vtable-sizes { "crate_name": "<UNKNOWN_CRATE>", "trait_name": "F", "entries": "6", "entries_ignoring_upcasting": "6", "entries_for_upcasting": "0", "upcasting_cost_percent": "0" } print-vtable-sizes { "crate_name": "<UNKNOWN_CRATE>", "trait_name": "_::S", "entries": "3", "entries_ignoring_upcasting": "3", "entries_for_upcasting": "0", "upcasting_cost_percent": "0" } print-vtable-sizes { "crate_name": "<UNKNOWN_CRATE>", "trait_name": "_::S", "entries": "3", "entries_ignoring_upcasting": "3", "entries_for_upcasting": "0", "upcasting_cost_percent": "0" }

Discussion:
While working on I think I found a bug. Given this program: rustc outputs the following vtable layout: Which is surprising, because is unnecessary — does not have any methods, so vtable can be inlined... I think we should be smarter here: (for the record, I'm pretty sure this happens in practice, I've found this with ) Originally posted by in
cc
sorry been slow a little recently... This is a nice improvement.
Change:
<ins> // Copyright 2015 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. struct S; trait InOut<T> { type Out; } fn do_fold<B, F: InOut<B, Out=B>>(init: B, f: F) {} fn bot<T>() -> T { loop {} } fn main() { do_fold(bot(), ()); //~ ERROR is not implemented for the type `()` } </ins>

Discussion:
Hello folks, I'm dutifully reporting this as the compiler told me to so. The bug is the same reported already by and , although it appeared on a different circumstance. I have this simple program (I'm a Rust newbie so It's very likely I'm doing things terribly wrong): Expected outcome: The compile to tell me how wrong I am Actual outcome: Meta Shows up with latest beta as well:
cc me
Minified: We do write tyerr to node 11 (). Apparently we somehow don't report an error.
triage: P-medium
Whoops. There is indeed an error, which is indeed gets to reportselectionerror, but when we do (), we get an error, and think this one was a duplicate.
no_std version:
You don't even need the trait:
Change:
post.dedup(); if self.is_tainted_by_errors() <del> && crate_names.len() == 1 && ["`core`", "`alloc`", "`std`"].contains(&crate_names[0].as_str()) && spans.len() == 0 </del> <ins> && (crate_names.len() == 1 && spans.len() == 0 && ["`core`", "`alloc`", "`std`"].contains(&crate_names[0].as_str()) || predicate.visit_with(&mut HasNumericInferVisitor).is_break()) </ins> { // Avoid complaining about other inference issues for expressions like // `42 >> 1`, where the types are still `{integer}`, but we want to

Discussion:
When I run this code (via ): I get the output I expected (i.e., a single line of output that says "My number is 42"). However, if I run this code (via the same with no other changes): I get two compiler errors. The first error indicates that is not in scope - this makes sense, I have not defined anywhere. However, the second error indicates (provided below) does not make sense: It appears that, when there are no other compiler issues, the compiler can infer a type for just fine. However, as soon as any other compiler issue appears, it loses the ability to infer type. That doesn't make sense to me - the ability to infer type should be unrelated to any other compiler errors present. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I partially fixed this for and in , but not in general. I am dissatisfied with this error message. I'll look into fixing it. claim
Change:
}; let base_ty = self.place_ty(&proj.base); match proj.elem { <del> Field(field, _) => Ok(self.read_field(base, None, field, base_ty)?.map(|(f, _)| f)), </del> <ins> Field(field, _) => Ok(Some(self.read_field(base, None, field, base_ty)?.value)), </ins> // The NullablePointer cases should work fine, need to take care for normal enums Downcast(..) | Subslice { .. } |

Discussion:
I saw that was closed when was merged so I thought it would fix the same error on my own code as well however as of nightly: it still happens. Code: Playground: From what I can tell its an alignment issue because changing id from a to a fixes the issue.
Change:
<ins> error[E0412]: cannot find type `MissingType` in this scope --> $DIR/erroneous_signature.rs:2:22 | LL |     fn err(&self) -> MissingType; |                      ^^^^^^^^^^^ not found in this scope error[E0412]: cannot find type `MissingType` in this scope --> $DIR/erroneous_signature.rs:7:22 | LL |     fn err(&self) -> MissingType { |                      ^^^^^^^^^^^ not found in this scope error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0412`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: async fn coroutine return type not an inference variable: impl Future<Output = &'b ()', 'error: internal compiler error: async fn coroutine return type not an inference variable: impl Future<Output = &'b ()' 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: [typeck] type-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in module [analysis] running analysis passes on this crate --
Also ices in Rust 2021 in case anybody was wondering. Further reduced:
(see below)
It's of course :upsidedownface:
fyi
Change:
# struct Point { x: f64, y: f64 } # enum Shape { Rectangle(Point, Point) } # impl Shape { fn area(&self) -> int { 0 } } <del> let start = @Point { x: 10.0, y: 20.0 }; </del> <ins> let start = ~Point { x: 10.0, y: 20.0 }; </ins> let end = ~Point { x: (*start).x + 100.0, y: (*start).y + 100.0 }; let rect = &Rectangle(*start, *end); let area = (*rect).area();

Discussion:
Their continued existence in the tutorial is causing confusion over what the status of this feature is. Let all the world know that managed pointers are relegated to the dustbin of history!
It's unclear to me if the tutorial is being rewritten from scratch by Mozilla. There's not much motivation for anyone to work on it if it's just going to be thrown out.
That may be true, but if a good samaritan wanted to do just enough work to delete mentions of them from the current tutorial, it would not be unappreciated.
Hi, I am the one who asked about this initially. I have started to work on it now.
At this point I do think it's worthwhile to keep maintaining the tutorial. Even if it doesn't survive as the tutorial, it does contain a lot of information that will end up disseminated elsewhere.
Not maintaining the tutorial leads to a growing collection of inaccurate or wrong information. Removing it could give newcomers a better first-time experience of Rust.
Change:
} #[stable(feature = "manually_drop", since = "1.20.0")] <del> impl<T> Deref for ManuallyDrop<T> { </del> <ins> impl<T: ?Sized> Deref for ManuallyDrop<T> { </ins> type Target = T; #[inline] fn deref(&self) -> &Self::Target {

Discussion:
currently requires . It would be nice if we could remove this restriction. I'm not sure how to do it with the current implementation using though.
Doesn't seem possible until we get by-value DSTs
care to explain why?
Ah, nevermind. It would just need to make unsized, too.
The and methods can keep could keep their bounds, we just need to relax the bound on the struct itself, and make sure . Then the following code would be possible:
I guess this would be possible by allowing types to be when there is only one variant. I was worried that would be unsound, but then I realized, the only way to create a DST type would be from an unsize coercion, and then way you know what the erased type is and can get the vtable/slice length then, just like any other unsize coercion.
See