jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Regression test for #66270, fixed by #66246 struct Bug { incorrect_field: 0, //~^ ERROR expected type } struct Empty {} fn main() { let Bug { any_field: Empty {}, } = Bug {}; } </ins>

Discussion:
paniked when I tried to use GAT, I didn't know does not support it then. Anyway I think it is not supposed to panic. I have confirmed with version 1.39 on Windows, my PC version 1.36 on Linux. It said,
Seems a duplicate of , I did not noticed it when I was opening this issue, sorry. There is also a small difference that I did not turn on
cc &
This should be fixed in the next nightly

This is a toy example I made in order to later make tests which run for with . This is the error I get: Error notes: - compiler flags: I don't know if this kind of pattern is intended as part of the feature or in its future, but if not, I think it can be satisfied by using a procedural macro so that's probably alright. The point of the pattern, as I mentioned at the beginning of the post, is to be able to test a particular generic type's implementation up to an arbitrary range of numeric constants. While implementing another project to help test the feature, I stumbled upon the problem of wanting to test hundreds of different constants, but having no way of doing so with say, a loop over a range of constants. This is one way I thought of making it work. Am I making the right decisions here? How should I go about testing hundreds of constants? Thanks :)
Note: another example that also panics. I know, yes, expressions aren't yet supported as const parameters. But it has the same panic, which is WEIRD! When I wrote this one, I thought "okay maybe inside a statement, the compiler won't try things like because the case when is is already covered... and with exhaustiveness check it should know that N = 0 won't enter the second branch". But I must be wrong there, or otherwise how did it panic? Error:
Minified: I'm pretty sure that I saw this ICE before, but I can't find it ;/
This is just a result of having an expression () as a const generic argument. I don't actually think there's a canonical issue, though many of the issues are essentially the same. is the best tracking issue.
No longer ICEs on the latest nightly
Oh, the new output is interesting. It probably needs to be monomorphized so that the compiler detects the infinite recursion. And then we could also write one that doesn't have infinite recursion :3 In order to force an error, a test function should suffice right?
What do you mean?
I mean that I imagined it might detect that the function recurses infinitely onto itself. But I guess it reads it lazily, and lets monomorphization do the job of recursing the function? which would make a lot of sense to me.
Change:
self.selcx.infcx().resolve_type_vars_if_possible(&obligation.predicate); } <ins> debug!("process_obligation: obligation = {:?}", obligation); </ins> match obligation.predicate { ty::Predicate::Trait(ref data) => { let trait_obligation = obligation.with(data.clone());

Discussion:
(continuation of as it looks like a compiler bug after all, important points repeated here) There appear to be an issue in handling traits that have a parent bound boxed through an await point: the following example fails to compile with for<'r'r : 'static (note: I'm using generators for simplicity of reproduction, see below for a futures-only example) However, when removing the bound on , it appears to compile correctly, even though the itself still has the bound. The error originated in code that looked like: The being here the trait that has the bound. This was tested with at commit and nightly 2018-08-14. I couldn't manage to get a generator-only version to fail: this compiles. This is potentially related to , as the same appears there?
Some work has started on ; the information there will likely be helpful to someone trying to fix this.
I think I've hit this with a generator-only code.
I'm marking this issue as blocking the async-await stabilization -- if nothing else, we need to investigate it and figure out what is going on.
I did some more digging into this problem. This code will actually ICE if using a version of rustc built with debug assertions. Moreover, the follow example code -- which doesn't use generators at all -- will ICE in the same way: the problem here ultimately has to do with the way that the WF code works. I left some , but the bottom line is something like this: The WF code presently descends through binders but (generally speaking) opts not to prove WF conditions that involve higher-ranked regions. The strategy was described as "lazy" in the relevant RFC, but with the new universes code we can generally try to pursue something better, so I hope to get rid of it sooner or later. Anyway the idea is that whenever a higher-region is "expanded" with a particular value, we'll prove the WF at that point. So in this particular case we wind up with a type -- for this type to be WF, the region bound must hold. We are producing this constraint. If debug assertions are enabled, we ICE out because the constraint isn't supposed to include higher-ranked regions (here, ). But without debug assertions, we fail to detect that, and then we just wind up failing to prove it.

It's kind of hard to stumble across this ICE normally, because defaults to since we see the bound declared on . However, with generators, it occurs more readily because when constructing the generator witness, we replace the with a bound region (we replace all the internal regions in this way). Pursuant with the existing lazy strategy, I think the right fix is just for the wf code to ignore the constraint -- and that is a small patch to do. I will probably open a PR around this shortly.
Great, thank you! I can confirm that on latest nightly the issue is no longer there :D
Change:
use crate::ptr; use crate::sync::atomic::{AtomicBool, AtomicU8, Ordering}; use crate::sys::cvt; <ins> use libc::{EBADF, EINVAL, ENOSYS, EOPNOTSUPP, EOVERFLOW, EPERM, EXDEV}; </ins> #[cfg(test)] mod tests;

Discussion:
While updating my code base from 1.49 to 1.50 we noticed a failures in a program that rebuilds files from small chunks. We are opening a file in append mode, one in read mode, and we stream one into the other (as for the snippet below). Testing this out confirmed that the error happens on the reader file when the writer is in append mode, whenever we use a / or not. If we load the whole file into a string and then use on the same data it works as intended, as does setting the file in write mode (while it becomes necessary to seek to the end). Checking what got shipped into 1.50 we suspect the probable culprit to be What we are guessing is that this change is using the syscall that doesn't support files in append mode even when the file is in append mode, triggering the Bad File Descriptor error I tried this code (): I expected to see this happen: the files to be concatenated Instead, this happened: returns Strace for the code snipped: Example that works with loading the file into a string before copy (): It most recently worked on: 1.49 50 : no 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-stable-regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
syscall326 is copyfilerange. And indeed, it has this error code overloading the more common meaning of EBADF. assign.
Error: Parsing assign command in failed: ...'ot assign.' ''... Please let know if you're having trouble with this bot.
claim
If you need a workaround for the moment you can do which should defeat the incorrect optimizations by going through a trait object so it can't see it's dealing with a file.
Nice, this is awesome. We will try this tomorrow which should allow to migrate our codebase to 1.50! Thanks a lot for the quick help on this..
Test out the workaround and it works, while we wait for the actual fix to come out, thanks a lot!

label +T-libs-impl +I-prioritize +regression-from-stable-to-stable +C-bug +O-linux workaround is available. fix needs review.
Assigning as discussed as part of the and removing . label -I-prioritize +P-critical
Not sure if this is related, but I have a smaller code which also fails with EBADF: Tested with Rust 1.41.1, stable, nightly on Debian 9 and Rust 1.41.1 on Debian 10. Also, the trick with doesn't work in this case.
Totally unrelated and not a bug. opens a file in write-only mode, then you try to read from it later. Use to create read-write files.
lol, just figured it out and wanted to post. Thanks anyway! It's still strange it's EBADF instead of EPERM.
Change:
eprint("removing", temp_path) os.unlink(temp_path) <ins> def curl_version(): m = re.match(bytes("^curl ([0-9]+).([0-9]+)", "utf8"), require(["curl", "-V"])) if m is None: return (0, 0) return (int(m[1]), int(m[2])) </ins> def download(path, url, probably_big, verbose): for _ in range(4):

Discussion:
We're passing --retry: but by default that only retries 500 errors, not any error: Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is a regression from when I moved the downloads from python to rust (about a year ago now I think).
Mentoring instructions: Add the option to the invocations, in and This doesn't affect the Windows Powershell fallback, since we already retry on any error. There are many other invocations across the repo, but they seem to not be causing problems.
claim
This is quite new flag shipped with recent versions of curl, which is not supported on many machines/platforms(including our CI runners). We can consider using as I also suggest at
I'd like to take a look at this. Looking through the PR history, we would like basic retry logic written in Rust versus using a curl flag like to retry during the bootstrap process. If it's a 404, then do not retry, but any other errors should be retried. I assume there is a http library already vendored in, so no new dependencies should be .
claim
Thanks! This shouldn't be needed. For now, retrying on "connection refused" () should be fine.
I'm a little confused as to why was closed then. What more is there beyond adding the retry refused connections flag?
I forgot that our CI runners depend on very old curl versions which doesn't support the flag I suggested. Sorry, you are right. As jyn also said() in that PR, we can handle this in Rust
are we ok with adding the dependency to facilitate sending requests to the payload URL? I'm very hesitant to add another crate dependency to the core payload. But without it, we would need to manually built a request via the standard library tcp library. Which is a little awkward. doesn't actually have support for sending requests. I suppose, in the case we decide to use it, another library would need to be as well?
What about using curl arguments to read the status code and handle it in rust logic? It might be a bit ugly, but adding a dependency solely for this purpose seems like overkill to me.
I agree adding a new dep seems extreme.

I can try parsing the curl exit code, great idea.
claim
claim
Hello Is this still relevant?
please don't ping me about rust-lang/ issues. is the current maintainer.
We didn't change any curl flags since then; it should be still relevant.
release-assignment
Change:
// This makes several assumptions about what layouts we will encounter; we match what // codegen does as good as we can (see `extract_field` in `rustc_codegen_ssa/src/mir/operand.rs`). let inner_val: Immediate<_> = match (**self, self.layout.abi) { <del> // if the entire value is uninit, then so is the field (can happen in ConstProp) </del> <ins> // If the entire value is uninit, then so is the field (can happen in ConstProp). </ins> (Immediate::Uninit, _) => Immediate::Uninit, <ins> // If the field is uninhabited, we can forget the data (can happen in ConstProp). // `enum S { A(!), B, C }` is an example of an enum with Scalar layout that // has an `Uninhabited` variant, which means this case is possible. _ if layout.abi.is_uninhabited() => Immediate::Uninit, </ins> // the field contains no information, can be left uninit // (Scalar/ScalarPair can contain even aligned ZST, not just 1-ZST) _ if layout.is_zst() => Immediate::Uninit,

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
seem like options that when paired together would cause issues... At first glance, I'm actually not sure why this is filed as a bug.
I agree. Nobody should be testing , I don't know why those passes are even in the codebase. But this is a bug. I've found this in real code with a much smaller set of flags: And this bisects to Bisected by hand, there's no nightly with that PR yet. Don't know where Matthias got that toolchain.
Afaict likes to do ICE testing against master
We just hit this on Fuchsia as well. I think we should revert the PR until we fix this issue and reland it.
Another one with
Also here's a list of files from the rustc repo that all seem to trigger the problem in one way or another
Looks like there is one more issue in GVN ():
There is no basis for the assumption that interpreter will never downcast to an uninhabited variant:
nice example! That assert was as an experiment to see if we ever hit that codepath, and it seems like the answer is yes. It should thus be removed, with a suitable const-eval test case.
I wonder if that code shouldn't have a read somewhere though... it is conceptually a match after all. Still, the assertion should go: That adds test, but not the others.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
use rustc_hir::def::DefKind; use rustc_hir::def_id::DefId; use rustc_hir::intravisit::Visitor; <ins> use rustc_hir::is_range_literal; </ins> use rustc_hir::lang_items::LangItem; use rustc_hir::{AsyncGeneratorKind, GeneratorKind, Node}; use rustc_hir::{Expr, HirId};

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The code here: Seems we can only get more context from , with only we can not know whether the current code snippet is an ident or a more complicated expression. The current is . An completed solution should make sure we get something like in ? A hack I'm thinking is checking whether contains spaces, if so we suggest it like:
I guess we have more similar issues for other suggestions come from .
This is an similar case, but we handle it well: Output is: The codepath is different, we take care parenthesis here, with :
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. // Test that when you use ufcs form to invoke a trait method (on a // trait object) everything works fine. trait Foo { fn test(&self) -> i32; } impl Foo for i32 { fn test(&self) -> i32 { *self } } fn main() { let a: &Foo = &22_i32; assert_eq!(Foo::test(a), 22); } </ins>

Discussion:
Discovered this ICE in the rollup that I'm preparing:
In Grust, I tried to change to: The crate compiles without an issue, but compiling another crate where this is used results in an ICE that looks to be this one.
Looks like I missed a case in
Nominating for 1.0 beta.
Are there any known workarounds for this problem? I ran into this in a hard way trying to update to the newest nightlies.
not sure, I'll try to get a PR up today
a new type wrapper around the object would probably work, ping me on irc () for more details
I just wanna run iron example on MAC 10.10 with rust-nightly, the same error occurs, I don't know if it's of the same case: error: internal compiler error: static call to invalid vtable: VtableObject(VtableObject(object_ty=error::Error + 'static))
This is also blocking Iron, which itself compiles well, but using the crate fails:
Fix in , sorry for the delay.
thanks for the work! I pulled your PR and built with it, and my code compiles again. Hooray!
Change:
<ins> struct NeedsDropTypes<'tcx, F>(std::marker::PhantomData<&'tcx F>); impl<'tcx, F, I> Iterator for NeedsDropTypes<'tcx, F> //~^ ERROR type annotations needed where F: Fn(&Missing) -> Result<I, ()>, //~^ ERROR cannot find type `Missing` in this scope I: Iterator<Item = Missing>, //~^ ERROR cannot find type `Missing` in this scope {} 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Correction: () (cc I'm not sure I'll be able to figure it out. searched nightlies: from nightly-2022-06-01 to nightly-2023-04-11 regressed nightly: nightly-2023-03-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Change:
<ins> // ignore-tidy-linelength #![feature(const_generics)] #![crate_name = "foo"] pub enum Order { Sorted, Unsorted, } // @has foo/struct.VSet.html '//pre[@class="rust struct"]' 'pub struct VSet<T, const ORDER: Order>' // @has foo/struct.VSet.html '//h3[@id="impl-Send"]/code' 'impl<const ORDER: Order, T> Send for VSet<T, ORDER>' // @has foo/struct.VSet.html '//h3[@id="impl-Sync"]/code' 'impl<const ORDER: Order, T> Sync for VSet<T, ORDER>' pub struct VSet<T, const ORDER: Order> { inner: Vec<T>, } // @has foo/struct.VSet.html '//h3[@id="impl"]/code' 'impl<T> VSet<T, { Order::Sorted }>' impl <T> VSet<T, {Order::Sorted}> { pub fn new() -> Self { Self { inner: Vec::new() } } } // @has foo/struct.VSet.html '//h3[@id="impl-1"]/code' 'impl<T> VSet<T, { Order::Unsorted }>' impl <T> VSet<T, {Order::Unsorted}> { pub fn new() -> Self { Self { inner: Vec::new() } } } </ins>

Discussion:
When playing around with const generics, I found some weird generated docs: How to reproduce: and go to the documentation on the VecSet struct (inside the vecset module), and find the auto impls.
My guess is that rustdoc just doesn't yet handle const generics properly
Support for const generics in rustdoc has not been tested very thoroughly at all (I don't think there are any tests in the test suite for it at all yet). We also have a number of issues with pretty-printing consts (). That said, I imagine this would not be too difficult to fix: we're getting the right parameter — we're just debug printing it instead of pretty-printing it.
Change:
<del> // build-pass </del> <ins> // This test ensures that we do not allow ZST statics to initialize themselves without ever // actually creating a value of that type. This is important, as the ZST may have private fields // that users can reasonably expect to only get initialized by their own code. Thus unsafe code // can depend on this fact and will thus do unsound things when it is violated. // See https://github.com/rust-lang/rust/issues/71078 for more details. </ins> <del> static FOO: () = FOO; </del> <ins> static FOO: () = FOO; //~ cycle detected when const-evaluating `FOO` </ins> fn main() { FOO

Discussion:
I tried this code: I expected the code to fail to compile with a cycle error. Instead, it compiled and ran,printing the value of . I was able to verify that this bug happens for the 1.42.0 stable, 1.43-beta.5, and 1.44.0-nightly(2020-04-11 ) versions. Trying this code in it errors up to 1.36.0,and doesn't error anymore from 1.37.0 onwards.
cc
narrowed to the following: Auto merge of - petrochenkov:builtout, r=eddyb Auto merge of - luca-barbieri:optimize-refcell-borrow, r=RalfJung Auto merge of - Centril:rollup-, r=Centril Auto merge of - petrochenkov:rpass, r=Centril Possibly ?
Weaponized soundness hole (using as a foundation): ==
cc
oopsie yeah... is probably where this started. But that is crucial to fix The problem is that "reading from a ZST" isn't actually doing anything. Here's the MIR for : So there actually is a that loads from this static (I didn't expect that). But in Miri, a ZST load just checks that the address is in-bounds; no actual access to the underlying memory happens so there is no cycle error.
Assigning as and removing .
Change:
<del> //@ compile-flags: --crate-name foo pub fn foo() {} </del>

Discussion:
Running on my checkout with the current master commit fails with tons of errors. here's the last few screens of messages:
Is the check looking for in the full path? My rustc checkout is in a directory called (it's my 2nd of 3 checkouts), and I suspect tidy gets confused by that.
It does CC
That code should probably use .
Oops, I will try to fix this ASAP
Submitted a fix for this at .
Change:
} } <del> pub fn Store(cx: Block, val: ValueRef, ptr: ValueRef) { if cx.unreachable.get() { return; } </del> <ins> pub fn Store(cx: Block, val: ValueRef, ptr: ValueRef) -> ValueRef { if cx.unreachable.get() { return C_nil(cx.ccx()); } </ins> B(cx).store(val, ptr) } <del> pub fn VolatileStore(cx: Block, val: ValueRef, ptr: ValueRef) { if cx.unreachable.get() { return; } </del> <ins> pub fn VolatileStore(cx: Block, val: ValueRef, ptr: ValueRef) -> ValueRef { if cx.unreachable.get() { return C_nil(cx.ccx()); } </ins> B(cx).volatile_store(val, ptr) }

Discussion:
The attached source produces code that misbehaves on some platforms that are picky about memory access alignment. The code should exit with code 2, but on both Emscripten-generated JavaScript and ARMv5, it finishes with exit code 1 to indicate that the field is incorrectly tested as equal to . Changing the field to a type results in proper execution on these platforms. All optimization levels seem to cause it. Libraries that make use of structs with fields followed by enums seem particularly prone to this problem. It all works fine on platforms that allow unaligned memory access like x86, ARMv6, etc. Expected output: (x86, ARMv6) Actual output: (ARMv5, Emscripten) Note that the same ARM binary runs on both ARMv5 and ARMv6 platforms, producing the different results. See also: ( and removed)
To quote myself: