jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Issue #66530: We would ICE if someone compiled with `-o /dev/null`, // because we would try to generate auxiliary files in `/dev/` (which // at least the OS X file system rejects). // // An attempt to `-o` into a directory we cannot write into should indeed // be an error; but not an ICE. // compile-flags: -o /dev/null // The error-pattern check occurs *before* normalization, and the error patterns // are wildly different between build environments. So this is a cop-out (and we // rely on the checking of the normalized stderr output as our actual // "verification" of the diagnostic). // error-pattern: error // On Mac OS X, we get an error like the below // normalize-stderr-test "failed to write bytecode to /dev/null.non_ice_error_on_worker_io_fail.*" -> "io error modifying /dev/" // On Linux, we get an error like the below // normalize-stderr-test "couldn't create a temp dir.*" -> "io error modifying /dev/" // ignore-tidy-linelength // ignore-windows - this is a unix-specific test // ignore-emscripten - the file-system issues do not replicate here // ignore-wasm - the file-system issues do not replicate here // ignore-arm - the file-system issues do not replicate here, at least on armhf-gnu #![crate_type="lib"] #![cfg_attr(not(feature = "std"), no_std)] pub mod task { pub mod __internal { use crate::task::Waker; } pub use core::task::Waker; } </ins>

Discussion:
Ok, so rustc outputting to /dev/null is a bit pathelogical but it used to not ICE the compiler. If you checkout and from dir tests/suite/futurescore run: rustc --crate-type lib -o /dev/null Then rustc is vexed: (ICEs on stable and nightly) The irony is that this is in the test suite of a rust code minimisation project.... Let me minimise the reproduction of the problem...
Thanks to rust-reduce I managed to get the repro down to: Interestingly it doesn't ICE on playground - I'm guessing playground is on linux?
Indeed
triage: P-medium, removing nomination tag, assigning self.
hmm. I nonetheless see an ICE on my own Linux machine. (There is probably some other reason the ICE does not replicate on the playpen.)
Change:
v.sort_by(|a, b| b.cmp(a)); assert!(v.windows(2).all(|w| w[0] >= w[1])); <ins> // Sort in lexicographic order. let mut v1 = orig.clone(); let mut v2 = orig.clone(); v1.sort_by_key(|x| x.to_string()); v2.sort_by_cached_key(|x| x.to_string()); assert!(v1.windows(2).all(|w| w[0].to_string() <= w[1].to_string())); assert!(v1 == v2); </ins> // Sort with many pre-sorted runs. let mut v = orig.clone(); v.sort();

Discussion:
Where we would normally put "^^^ did you mean Up" under mistyped names, I noticed that we don't do that for enum variants. Here's an example I just saw: !
Taking a look.
Change:
<ins> error[E0308]: mismatched types --> $DIR/type_mismatch.rs:2:11 | LL |     bar::<N>() |           ^ expected `u8`, found `usize` error[E0308]: mismatched types --> $DIR/type_mismatch.rs:5:31 | LL | fn bar<const N: u8>() -> [u8; N] {} |                               ^ expected `usize`, found `u8` error[E0308]: mismatched types --> $DIR/type_mismatch.rs:5:26 | LL | fn bar<const N: u8>() -> [u8; N] {} |    ---                   ^^^^^^^ expected array `[u8; N]`, found `()` |    | |    implicitly returns `()` as its body has no tail or `return` expression error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0308`. </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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
's parameter doesn't have to have an error type; it appears it can be any type (that doesn't trip the full feature gate error.) This version ICEs without any prior diagnostics: Neither version ICEs on beta or stable. (const generics aren't stable on 1.50, but after reporting an error for use of unstable features the compiler reports the same errors as beta and doesn't ICE.) label A-const-generics regression-from-stable-to-nightly
Bisected, this is a weird one:
I've attempted a second bisection using the snippet from the , I got a different result (not sure why, unsure if it helps) searched nightlies: from nightly-2021-02-15 to nightly-2021-03-18 regressed nightly: nightly-2021-03-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
I guess that was a lie I'm looking into this
Assigning and removing as in the prioritization working group. label: +P-high -I-prioritize
Change:
self.bclose_maybe_open(span, true) } <del> crate fn break_offset_if_not_bol(&mut self, n: usize, off: isize) { </del> <ins> crate fn break_offset_if_not_bol(&mut self, n: usize, off: isize) { </ins> if !self.s.is_beginning_of_line() { self.s.break_offset(n, off) } else {

Discussion:
I'm seeing the following error on the channel, but not on or : Found with the help of .
triage: P-medium. Leaving nominated so that team double-checks that priority assignment.
This is triggered here It should be possible to use the span snippet instead. I believe it was introduced in
Change:
// a pointer and Rust does not or vice versa. for i in 0..tys.fn_sig.inputs.len() { let rust_ty = tys.fn_sig.inputs[i]; <del> let llrust_ty = tys.llsig.llarg_tys[i]; </del> let rust_indirect = type_of::arg_is_indirect(ccx, rust_ty); <ins> let llty = rust_param_tys.next().expect("Not enough parameter types!"); let llrust_ty = if rust_indirect { llty.element_type() } else { llty }; </ins> let llforeign_arg_ty = tys.fn_ty.arg_tys[i]; let foreign_indirect = llforeign_arg_ty.is_indirect();

Discussion:
Repro: ICE:
tracks a number of cases that throw the same error.
A couple of hints - it looks like it happens when structure size is actually smaller or equal to register of architecture. I had the similar report for failing on iOS with the following sample: It fails on and if + <= 64 bits, i.e. they are u16 or u32. When switching to armv7 it fails if + <= 32 bits
after 6 hours bisecting the verdict is - , part of
sigh I actually saw that when I was working on but didn't come up with a test case that would trigger a problem here and then forgot about it. Will look into this.
will fix hit the upcoming beta?
Sorry, fixing a few regressions in LLVM that affected rust had higher priority for me than this issue (because LLVM is very close to its 3.6 release), so I couldn't devote much time to this issue yet. But given that the beta is still ~3 weeks away, I'm positive that I'll get around to have it fixed by then.
Hmm, beta is on week of Feb 16 (i.e. next week), isn't it?
Yes. Although, as someone hitting that bug, I'd be okay if that were flagged as a known bug and would prefer if semantic issues were cared about first.
I have nothing against fixing regressions, still be extremely happy to see it fixed as I will be stuck on beta1 following 6 weeks till beta2 or rc1.
:tada: thanks a lot!
Change:
Some(key.default_span(tcx)) }; let def_id = key.key_as_def_id(); <del> let def_kind = if kind == dep_graph::dep_kinds::def_kind { </del> <ins> let def_kind = if kind == dep_graph::dep_kinds::def_kind || reduce_queries { </ins> // Try to avoid infinite recursion. None } else {

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. --from Rustc will crash "normally" (expected as the bug is not fixed) but when trying to print the query stack, rustc will eat up all available memory which is BAD. <!-- 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
Its very likely hat this was caused by cc
This looks like again. It was fixed in , but the doesn't actually test what it's supposed to, because it doesn't check for the "end of query stack" line. (This also means that we currently have an UI that will fill up your entire RAM and then get killed.) The / calls are needed to fix this, not sure why they got removed.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
<ins> const F: &'static dyn PartialEq<u32> = &7u32; fn main() { let a: &dyn PartialEq<u32> = &7u32; match a { F => panic!(), //~ ERROR: `&dyn PartialEq<u32>` cannot be used in patterns } } </ins>

Discussion:
Compiled with: Using: Gives:
The problem is not tied to box:
No longer ICEs after
Ops, sorry, I reopen until a test is present.

: <details<summary<strongBacktrace</strong</summary<p</p</detailssearched nightlies: from nightly-2019-10-03 to nightly-2020-07-05 regressed nightly: nightly-2020-02-16 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
Minified, It seems possible to ICE on stable, though I'm not sure if it counts? <details<summaryStable error</summary</details
The ICE is fixed in the latest nightly, marking as .
Change:
<ins> const F: &'static dyn PartialEq<u32> = &7u32; fn main() { let a: &dyn PartialEq<u32> = &7u32; match a { F => panic!(), //~ ERROR: `&dyn PartialEq<u32>` cannot be used in patterns } } </ins>

Discussion:
This produces an ICE (): It points to this assert firing: This assert assumes that if we match on a with a const, then must be . I'm not sure where this assumption comes from (I'd guess byte-array patterns), but it's clearly wrong. Note that this also fails with any other non- type here instead of . Note that this does not fail when the arrays are not behind references, or if we use slices instead of arrays. EDIT: removed unnecessary feature gate
The feature gate isn't needed to trigger the ICE
Oh, well spotted. And it appears that fails on stable too then
cc as it's possible this is related to your structural match work I guess?
Funny enough: this doesn't ICE but instead shows the correct "unreachable" warning
Reduced:
What the heck?!?
triage: P-high. Removing nomination. Self-assigning.
That's a leftover from matching on byte strings, which used to be one of the few constants one could actually match on.
I think it's one more of theses cases where we don't know how to handle properly. shouldn't even exist: specialization should be able to specialize consts by unpacking a pattern into its subpatterns, like we specialize everything else.
I've figured out a way to eliminate the ICE, but I do not think my code has the desired semantics. That is, I would imagine we would want this to be accepted: but my current draft code rejects the above as non-exhaustive. On the other hand, that does match the current behavior of the compiler, for better or for worse. Update: Or maybe I've forgotten the desirata for how match usefulness and consts are supposed to interact...?
This was not a stable reduction; on the current nightly, the above length-zero ZST array is accepted with no ICE, while the original length-one ZST array still causes an ICE.
Yet another fun variation on the test: yields:
The reason it exists is that we don't want to unpack a multi megabyte byte string you may have gotten from . That would be super inefficient and likely just cause an out of memory abort. The reason why I believe we should also do this optimization for other types is that you can easily transmute a multi megabyte byte string to another array type in a constant, and then you have the same problem all over again.

(Or you init with a repeat expression). I agree that it would be nicer and less fragilr if we just unpacked everything.
Btw, addresses a few of the ICEs around this
Since the original and reduced versions no longer ICE, but still does
The above no longer ICEs after , could do with a test
Change:
/// Compiler documentation is distributed separately, so we make sure /// we do not merge it with the other documentation from std, test and /// proc_macros. This is largely just a wrapper around `cargo doc`. <del> fn run(self, builder: &Builder<'_>) { </del> <ins> fn run(mut self, builder: &Builder<'_>) { </ins> let stage = self.stage; let target = self.target;

Discussion:
title. I ran and nothing opened, cc (havent actually checked that PR caused this). still works <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
whoops yeah this is definitely my fault :sweatsmile: needs to be
claim
What is in this context? Looks like it wants a and "rustcdriver" doesn't seem to do the trick.
you might need to add a temporary binding in a higher scope so you can assign a String to it
That gives me a panic over at
does fix it?
It fixes the panic, but it doesn't fix the main issue (nothing opens).
ok, you'll have to figure out why that didn't work and what the proper fix is.
Ok, some more investigation: the builder wants to open which is "rust/build/x8664-unknown-linux-gnu/compiler-" but this file doesn't exist. builds that file, except under rustcmain, however. That's not much help. Is the idea behind your suggested fix, to compile rustcdriver if nothing else is provided, or to open the (assumedly compiled) docs if nothing else is provided? Currently in that function, . If the former is true, then the fix would be to check for if and pass the arg to cargo that way. If the latter is true, then there's a further bug in that isn't being compiled when it's supposed to be. Forgive the newcomer questions! If anyone wants to fix this before me, feel free - I see the prioritize label :)
If == [], that means we should build all the compiler crates. Maybe we need to add back the logic that was there before, to treat rustc_driver as the root? I guess since they're all part of the larger workspace doesn't do the right thing by default like it does elsewhere.
Just to be sure: It should open this? !
Change:
fn next(&mut self) -> Option<char> { self.0.next() } } <del> /// An iterator over the titlecase mapping of a given character, returned from /// the [`to_titlecase` method](../primitive.char.html#method.to_titlecase) on /// characters. #[unstable(feature = "unicode", reason = "recently added")] pub struct ToTitlecase(CaseMappingIter); #[stable(feature = "unicode_case_mapping", since = "1.2.0")] impl Iterator for ToTitlecase { type Item = char; fn next(&mut self) -> Option<char> { self.0.next() } } </del> enum CaseMappingIter { Three(char, char, char),

Discussion:
Converting a string to titlecase requires a word-breaking algorithm, which std does not provide. We do have the method for converting a single char to titlecase, if one can identify the first char of a word. This method requires a few kb of lookup tables. We might want to consider whether its wise to ship one without the other. This is marked for stabilization in 1.2 so we need to decide soon. cc
so I'm fine just deleting it, I don't think it's marked to be stable.
Change:
<ins> // check-pass #![feature(const_fn)] const fn nested(x: (for<'a> fn(&'a ()), String)) -> (fn(&'static ()), String) { x } pub const TEST: (fn(&'static ()), String) = nested((|_x| (), String::new())); fn main() {} </ins>

Discussion:
The following ICEs (example by shows This means that is wrong. It might be possible to also trigger this without nightly features through const_prop.
Baring a way to do the proper structural subtyping check, the only solution I see is to go back to comparing layouts in all cases (as a fallback after types mismatch) -- but does not like this, as far as I recall. Any other proposals?
Change:
} impl AsInner<c::in6_addr> for Ipv6Addr { <ins> #[inline] </ins> fn as_inner(&self) -> &c::in6_addr { &self.inner } } impl FromInner<c::in6_addr> for Ipv6Addr { <ins> #[inline] </ins> fn from_inner(addr: c::in6_addr) -> Ipv6Addr { Ipv6Addr { inner: addr } }

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: assembly generated should be equivalent to: Instead, this happened: the generated assembly retains calls to Ipv4::octets and Ipv4::from, leaving the assembly poorly optimized I've played with different ways of implementing the safe version, but cannot find anyway get it to optimize further. Good assembly: Bad assembly: and (both include an IPv6 example as well) Adding '-Z mir-opt-level=2' (or higher) does optimize away the call to octets, but not the call to from. I get the same optimization behavior when building a binary, at least on my own platfom (x86-64 Windows MSVC) <!-- 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. --:
Maybe it's just missing s?
I will try to test with adding in the appropriate places in std
This is a trivial method on a concrete type, so yeah, probably just needs . Or you want to turn on LTO. (If it were generic it wouldn't be necessary, but for concrete things the bodies aren't in the meta.)
So I found when a crate exports a function with , it does get optimized where called (though I'm . On the other hand, the same logic inside function will not be inlined: this basic program, for instance, retains assembly calls to octets() and from(): Edit: copy the right "basic program" this time... With on the methods in libstd, the two calls are optimized away. Is this worth a PR to add to libstd? If so, is there anything that shouldn't have in the API? Seems to me like nearly everything would be better inlined, at least for IPv4, but I'm far from an expert.
Feel free to open a PR I guess, your reviewer will decide whether it should be merged or not.
Ping do you want to work on fixing this issue?
Change:
.emit(); return vec![Annotatable::Item(item)]; <del> } </del> <ins> }; </ins> // has_*_signature will report any errors in the type so compilation // will fail. We shouldn't try to expand in this case because the errors

Discussion:
Edit: outstanding work is to change the span from pointing at the function body to point at the return type. adds a test for the case where a unit test returns a value that does not implement . The message currently talks about and has an ugly multi-line span: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
As long as we have the method signature around when we emit E0277, it has a field with the span for the return type, which should be used for this instead, but this will probably require some special casing this in that (already quite hairy) diagnostic code. Extending could be possible, but I would advice against doing so to avoid turning that attribute into a bigger monster than it already is.
Chiming in that this confused me as I was preparing for a Rust training session, where I expect it would confuse the students even more. Specifically, this should not talk about at all as it's plausible to cause people to look in the wrong spot.
CC
Just started learning Rust and came across this error while writing some tests- I absolutely agree "ungreat" is perfect word choice.
It could get even more confusing when : Rust 1.64
This issue is now (mostly) fixed on nightly by and should be closed I think. The error message is now correct but the span is still “ugly”. I've overlooked this issue and only closed its duplicate, namely .
Actually, let's keep this open only for the span change :)
Just wrap the return type with a struct and implement the Termination trait for that wrapper struct example
Note that this GitHub issue is about the subpar error message given by the compiler which should be fixed and not about potential solutions for user code when facing this message. claim
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. use m::{START, END}; fn main() { match 42u32 { m::START...m::END => {}, 0u32...m::END => {}, m::START...59u32 => {}, _  => {}, } } mod m { pub const START: u32 = 4; pub const END:   u32 = 14; } </ins>

Discussion:
The following code: Produces this error: Putting parens around and doesn't fix it.
Also, it doesn't work too (Should?):
Change:
cargo.env("RUSTC_ERROR_FORMAT", error_format); } if cmd != "build" && cmd != "check" && cmd != "rustc" && want_rustdoc { <del> cargo.env("RUSTDOC_LIBDIR", self.sysroot_libdir(compiler, self.config.build)); </del> <ins> cargo.env("RUSTDOC_LIBDIR", self.rustc_libdir(compiler)); </ins> } if mode.is_tool() {

Discussion:
To reproduce, make sure you have an entirely clean checkout -- I did . Then run This will go on for a while and ultimately fail with Notably, it doesn't seem to build LLVM at all -- which may be why it can't find a codegen-backend...
Turns out that works fine. However, stage 0 tests with doctests still seem pretty much broken. Can these even reasonably work without having a "bootstrap rustdoc"?
Cc
Note that it fails in stage 1 as well -- both of these fail:
Change:
errors = { path = "../librustc_errors", package = "rustc_errors" } rustc_metadata = { path = "../librustc_metadata" } rustc_mir = { path = "../librustc_mir" } <ins> rustc_plugin = { path = "../librustc_plugin/deprecated" } # To get this in the sysroot </ins> rustc_plugin_impl = { path = "../librustc_plugin" } rustc_save_analysis = { path = "../librustc_save_analysis" } rustc_codegen_utils = { path = "../librustc_codegen_utils" }

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. 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! cc the PR reviewer, and -- nominating for prioritization.
should fix this