jiebi/CodeConvo huggingface dataset:
Change:
Right now on our bots we're basically in a state where if valgrind rpass tests are compiled dynamically they will all fail, but when compiled statically they will pass. I'm not really sure what's going on unfortunately, but this is either a bug in valgrind or a bug with us, and we should know precisely what it is to ensure something more sinister isn't lurking. Some links: - first pass at linking tests statically, fixed - another pass at linking all tests statically
All the failures seem to be within platform’s dynamic loader. Here’s a few things to try: updating kernel+glibc to the most recent versions (4.4-ish and 2.23-ish, respectively) help? downgrading kernel+glibc to some older version help? non-linux/non-glibc work correctly?
Any news/changes on this one ?

Discussion:
<del> // no-prefer-dynamic </del> #![allow(dead_code)] // check dtor calling order when casting enums.

<del> // no-prefer-dynamic </del> // This would previously leak the Box<Trait> because we wouldn't // schedule cleanups when auto borrowing trait objects. // This program should be valgrind clean.

<del> // no-prefer-dynamic </del> fn main() { let _ = std::io::stdin(); let _ = std::io::stdout();

<del> // no-prefer-dynamic </del> // ignore-emscripten thread_local!(static FOO: Foo = Foo);

<del> // no-prefer-dynamic </del> static mut DROP_RAN: bool = false; struct Foo;

<del> // no-prefer-dynamic </del> static mut DROP_RAN: isize = 0; struct Foo;

<del> // no-prefer-dynamic </del> #![feature(unsized_tuple_coercion)] static mut DROP_RAN: bool = false;

<del> // no-prefer-dynamic </del> #![feature(unsized_tuple_coercion)] static mut DROP_RAN: isize = 0;

<del> // no-prefer-dynamic </del> // ignore-cloudabi // ignore-emscripten // ignore-sgx no processes

<del> // no-prefer-dynamic </del> // pretty-expanded FIXME #23616 #![feature(rustc_private)]
Change:
can return an error after a partial write if flushing the inner fails (). It should instead return , ignoring the error. I originally thought this problem was systematic so I audited stdlib. Apparently it isn't... See below. The write trait guarantees: However, this is violated all over stdlib. For example, if is written to a , the could write , try to flush, and then return an error due to a failed flush. However, has been written violating the spec. IMO, the solution is to return for partial writes and drop the error (if any). This should be safe because of write's write-xor-error guarantee. If the error was transient, the caller never needs to know. Otherwise, they will will learn of it on the next write. Here's everything in the stdlib that implements write (and should be audited): [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [ ] in (buggy) [x] in (buggy but unfixable and deprecated). [x] in [x] in [x] in [ ] in (panics on partial write) [x] in [x] in [x] in
Note: this could, e.g., theoretically cause to write on interrupt.
Ok. Actually, it turns out that only and are really problematic. on windows is bad but at least it's acknowledged in the code with a ...
So, is actually correct (I misread some of the code). This is just a bug in , nothing more.
Nice effort to audit it all!

Discussion:
match memchr::memrchr(b'n', buf) { Some(i) => { let n = try!(self.inner.write(&buf[..i + 1])); <del> if n != i + 1 { return Ok(n) } try!(self.inner.flush()); </del> <ins> if n != i + 1 || self.inner.flush().is_err() { // Do not return errors on partial writes. return Ok(n); } </ins> self.inner.write(&buf[i + 1..]).map(|i| n + i) } None => self.inner.write(buf),

} #[test] <ins> fn test_line_buffer_fail_flush() { // Issue #32085 struct FailFlushWriter<'a>(&'a mut Vec<u8>); impl<'a> Write for FailFlushWriter<'a> { fn write(&mut self, buf: &[u8]) -> io::Result<usize> { self.0.extend_from_slice(buf); Ok(buf.len()) } fn flush(&mut self) -> io::Result<()> { Err(io::Error::new(io::ErrorKind::Other, "flush failed")) } } let mut buf = Vec::new(); { let mut writer = LineWriter::new(FailFlushWriter(&mut buf)); let to_write = b"abcndef"; if let Ok(written) = writer.write(to_write) { assert!(written < to_write.len(), "didn't flush on new line"); // PASS return; } } assert!(buf.is_empty(), "write returned an error but wrote data"); } #[test] </ins> fn test_line_buffer() { let mut writer = LineWriter::new(Vec::new()); writer.write(&[0]).unwrap();
Change:
is not reentrant (you can't a mutex if you already ed it and haven't released the lock), but this behavior is . Looks like the exact consequences of locking the mutex twice vary by platform. On linux, you get a deadlock. On windows there is a panic: Maybe this should on all platforms?
Windows will also deadlock most of the time as we use SRWLOCK instead of CRITICAL_SECTION, it should basically be documented that you can't lock a mutex twice on the same thread.
But are the exact consequences of locking twice unspecified?
Yeah I think we'll want to leave it unspecified. We must detect it with CRITICALSECTION as the underlying primitive allows reentrancy, and the most reasonable thing to do there is to just panic. We'd probably panic if we could on SRWLOCK and pthreadmutex_t, but they're not as easily detectable.
The problem is that Rust is so paranoid about data races, that one has to uses mutexes all over the place (if using shared memory) to fight the borrow checker off. This results then in increased risk of deadlocks due to the fact that locks are not reentrant.
parkinglot crate provides reentrant mutex if you need it: I‘m curious what’re the reasons behind not providing reentrant mutex as the default implementation in the standard library?
I think it's because Mutex and friends were originally meant to be wrappers around the native OS synchronization primitives, and some OS mutexes are not reentrant, though I'm not 100% sure on that.
there's definitely an interesting conversation to have here, but a closed PR is not the right venue for such discussions: it's unlikey to be noticed by anyone not originally subscribed to the issue it actively pings all relevant folks, which spends people's time. I've moved this issue to the forum: In the future, please consider steering folks to the appropriate discussion platforms, rather then engaging in the conversation on GitHub :) Thanks!

Discussion:
/// held. An RAII guard is returned to allow scoped unlock of the lock. When /// the guard goes out of scope, the mutex will be unlocked. /// <ins> /// The exact behavior on locking a mutex in the thread which already holds /// the lock is left unspecified, however, this function will not return on /// the second call, it might e.g. panic or deadlock. /// </ins> /// # Errors /// /// If another user of this mutex panicked while holding the mutex, then /// this call will return an error once the mutex is acquired. <ins> /// /// # Panics /// /// This function might panic when called if the lock is already held by /// the current thread. </ins> #[stable(feature = "rust1", since = "1.0.0")] pub fn lock(&self) -> LockResult<MutexGuard<T>> { unsafe {
Change:
On Mac OS, I get the following when building with : We should track down what's going on with this test, and get the builders enabling debug assertions in general to catch this kind of problem.
cc

Discussion:
-> Result<Duration, Duration> { if self >= other { Ok(if self.t.tv_usec >= other.t.tv_usec { <del> Duration::new(self.t.tv_sec as u64 - other.t.tv_sec as u64, (self.t.tv_usec as u32 - other.t.tv_usec as u32) * 1000) </del> <ins> Duration::new((self.t.tv_sec - other.t.tv_sec) as u64, ((self.t.tv_usec - other.t.tv_usec) as u32) * 1000) </ins> } else { <del> Duration::new(self.t.tv_sec as u64 - 1 - other.t.tv_sec as u64, </del> <ins> Duration::new((self.t.tv_sec - 1 - other.t.tv_sec) as u64, </ins> (self.t.tv_usec as u32 + (USEC_PER_SEC as u32) - other.t.tv_usec as u32) * 1000) })
Change:
This test is ignored on MSVC because MSVC does not have a sprintf function. We have a variadic function defined in test helpers, which should be used in this test as well. See for an example.
The ? What to do with it?
It should be copied over along with the block.

Discussion:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // ignore-msvc -- sprintf isn't a symbol in msvcrt? maybe a #define? #![feature(libc, std_misc)] extern crate libc; use std::ffi::{CStr, CString}; use libc::{c_char, c_int}; </del> <ins> #[link(name = "rust_test_helpers")] </ins> extern { <del> fn sprintf(s: *mut c_char, format: *const c_char, ...) -> c_int; } unsafe fn check<T, F>(expected: &str, f: F) where F: FnOnce(*mut c_char) -> T { let mut x = [0 as c_char; 50]; f(&mut x[0] as *mut c_char); assert_eq!(expected.as_bytes(), CStr::from_ptr(x.as_ptr()).to_bytes()); </del> <ins> fn rust_interesting_average(_: u64, ...) -> f64; </ins> } pub fn main() { <ins> // Call without variadic arguments </ins> unsafe { <del> // Call with just the named parameter let c = CString::new(&b"Hello Worldn"[..]).unwrap(); check("Hello Worldn", |s| sprintf(s, c.as_ptr())); // Call with variable number of arguments let c = CString::new(&b"%d %f %c %sn"[..]).unwrap(); check("42 42.500000 a %d %f %c %snn", |s| { sprintf(s, c.as_ptr(), 42, 42.5f64, 'a' as c_int, c.as_ptr()); }); </del> <ins> assert!(rust_interesting_average(0).is_nan()); } </ins> <del> // Make a function pointer let x: unsafe extern fn(*mut c_char, *const c_char, ...) -> c_int = sprintf; </del> <ins> // Call with direct arguments unsafe { assert_eq!(rust_interesting_average(1, 10i64, 10.0f64) as i64, 20); } </ins> <del> // A function that takes a function pointer unsafe fn call(fp: unsafe extern fn(*mut c_char, *const c_char, ...) -> c_int) { // Call with just the named parameter let c = CString::new(&b"Hello Worldn"[..]).unwrap(); check("Hello Worldn", |s| fp(s, c.as_ptr())); </del> <ins> // Call with named arguments, variable number of them let (x1, x2, x3, x4) = (10i64, 10.0f64, 20i64, 20.0f64); unsafe { assert_eq!(rust_interesting_average(2, x1, x2, x3, x4) as i64, 30); } </ins> <del> // Call with variable number of arguments let c = CString::new(&b"%d %f %c %sn"[..]).unwrap(); check("42 42.500000 a %d %f %c %snn", |s| { fp(s, c.as_ptr(), 42, 42.5f64, 'a' as c_int, c.as_ptr()); }); } </del> <ins> // A function that takes a function pointer unsafe fn call(fp: unsafe extern fn(u64, ...) -> f64) { let (x1, x2, x3, x4) = (10i64, 10.0f64, 20i64, 20.0f64); assert_eq!(fp(2, x1, x2, x3, x4) as i64, 30); } </ins> <del> // Pass sprintf directly call(sprintf); </del> <ins> unsafe { call(rust_interesting_average); </ins> <del> // Pass sprintf indirectly </del> <ins> // Make a function pointer, pass indirectly let x: unsafe extern fn(u64, ...) -> f64 = rust_interesting_average; </ins> call(x); } }
Change:
rustc 1.7.0 ( 2016-02-29) (32-bit GNU) rustc 1.9.0-nightly ( 2016-03-17) (32-bit MSVC)
This was fixed by , methods' ABIs were previously completely ignored.
Yes, rustc 1.9.0-nightly ( 2016-03-21) (32-bit MSVC) is working fine. Thanks.
I'd like this open to make sure a test ends up being written.

Discussion:
<ins> // Copyright 2016 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. // compile-flags: -C no-prepopulate-passes struct Foo; impl Foo { // CHECK: define internal x86_stdcallcc void @{{.*}}foo{{.*}}() #[inline(never)] pub extern "stdcall" fn foo<T>() { } } fn main() { Foo::foo::<Foo>(); } </ins>
Change:
This code compiles fine on stable/beta, but ICEs on nightly: cc happened last night, maybe recent trans changes?
That's weird...

Discussion:
for (j, &tupled_arg_ty) in tupled_arg_tys.iter().enumerate() { let dst = StructGEP(bcx, llval, j); let arg = &self.fn_ty.args[idx]; <ins> idx += 1; </ins> let b = &bcx.build(); if common::type_is_fat_ptr(bcx.tcx(), tupled_arg_ty) { let meta = &self.fn_ty.args[idx];

<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn foo<T>() -> T { loop {} } fn test() { let ref mut a: &mut FnMut((i8,), i16) = foo(); a((0,), 0); } fn main() { let _ = test; } </ins>
Change:
rustc 1.9.0-nightly ( 2016-03-19) Same on python:
Oh dear, looks like these are stored in the network byte order and they're apparently supposed to not be stored as such.
Works on latest nightly. Thanks!

Discussion:
sin6_family: c::AF_INET6 as c::sa_family_t, sin6_port: hton(port), sin6_addr: *ip.as_inner(), <del> sin6_flowinfo: hton(flowinfo), sin6_scope_id: hton(scope_id), </del> <ins> sin6_flowinfo: flowinfo, sin6_scope_id: scope_id, </ins> .. unsafe { mem::zeroed() } }, }

/// Returns the flow information associated with this address, /// corresponding to the `sin6_flowinfo` field in C. #[stable(feature = "rust1", since = "1.0.0")] <del> pub fn flowinfo(&self) -> u32 { ntoh(self.inner.sin6_flowinfo) } </del> <ins> pub fn flowinfo(&self) -> u32 { self.inner.sin6_flowinfo } </ins> /// Change the flow information associated with this socket address. #[unstable(feature = "sockaddr_setters", reason = "recent addition", issue = "31572")] pub fn set_flowinfo(&mut self, new_flowinfo: u32) { <del> self.inner.sin6_flowinfo = hton(new_flowinfo) </del> <ins> self.inner.sin6_flowinfo = new_flowinfo; </ins> } /// Returns the scope ID associated with this address, /// corresponding to the `sin6_scope_id` field in C. #[stable(feature = "rust1", since = "1.0.0")] <del> pub fn scope_id(&self) -> u32 { ntoh(self.inner.sin6_scope_id) } </del> <ins> pub fn scope_id(&self) -> u32 { self.inner.sin6_scope_id } </ins> /// Change the scope ID associated with this socket address. #[unstable(feature = "sockaddr_setters", reason = "recent addition", issue = "31572")] pub fn set_scope_id(&mut self, new_scope_id: u32) { <del> self.inner.sin6_scope_id = hton(new_scope_id) </del> <ins> self.inner.sin6_scope_id = new_scope_id; </ins> } }
Change:
See this gist: , with the attached llvm bitcode. Rust compiles it fine, but looking through the bitcode, it appears that rust is returning a stack pointer.
Reproduced as of
Hm. I think this is just returning the slice, which is ok, no? The lifetime is static, and it outlives the caller lifetime as inferred..
Well, that example is a bit unfortunate but the following compiles too: and prints out rubbish for me.
That's also fine. is a slice to a static array (i.e. with unlimited lifetime). Or .. it should be!
Oh. I guess if it prints out rubbish it's probably compiling as non-static. Yeah, that's bad.
Stack arrays should be returned by-value (so through an output parameter). They can't be static because they're mutable.
Reproduced as of Here is a slightly elaborated version of that I used to better understand the scenario: On my machine, it prints:
mhm. definitely disappointing and worth fixing (keeping those importance labels) but I don't think it's a showstopper for 0.6. removing milestone.
Still reproducible,, thought I get slightly different output. Nominating for production ready.
accepted for production-ready milestone
This is a pretty nasty and subtle bug. Just spent a while trying to figure out how the heck I was getting back, and finally tracked it down to returning the results of and having that transform into behind my back. Given how easy it is to accidentally trigger (especially with ) I think it should be a bit higher priority.
yes, you're right. I'll take a look, I suspect the fix is fairly straightforward.
accepted for P-backcompat-lang.
This was fixed as part of . However, no test case. I'll add one.

Discussion:
<del> // Copyright 2012 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. // xfail-test fn function() -> &mut [int] { let mut x: &'static mut [int] = &[1,2,3]; x[0] = 12345; x //~ ERROR bad } fn main() { let x = function(); error!("%?", x); } </del>

<ins> // Copyright 2012 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 we cannot return a stack allocated slice fn function(x: int) -> &'static [int] { &[x] //~ ERROR mismatched types } fn main() { let x = function(1); let y = x[0]; } </ins>
Change:
Can we include the output of into the source archives? It can be important for beta and nightly. Ideally the download page should also display them.
This should be a pretty easy bug to tackle for anyone aspiring to do so. Let's just create a file called in our tarballs with basically the output of
This will require editing the makefiles in as well as the rustbuild build system in . The version info is in . I realized that the installers already include this info in a file called 'version', so we can just duplicate that logic. Use the same lower case naming for consistency.

Discussion:
@$(call E, making src image) $(Q)rm -Rf tmp/dist/$(SRC_PKG_NAME)-image $(Q)mkdir -p tmp/dist/$(SRC_PKG_NAME)-image/lib/rustlib/src/rust <ins> $(Q)echo "$(CFG_VERSION)" > tmp/dist/$(SRC_PKG_NAME)-image/lib/rustlib/src/rust/version </ins> $(Q)tar  -C $(S)  -f - 

// Rename directory, so that root folder of tarball has the correct name t!(fs::rename(&dst_src, &plain_dst_src)); <ins> // Create the version file write_file(&plain_dst_src.join("version"), build.version.as_bytes()); </ins> // Create plain source tarball let mut cmd = Command::new("tar"); cmd.arg("-czf").arg(sanitize_sh(&distdir(build).join(&format!("{}.tar.gz", plain_name))))

Some(format!("/{}/{}", drive, &s[drive.len_utf8() + 2..])) } } <ins> fn write_file(path: &Path, data: &[u8]) { let mut vf = t!(fs::File::create(path)); t!(vf.write_all(data)); } </ins>
Change:
Testcase: Excerpt from the assembly: This is generated from the expression . The code should look more like this: LLVM probably should be able to perform this optimization, but it looks like it's confusing itself by converting into a shift. CC
Thanks. Do you want me to experiment here?
I'm not planning on digging into this any further.

Discussion:
if index == 0 || index == self.len() { return true; } match self.as_bytes().get(index) { None => false, <del> Some(&b) => b < 128 || b >= 192, </del> <ins> // This is bit magic equivalent to: b < 128 || b >= 192 Some(&b) => (b as i8) >= -0x40, </ins> } }
Change:
A bunch of my nightly builds are now generating the error: error: the current crate is indistinguishable from one of its dependencies: it has the same crate-name and was compiled with the same arguments. This will result in symbol conflicts between the two. [E0519] This is likely due to the revamp of symbol names, but it's also unfortunately a regression on nightly. I think what's happening here is that Cargo isn't passing to rustdoc (because it can't) and then the libc crate is conflicting with the in-tree libc crate. cc
Ah, and an example of a
I'm hitting this too.
cc
specifically with libc, or with other crate names?
So I'm trying to figure out if the right answer here is that we should just be passing in metadata to rustdoc? Seems plausible.
Hm, in rustdoc we actually don't care about symbol name conflict, so we could indicate that to the crate loader?
The analysis of the underlying reason by seems plausible to me, by the way.
Maybe, but it seems sloppy to me -- I mean, why don't we care? The signatures might well be different, for example, so it might well matter. In any case, I'm trying to understand what is leading us to get this conflict still (I haven't reproduced it yet -- what target do I need to use?). I feel like I'm still missing something. From what I can tell, the error comes when generating docs for the crate -- so why is it accessing anyway? And doesn't give metadata when building? (Do we tell rustdoc where to find all dependencies the same way we tell rustc? I would expect maybe it's falling back to some other behavior and scraping things off the file system?) Perhaps part of it is that I am a bit removed from the details of how a lot of this lower level stuff works.
ok, I see now that this error is not when bootstrapping.
Further investigation reveals that somehow we do not seem to be supplying except for tests. Oops. That will presumably fix this conflict, though not in the best possible way -- because now the makefile libc will have a disambiguator, so the rustdoc version would have a disambiguator of just and everybody is happy. That said, it seems to me that should take a argument -- presumably it should take the same arguments as rustc, since it basically invokes rustc.
Can you elaborate on that?
I believe this is fixed in , explained here: To elaborate on the lack of metadata, rustdoc simply doesn't accept flags, so that's why it's not being passed :)
did you actually check whether this is fixed? I wonder if it's worth trying to allow rustdoc to accept -C metadata -- I guess so long as it doesn't matter, it doesn't matter.
Nah I was hoping to test with today's nightly, but that's blocked on I'm pretty confident that the change would fix this, however.
FYI rustc 1.9.0-nightly ( 2016-03-29) fixed this issue for me

Discussion:
$$(RUSTFLAGS$(1)_$(4)_T_$(2))  --out-dir $$(@D)  -C extra-filename=-$$(CFG_FILENAME_EXTRA)  <ins> -C metadata=$$(CFG_FILENAME_EXTRA)  </ins> $$< @touch -r $$@.start_time $$@ && rm $$@.start_time $$(call LIST_ALL_OLD_GLOB_MATCHES,
Change:
May be a dup of
not a dup, I think.
This is indeed a dup of .
The job failed! Check out the build log: <details<summary<iClick to see the possible cause of the failure (guessed by this bot)</i</summary</details

Discussion:
<del> Subproject commit a416c5e0f7c4c9473069a58410d3ec3e86b1ac0d </del> <ins> Subproject commit fc24fce73f878e641094b1802df1e748c5fe233a </ins>