jiebi/CodeConvo huggingface dataset:
Change:
This currently is not the case, so you can't impl where is unsized. Note that this is distinct from whether is (it is).
Hmm, yeah I guess at first glance it seems strange that is but is this at least looks like an easy fix to me.
I'm not really sure who to ping on this, maybe I should just make up a pull request and see what happens?
Yeah, probably :)
Yeah, just adding seems fine.
Awesome. I'll put together a pull request now then.

Discussion:
/// } /// ``` #[lang="deref_mut"] <del> pub trait DerefMut<Sized? Result>: Deref<Result> { </del> <ins> pub trait DerefMut<Sized? Result> for Sized? : Deref<Result> { </ins> /// The method called to mutably dereference a value fn deref_mut<'a>(&'a mut self) -> &'a mut Result; }
Change:
These two tests seem both to test that is invalid. One of these (probably the one, because it’s newer) should be removed.

Discussion:
<del> // 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. extern { const FOO: uint; //~ ERROR: unexpected token: `const` } fn main() {} </del>
Change:
TOC entries for impls contain special characters like etc and the links are not sanitized correctly per pandoc's rules.

Discussion:
<del> Subproject commit bebcf527e67755a989a1739b7cfaa8f0e6b30040 </del> <ins> Subproject commit 5e9051f71638aa941cd5dda465e25c61cde9594f </ins>

<del> Subproject commit 17842ebb050f62e40a4618edeb8e8ee86e758707 </del> <ins> Subproject commit dd962bb82865a5284f2404e5234f1e3222b9c022 </ins>

<del> Subproject commit 51817951d0d213a0011f82b62aae02c3b3f2472e </del> <ins> Subproject commit e356977fceaa8591c762312d8d446769166d4b3e </ins>

<del> Subproject commit 229ad13b64d919b12e548d560f06d88963b25cd3 </del> <ins> Subproject commit 20482893d1a502df72f76762c97aed88854cdf81 </ins>

<del> Subproject commit 2d1947ff34d50ca46dfe242ad75531a4c429bb52 </del> <ins> Subproject commit b6d4a4940bab85cc91eec70cc2e3096dd48da62d </ins>
Change:
This may be a duplicate, but can't find the original if it exists. See for the problem. Most of the intrinsics are doc'd with stability markers, but none of that shows up. Docs also consequently don't show up in re-exports.
Uh, are you sure? The doesn't seem to have stability markers at all. Reexports would be a different story though.
The copy_memory ones do.
Ah, you are right. It seems that any extern fns (and not only ) with stability markers are missing them.
To clarify: functions declared inside an block are missing stability markers. Extern functions have them. That is:
There is a FIXME related to this issue, Now that the issue is closed can the FIXME be fix, or made more specific?

Discussion:
if abi == abi::RustIntrinsic { encode_inlined_item(ecx, rbml_w, IIForeignRef(nitem)); } <ins> encode_attributes(rbml_w, &*nitem.attrs); let stab = stability::lookup(ecx.tcx, ast_util::local_def(nitem.id)); encode_stability(rbml_w, stab); </ins> encode_symbol(ecx, rbml_w, nitem.id); } ast::ForeignItemStatic(_, mutbl) => {

} encode_bounds_and_type(rbml_w, ecx, &lookup_item_type(ecx.tcx,local_def(nitem.id))); <ins> encode_attributes(rbml_w, &*nitem.attrs); let stab = stability::lookup(ecx.tcx, ast_util::local_def(nitem.id)); encode_stability(rbml_w, stab); </ins> encode_symbol(ecx, rbml_w, nitem.id); encode_name(rbml_w, nitem.ident.name); }

fn visit_struct_field(&mut self, s: &StructField) { self.annotate(s.node.id, &s.node.attrs, |v| visit::walk_struct_field(v, s)); } <ins> fn visit_foreign_item(&mut self, i: &ast::ForeignItem) { self.annotate(i.id, &i.attrs, |_| {}); } </ins> } impl Index {
Change:
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!

Discussion:
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> } } }
Change:
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.

Discussion:
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> } } }
Change:
Compiler error when trying to build
Thanks for the report! If you run though it should fix things.

Discussion:
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> } } }
Change:
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.

Discussion:
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> } } }
Change:
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!

Discussion:
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> } } }
Change:
Basically, it's now possible to write: and have everything work. This unfortunately means that doing something like with a will zero b, but not move it. /cc
I noticed this possibility too and was debating if this is a problem. It's not clear to me. Probably best to disallow it for now.
at the very least, it's causing incorrect behaviour at runtime, since it's zeroing out types like a move, but not forbidding the use of them like a copy.
Looks unsafe to me: Program received signal SIGSEGV, Segmentation fault. 0x0000555555598e5c in ()
I agree that combining it with zeroing is unsafe. If zeroing did not occur, or we did not zero for types that were copy, there wouldn't necessarily be a problem.
Anyhow, it's easiest to forbid it for now. We can always make it legal later if someone comes up with a persuasive use case. Idempotent destructors seem like a bit of an odd thing.

Discussion:
FieldDoesNotImplementCopy(ast::Name), VariantDoesNotImplementCopy(ast::Name), TypeIsStructural, <ins> TypeHasDestructor, </ins> } pub fn can_type_implement_copy<'a,'tcx>(param_env: &ParameterEnvironment<'a, 'tcx>,

{ let tcx = param_env.tcx; <del> match self_type.sty { </del> <ins> let did = match self_type.sty { </ins> ty::ty_struct(struct_did, substs) => { let fields = ty::struct_fields(tcx, struct_did, substs); for field in fields.iter() {

return Err(FieldDoesNotImplementCopy(field.name)) } } <ins> struct_did </ins> } ty::ty_enum(enum_did, substs) => { let enum_variants = ty::enum_variants(tcx, enum_did);

} } } <ins> enum_did </ins> } _ => return Err(TypeIsStructural), <ins> }; if ty::has_dtor(tcx, did) { return Err(TypeHasDestructor) </ins> } Ok(())

for this type; type is not a structure or  enumeration") } <ins> Err(ty::TypeHasDestructor) => { span_err!(tcx.sess, span, E0184, "the trait `Copy` may not be implemented for this type;  the type has a destructor"); } </ins> } } }

E0180, E0181, E0182, <del> E0183 </del> <ins> E0183, E0184 </ins> }

// option. This file may not be copied, modified, or distributed // except according to those terms. <del> impl Drop for int { </del> <ins> impl<'a> Drop for &'a mut int { </ins> //~^ ERROR the Drop trait may only be implemented on structures //~^^ ERROR cannot provide an extension implementation fn drop(&mut self) {

<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. #![feature(unsafe_destructor)] // issue #20126 #[derive(Copy)] //~ ERROR the trait `Copy` may not be implemented struct Foo; impl Drop for Foo { fn drop(&mut self) {} } #[derive(Copy)] //~ ERROR the trait `Copy` may not be implemented struct Bar<T>; #[unsafe_destructor] impl<T> Drop for Bar<T> { fn drop(&mut self) {} } fn main() {} </ins>
Change:
It starts talking about cell for some reason. I think this was copy + pasted from InvariantLifetime and never updated.
cc
doesn't have this example (atm), and, the example only makes sense with since there's no lifetimes involved in the definition of the type. I do think the example could probably have a little more description, but I don't think it's wrong. For reference, it currently says: rust /// The Cell type is an example which uses unsafe code to achieve /// "interior" mutability: /// /// /// /// The type system would infer that is only read here and /// never written, but in fact uses unsafe code to achieve /// interior mutability.

Discussion:
/// /// # Example /// <del> /// The Cell type is an example which uses unsafe code to achieve /// "interior" mutability: </del> <ins> /// The Cell type is an example of an `InvariantType` which uses unsafe /// code to achieve "interior" mutability: </ins> /// /// ``` /// struct Cell<T> { value: T } /// ``` /// <del> /// The type system would infer that `value` is only read here and /// never written, but in fact `Cell` uses unsafe code to achieve /// interior mutability. </del> <ins> /// The type system would infer that `value` is only read here /// and never written, but in fact `Cell` uses unsafe code to achieve /// interior mutability. In order to get correct behavior, the /// `InvariantType` marker must be applied. </ins> #[unstable(feature = "core", reason = "likely to change with new variance strategy")] #[lang="invariant_type"]
Change:
Code: Error: The compiler should tell us, struct doesn't implements , at least.
This is fixed (after changing the type of to ):
Needs test?

Discussion:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. struct X { x: i32 } fn main() { let mut b: Vec<X> = vec![]; b.sort(); //~^ ERROR the trait `core::cmp::Ord` is not implemented for the type `X` } </ins>
Change:
It becomes very hard to read certain signatures at the moment. A good example is : This would be a lot easier to read (assuming lands) like this: Reasoning being that right now the important part (return value) is lost somewhere in the middle whereas the trait bounds (which very often are not as important) are on the easier to read, end of the line.
+1 and I were all in favour of this (and some other rustdoc tweaks for making complicated signatures more readable, which I don't recall) when we discussed it in passing at the work week.
Can this be closed as of ?
Thanks

Discussion:
if gens.where_predicates.len() == 0 { return Ok(()); } <del> try!(f.write(" where ".as_bytes())); </del> <ins> try!(f.write(" <span class='where'>where ".as_bytes())); </ins> for (i, pred) in gens.where_predicates.iter().enumerate() { if i > 0 { try!(f.write(", ".as_bytes()));

} } } <ins> try!(f.write("</span>".as_bytes())); </ins> Ok(()) } }

font-size: 1em; position: relative; } <ins> /* Shift "where ..." part of method definition down a line */ .content .method .where { display: block; } /* Bit of whitespace to indent it */ .content .method .where::before { content: '      '; } </ins> .content .methods .docblock { margin-left: 40px; } .content .impl-items .docblock { margin-left: 40px; }
Change:
Looks like the errno should be generating the mentioned error kind, but someone forgot to wire them up.

Discussion:
} #[test] <ins> fn mkdir_path_already_exists_error() { use io::{IoError, PathAlreadyExists}; let tmpdir = tmpdir(); let dir = &tmpdir.join("mkdir_error_twice"); check!(mkdir(dir, io::USER_RWX)); match mkdir(dir, io::USER_RWX) { Err(IoError{kind:PathAlreadyExists,..}) => (), _ => assert!(false) }; } #[test] </ins> fn recursive_mkdir() { let tmpdir = tmpdir(); let dir = tmpdir.join("d1/d2");

"file descriptor is not a TTY"), libc::ETIMEDOUT => (io::TimedOut, "operation timed out"), libc::ECANCELED => (io::TimedOut, "operation aborted"), <ins> libc::consts::os::posix88::EEXIST => (io::PathAlreadyExists, "path already exists"), </ins> // These two constants can have the same value on some systems, // but different values on others, so we can't use a match

"invalid handle provided to function"), libc::ERROR_NOTHING_TO_TERMINATE => (io::InvalidInput, "no process to kill"), <ins> libc::ERROR_ALREADY_EXISTS => (io::PathAlreadyExists, "path already exists"), </ins> // libuv maps this error code to EISDIR. we do too. if it is found // to be incorrect, we can add in some more machinery to only
Change:
There are quite few os-specific types definitions whose traits implementations are not consistent. With the work happening in OIBIT, I've tried to keep the implementations of built-in traits consistent for both and . Unfortunately, the test suite for these implementations is not unified, therefore there's a high chance that some types for 's implementation may have some traits implemented, whereas the 's implementation doesn't. In theory, we can assume that common types for these implementations should implement the same built-in types, therefore there should be tests that enforce this guarantee in a common place. Some examples may be found in This bug is to track the work there which impacts the of our standard library.
I can mentor on this bug, tagging with
seems interesting. Can i take this bug? :)
it's all yours, lemme know if you need help/reviews
This should be closed now right?
correct. Thanks!

Discussion:
} } <ins> unsafe impl Send for Event {} unsafe impl Sync for Event {} </ins> struct Inner { handle: libc::HANDLE, lock: Mutex<()>,

} } <ins> unsafe impl Send for Inner {} unsafe impl Sync for Inner {} </ins> unsafe fn pipe(name: *const u16, init: bool) -> libc::HANDLE { libc::CreateNamedPipeW( name,

write_deadline: u64, } <del> unsafe impl Send for UnixStream {} unsafe impl Sync for UnixStream {} </del> impl UnixStream { fn try_connect(p: *const u16) -> Option<libc::HANDLE> { // Note that most of this is lifted from the libuv implementation.

deadline: u64, } <del> unsafe impl Send for UnixAcceptor {} unsafe impl Sync for UnixAcceptor {} </del> struct AcceptorState { abort: Event, closed: AtomicBool, } <del> unsafe impl Send for AcceptorState {} unsafe impl Sync for AcceptorState {} </del> impl UnixAcceptor { pub fn accept(&mut self) -> IoResult<UnixStream> { // This function has some funky implementation details when working with

deadline: u64, } <del> unsafe impl Send for TcpAcceptor {} unsafe impl Sync for TcpAcceptor {} </del> struct AcceptorInner { listener: TcpListener, abort: Event,

closed: AtomicBool, } <del> unsafe impl Send for AcceptorInner {} </del> unsafe impl Sync for AcceptorInner {} impl TcpAcceptor {
Change:
Per theme in , here's a minimized example exhibiting the same ICE:
This also triggers an ICE. The error and backtrace: output of rustc --version --verbose Note that removing the where clause eliminates the error. (although it isn't used anywhere)
Yet another variant:
Slight variant:
I'm currently getting the following ICE on the latest version of : The relevant code fragments: Changing the method call to use function notation, i.e. , as indicated in did not work here.

Discussion:
<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. trait Foo { fn answer(self); } struct NoData<T>; //~^ ERROR: parameter `T` is never used impl<T> Foo for T where NoData<T>: Foo { //~^ ERROR: overflow evaluating the requirement fn answer(self) { let val: NoData<T> = NoData; } } fn main() {} </ins>

<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. // exec-env:RUST_LOG=rustc::middle=debug fn main() { let b = 1isize; println!("{}", b); } </ins>
Change:
$ rustc --version rustc 0.13.0-nightly ( 2015-01-01 15:51:08 +0000)
Replacing with spits out a warning to use loop instead but compiles and runs as expected.
This is largely because the has a type parameter indicating the return value of the closure. In the case of , the closure return value cannot be inferred (as the function never returns). In the case of the closure return value is because the compiler assumes all while loops eventually terminate. To use , you can invoke like so: Here the is a manual ascription of what the return type should be, and it can be to say that it's the "unit return value"
Actually, for diverging type variables (which is what a without a gets typeck'ed to) we normally fall back to . However, that happens at the very end of type checking and so the fall back will not be used for dispatch resolution. Maybe we should do it earlier, then.
Here's the same issue: As seen It took me a bit to realize the issue was actually regarding the channel type, as I thought it was referring to the thread's move fn itself with the error:
I'm stuck with the same-looking bug, but the loop is apparently not the cause: When I comment-out the line, I get no errors. When the line is there, I get the error. Unfortunately I don't yet know enough to figure out what's wrong with that line. However, the error message is extremely confusing.
My mistake was trying to use mutable state across threads. Using AtomicUsize solved the problem. To be clear: the only issue is that the message "unable to infer enough type information" is confusing because it has nothing to do with the real problem. The loop statement without break caused no problems for me.
I have the same issue event with the program in "A 30-minute Introduction to Rust": it has the same error:

Discussion:
<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. use std::thread; fn main() { thread::Thread::spawn(move || { // no need for -> () loop { println!("hello"); } }); } </ins>
Change:
The new installer has a bug that causes the docs to be installed in a way that can't be read by non-root.
This is because the docs in-tree have non-world-readable permissions. I think we'll need a build step that just changes the permissions of everything in the doc directory.
Actually, I'm going to fix this in rust-installer.
Fixed in

Discussion:
<del> Subproject commit 3a37981744a5af2433fed551f742465c78c9af7f </del> <ins> Subproject commit b5ac4cd44321da10dfd70f070dbc9094ca3f92ff </ins>