jiebi/CodeConvo huggingface dataset:
Change:
// * C and Cdecl obviously support varargs. // * C can be based on Aapcs, SysV64 or Win64, so they must support varargs. // * EfiApi is based on Win64 or C, so it also supports it. <ins> // * System falls back to C for functions with varargs. </ins> // // * Stdcall does not, because it would be impossible for the callee to clean //   up the arguments. (callee doesn't know how many arguments are there) // * Same for Fastcall, Vectorcall and Thiscall. <del> // * System can become Stdcall, so is also a no-no. </del> // * Other calling conventions are related to hardware or the compiler itself. match self { Self::C { .. } | Self::Cdecl { .. } <ins> | Self::System { .. } </ins> | Self::Aapcs { .. } | Self::Win64 { .. } | Self::SysV64 { .. }

Discussion:
While testing variadic function support with I discovered that Rust requires such functions to use either "C" or "cdecl" ABIs but requires the "system" ABI on non-x86 Windows. My undertstanding from discussing with is that this is not an issue with itself but with Rust's insistence that such functions aren't allowed to use the "system" ABI. It's just that is very strict about calling convention so that's where the issue surfaced. On x64 I should be able to compile this but Rust says no: This example works if I change the ABI to "cdecl" but that's not meant to be a valid ABI on x64 and so when I try to compile this with it fails: The practical result is that it is impossible to link this function with on non-x86.
cc which originally variadics support to some other calling conventions (though not it seems) behind the feature gate .
A workaround is to use "C" on non-x86 as I implemented here:
Thoughts on permitting variadic parameters with the calling convention for non-x86 Windows? If gets merged then we'll be pushing folks to use so that they get the correct calling convention for Windows APIs on all architectures, but that breaks compatibility with variadic parameters.
This work-around is . Would be great if there was a way that it could be avoided. :)
There's a comment saying this can't work: I don't understand anything about these ABIs so I can't say how accurate this is. Also I see nothing here special-casing x86, so why does the issue specifically mention non-x86?
Happy to update as soon as there's a way to avoid it.
Can we make equal to when applied to a variadic function? It's supposed to be whatever ABI is correct for the system api and is the correct ABI for a variadic win32 function. According to the acts as when applied to a variadic function.
Went ahead and opened for this.
Change:
MetadataArchive(ref ar) => ar.as_slice(), }; if slice.len() < 4 { <del> &[] </del> <ins> &[] // corrupt metadata </ins> } else { <del> let len = ((slice[0] as u32) << 24) | ((slice[1] as u32) << 16) | ((slice[2] as u32) << 8) | ((slice[3] as u32) << 0); slice.slice(4, len as uint + 4) </del> <ins> let len = (((slice[0] as u32) << 24) | ((slice[1] as u32) << 16) | ((slice[2] as u32) << 8) | ((slice[3] as u32) << 0)) as uint; if len + 4 <= slice.len() { slice.slice(4, len + 4) } else { &[] // corrupt or old metadata } </ins> } } }

Discussion:
error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace task 'rustc' panicked at 'assertion failed: end <= ()', make:  [x8664-apple-darwin/stage2/lib/rustlib/x8664-apple-] Error 101 pull the latest source code ./configure sudo make ==panic env: Darwin localhost 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASEX8664 x8664 make:  [x8664-apple-darwin/stage2/lib/rustlib/x8664-apple-] Error 101
If you run it should take care of it (see , , , , )
yeah, I should check it! sorry about that!

Got this compiler panic on some (probably badly-typed or otherwise bogus) code while I was playing around with Iron. (on Ubuntu 14.04.1, if that makes a difference) The code (), depending on iron 0.0.7: Full command-line (from rerunning cargo with ):
This is due to a recent change, should fix it.

Compiler error when trying to build
Thanks for the report! If you run though it should fix things.

Archlinux: I'll fiddle around with gdb later.
should fix this.
Yes, and if this reproduces afterwards, feel free to reopen!
Indeed it did, thanks! FWIW I wouldn't have been able to reopen this issue, since you closed it. I would've been able to reopen only if I closed it myself.

I got crash error when compile rust from latest code, the backtrace is: my OS is:
If you run it should fix this, but thanks for the report!
Change:
use error; use error::Error as error_Error; use fmt; <ins> use sys::os::error_string; #[test] fn test_debug_error() { let code = 6; let msg = error_string(code); let err = Error { repr: super::Repr::Os(code) }; let expected = format!("Error {{ repr: Os {{ code: {:?}, message: {:?} }} }}", code, msg); assert_eq!(format!("{:?}", err), expected); } </ins> #[test] fn test_downcasting() {

Discussion:
yields practically no information, and to even figure out what type of error occurred a user has to go run another rust script to use the Display implementation on an error with that os error code. It's not a good UX.
The Debug impl is used quite often, especially through unwrap.
You can look up the error code via (e.g. ). In fact on Windows the standard way to report an error is via its status.
I appreciate the tip, but still consider this is a serious UX problem since I really shouldn't need python to conveniently find out what kind of error I'm dealing with.
Change:
} } <del> fn type_is_slice(ty:t) -> bool { </del> <ins> fn type_is_slice(ty: t) -> bool { </ins> match get(ty).sty { ty_rptr(_, mt) => match get(mt.ty).sty { ty_vec(_, None) | ty_str => true,

Discussion:
fails to compile: cc
What does the l-wrong label mean here?
It means that the current behavior of the compiler is incorrect.
Change:
let len = other.len(); // We need to extend the buf if it's not a power of two, too small <del> // or doesn't have at least one free space if !buf.capacity().is_power_of_two() </del> <ins> // or doesn't have at least one free space. // We check if `T` is a ZST in the first condition, // because `usize::MAX` (the capacity returned by `capacity()` for ZST) // is not a power of two and thus it'll always try // to reserve more memory which will panic for ZST (rust-lang/rust#78532) if (!buf.capacity().is_power_of_two() && mem::size_of::<T>() != 0) </ins> || (buf.capacity() < (MINIMUM_CAPACITY + 1)) || (buf.capacity() == len) {

Discussion:
This code panics under Miri, and also when I compile to WASM, though not when running normally. The overflow is here:
I can reproduce when using Miri, but it works fine for me with WASM: (Same with nightly toolchain.)
panics with it always fails here because is greater than so underflows.
Why is this specific to ZSTs?
does not allocate for and starts out with capacity which overflows when converting to a deque which does not expect this
Assigning and removing as in the prioritization working group.
Currently on playground it seems to work fine both under Miri and regular rustc? Indeed something would be very wrong if it only panicked on Miri... version panics both with rustc and Miri. Maybe the example in the OP should be updated.
Yes, though at time of posting it did fail under miri (and only under miri) on the playground. Sorry if I was unclear; I meant that I got the same panic when running the built WASM.
My guess is that something in libstd changed to fix the panic for your case (but not for and when you tested this, Miri was broken in the latest toolchain so playground had an older version of Miri. When this happens again, please note down the exact versions of every component involved, so we can make sure this is comparing Miri and rustc for the same toolchain, not two different versions of Rust.
The originally reported panic is an overflow check and one of those that is not inherited cross-crate. To observe it the standard library must be built with overflow checks. It's still an issue right now.
Ah, so this stopped to fail in Miri when we recently stopped building libstd with debug assertions.
Change:
/// assert_eq!("abaaa".find('b'), Some(1)); /// assert_eq!("abaaa".find('c'), None); /// <ins> /// // &[char; N] /// assert_eq!("ab".find(&['b', 'a']), Some(0)); /// assert_eq!("abaaa".find(&['a', 'z']), Some(0)); /// assert_eq!("abaaa".find(&['c', 'd']), None); /// </ins> /// // &[char] /// assert_eq!("ab".find(&['b', 'a'][..]), Some(0)); /// assert_eq!("abaaa".find(&['a', 'z'][..]), Some(0));

Discussion:
Many methods accept patterns of any type that implements the trait. One such type is , which matches any single character mentioned in the pattern slice. However, patterns are not as nice to use as one might hope. This does not compile: Rust complains: The method constrains its argument type with , and Rust won't apply the usual type coercions like to in order to satisfy trait bounds. One must instead write: It's not a tragedy, but it's not pretty either. CC
Shorter version:
cc
Lovely! This hadn't occurred to me.
Yeah, this was a known issue from the start. This concrete impl is basically a originally-nice API that is old enough that it got gradually worse over time in multiple iterations. If I remember right, there was originally a hardcoded method that just took a , and the language still allowed array literals to coerce to static slices, so originally you could do . At some point we got a cleaning up of the expression syntax, which lead to . And then when I proposed the trait the methods got generic, and no longer liked to do deref coercions, leading to the ugly as shortest possible literal form. I think the only real "fix" for this is deprecating this pattern, and/or holding out till we have char array generics and can have a impl for all directly.
Triage: Seems like the same status today; we are making progress on const generics, but it's not ready yet.
Change:
#![feature(associated_consts)] #![feature(collections)] <ins> #![feature(collections_drain)] </ins> #![feature(core)] #![feature(libc)] #![feature(rustc_private)]

Discussion:
cc
The rfc says It also includes an example which depends on usize: However RangeArgument only implements the first four. Furthermore as things stand it does not appear possible to accept RangeArgument<usizeand usize simultaneously, because dispatch doesn't consider the trait bound and reports that conflicting implementations exist.
Yes, was explicit about these issues. I forsee a new RFC to finish off drain and maybe the RangeArgument trait.
I believe this has
Change:
} #[test] <del> fn connect_timeout_unroutable() { // this IP is unroutable, so connections should always time out, // provided the network is reachable to begin with. let addr = "10.255.255.1:80".parse().unwrap(); let e = TcpStream::connect_timeout(&addr, Duration::from_millis(250)).unwrap_err(); assert!(e.kind() == io::ErrorKind::TimedOut || e.kind() == io::ErrorKind::Other, "bad error: {} {:?}", e, e.kind()); } #[test] </del> fn connect_timeout_unbound() { // bind and drop a socket to track down a "probably unassigned" port let socket = TcpListener::bind("127.0.0.1:0").unwrap();

Discussion:
When I run the test suite on campus, I get a failure in : The test says "this IP is unroutable, so connections should always time out," but evidently there's something about the setup at this location that was not anticipated. The results are the same whether I am connected to WiFi or through ethernet. Both connections go through the same router (a Linksys WRT120N I have physical access to, which doesn't appear to save any sort of logs), and I don't know where it goes after that. I can work around it by disconnecting from the internet entirely, and do not have issues when running the tests at home (same laptop, different network).
is your subnet 10.255.255.0/24 or 10.255.0.0/16 or 10.0.0.0/8 or anything similar? You can check by running . Either way, the test is ill formed and should be correctled.
I'm not there right now, but just in case I forget to come back to this, I do recall that the router is accessed through an IP in the 192.168.x.x subnet. (I'm not sure if this precludes the situation you have described) (I wish GitHub notifications had a "mark unread" feature!)
It appears not to be. wifi ethernet:
I think I must have misread something when making that test - the IP is inside of an address block reserved for private networks which means it could be routable depending on how your network is set up. We could instead use an IP from one of the documentation blocks like 192.0.2.0.
The address 10.255.255.1 is routable on my vanilla Ubuntu 18.04 box: The address 192.0.2.0 is not routable: Therefore, this test always fails on this box. I will file a PR changing it to 192.0.2.0.
This is a dup of .
Change:
<ins> // edition:2018 // Avoid spurious warnings of unused lifetime. The below async functions // are desugered to have an unused lifetime // but we don't want to warn about that as there's nothing they can do about it. #![deny(unused_lifetimes)] #![allow(dead_code)] pub async fn october(s: &str) { println!("{}", s); } pub async fn async_fn(&mut ref s: &mut[i32]) { println!("{:?}", s); } macro_rules! foo_macro { () => { pub async fn async_fn_in_macro(&mut ref _s: &mut[i32]) {} }; } foo_macro!(); pub async fn func_with_unused_lifetime<'a>(s: &'a str) { //~^ ERROR lifetime parameter `'a` never used println!("{}", s); } pub async fn func_with_two_unused_lifetime<'a, 'b>(s: &'a str, t: &'b str) { //~^ ERROR lifetime parameter `'a` never used //~^^ ERROR lifetime parameter `'b` never used println!("{}", s); } pub async fn func_with_unused_lifetime_in_two_params<'c>(s: &'c str, t: &'c str) { //~^ ERROR lifetime parameter `'c` never used println!("{}", s); } fn main() {} </ins>

Discussion:
Async functions that take references seem to always trigger the lint (which is allow-by-default). Example: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I found which describes basically the same problem.
Seeing as this lint is not enabled by default, marking as deferred, though this would be good to fix and probably not too hard.
claim
Looks the same issue as . A little inelegant but if we can suppress the lint I think...
Change:
<ins> // edition:2018 // Avoid spurious warnings of unused lifetime. The below async functions // are desugered to have an unused lifetime // but we don't want to warn about that as there's nothing they can do about it. #![deny(unused_lifetimes)] #![allow(dead_code)] pub async fn october(s: &str) { println!("{}", s); } pub async fn async_fn(&mut ref s: &mut[i32]) { println!("{:?}", s); } macro_rules! foo_macro { () => { pub async fn async_fn_in_macro(&mut ref _s: &mut[i32]) {} }; } foo_macro!(); pub async fn func_with_unused_lifetime<'a>(s: &'a str) { //~^ ERROR lifetime parameter `'a` never used println!("{}", s); } pub async fn func_with_two_unused_lifetime<'a, 'b>(s: &'a str, t: &'b str) { //~^ ERROR lifetime parameter `'a` never used //~^^ ERROR lifetime parameter `'b` never used println!("{}", s); } pub async fn func_with_unused_lifetime_in_two_params<'c>(s: &'c str, t: &'c str) { //~^ ERROR lifetime parameter `'c` never used println!("{}", s); } fn main() {} </ins>

Discussion:
<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Duplicate of
Change:
<ins> // run-rustfix // Parser should know when a semicolon is missing. // https://github.com/rust-lang/rust/issues/87197 fn main() { let x = 100; //~ ERROR: expected `;` println!("{}", x); //~ ERROR: expected `;` let y = 200; //~ ERROR: expected `;` println!("{}", y); } </ins>

Discussion:
: The current output is: We should detect cases where a semicolon would be appropriate (probe that the current token and maybe limited lookahead confirm that what comes next could be a valid statement on its own) and suggest a semicolon. . We might want to silence one or the other depending on whether the current token might be starting a statement or an item ( vs , etc.). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Sorry, I don't have much time these days. release-assignment
Just a guess: could this be addressed with another block, as in
I think we would need to answer this question: why is the logic here not handling the cases we want to handle?
This seems to be on track given the clue "probe that the current token and maybe limited lookahead confirm that what comes next could be a valid statement on its own"...
claim
release-assignment
That is a great question: as the code is written it looks like it should work. I don't know why it isn't triggering :( It might be that isn't being called in these case. It might be a good idea to uplift most of this method into
I'd like to give this a try. claim
Change:
//         debug self => _1; //     } //     bb0: { <del> //         _2 = discriminant(_1); </del> //         _0 = move _1; //         return; //     }

Discussion:
The doesn't have any effect. (Labeling because this prevents codegen of the like . Which may result in a few extra instructions being emitted to move registers and jump to the return block for cg_clif.) modify labels: +A-mir +A-mir-opt +A-cranelift
We already have a pass that propagates the terminator, it should be possible to make it handle as well. (however can leave sideeffects visible to the caller, so maybe this should be a proper dead code elimination pass instead)
For background, this is a side-effect of (see the MIR diagram in the PR summary) and . The MIR for the above example used to contain a frivolous open drop of . After my changes to drop elaboration, all branches of the open drop become no-op s, which are then removed by the pass. The read of the discriminant as part of the open drop remains, however. To my knowledge, we don't have a dead-code elimination pass for the MIR, which would be the proper way to handle this.
Change:
float: left; padding: 20px; } <ins> .stability { border-left: 5px solid #000; border-radius: 3px; padding: 0 3px; float: right; background: #fff; text-transform: lowercase; } .stability.Deprecated { border-color: #D60027; color: #880017; } .stability.Experimental { border-color: #EC5315; color: #a53c0e; } .stability.Unstable { border-color: #FFD700; color: #b39800; } .stability.Stable { border-color: #AEC516; color: #7c8b10; } .stability.Frozen { border-color: #009431; color: #007726; } .stability.Locked { border-color: #0084B6; color: #00668c; } </ins>

Discussion:
Nominating for milestone 5, production-ready
Can't be done without running resolve.
should be optional at most, as sometimes you want to see them
just a bug, removing milestone/nomination.
Still relevant though parenting to metabug on rustdoc_ng
/cc This would involve looking at the visibility of the associated trait and excluding the impl from the list if it's not public.
Didn't find a trait to test it with but it should be done now.
Change:
/// See [`scope`] for details. #[stable(feature = "scoped_threads", since = "1.63.0")] pub struct Scope<'scope, 'env: 'scope> { <del> data: ScopeData, </del> <ins> data: Arc<ScopeData>, </ins> /// Invariance over 'scope, to make sure 'scope cannot shrink, /// which is necessary for soundness. ///

Discussion:
The following code sometimes causes a data race to be reported by Miri: Miri reports: The deallocation occurs when returns and its local variable gets deallocated. The read occurs here (I am fairly sure): This reads the contents of the field after the . But the moment the is done, the memory backing might be deallocated. That makes the read a potential use-after-free, and a race with the deallocation. Cc
The following patch fixes this: However, even with this patch, we still run into a problem like the gets deallocated while still runs. This is still UB even after my proposed because contains a field that is not inside an (the field). So that part of what points to is expected to stay live for the entire duration of the function call. Another alternative might be to put the entire into an rather than allocating it on the stack frame of .
Going to attach this to the 1.63 milestone, since this is in a newly stabilized feature -- we may wish to back out stabilization for a cycle or backport fixes.
Re-opening for beta backport.
The fix was backported in .
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // FIXME(#8767) bad error message; Option is not a module impl<T> Option<T> { //~ERROR found module name used as a type </del> <ins> // ignore-tidy-linelength impl<T> Option<T> { //~ERROR inherent implementations are not allowed for types not defined in the current module. </ins> pub fn foo(&self) { } }

Discussion:
The code <pretrait T {} impl&lt;U: T&gt; Vec&lt;U&gt; {} fn main() { let r = Vec::fromslice(&[1u]); } </prefails with 4:36 error: unresolved name . fn main() { let r = Vec::from_slice(&[1u]); } </preRemoving the <codeimpl</codeline causes the code to compile fine. Thx Ms2ger for finding such a small example case.
I think this is related to anonymous modules appearing, resolves to a module due to the impl. If you change to this you get another interesting error:
Note that a workaround is to wrap in parens, as Then you get the correct error message about trying to on a type outside of its crate.
I've spent some time investigating this bug and I think that the cleanest thing to do is to (closed B-RFC right now, does anyone have a link to a relevant RFC?) and require to occur only in the same module as, and after, the definition of . This check would be done before creating the anonymous trait module with name . Otherwise in the case of where a definition of is not visible, is not resolved until typeck (at which point the compiler will complain if is defined outside the current crate, or not at all), but if there are resolve errors like the current bug, these will be exposed to the user first and halt compilation. The current behaviour upon encountering where has not been defined in the current module is to create a module (which shadows any other modules exposed by statements) and try to resolve any symbols into this module. This means that the current support for outside of the module is defined in is <ialready</ibroken. Consider for example will error out with "unresolved name ". I'm sure I could come up with other examples of currently broken behaviour like this.
the closing of that bug predates our RFC process, so there would not be a link to an RFC.
Interestingly, this breaks in the opposite direction if you qualify the :
My suggestion is that should be disallowed. I will submit an RFC with these changes.