jiebi/CodeConvo huggingface dataset:
Code change:
Currently, llvm is built with all the possible targets including Mips, ARM... For development, we can speed the build by enabling only the native target (x86 or x86_64). Maybe it would also speed the build of rustc?
FWIW, for development I use ccache (pass to ) and building LLVM takes one minute or less on a "fresh" bootstrap. (I usually work with several branches at the same time; one docker container per branch and all of them reuse the same ccache directory) Just please don't change the defaullt. I'd be very upset if I spent several minutes building stage1 rustc just to learn that it can't cross compile anything.
yeah, of course.
This is such a niche use case, to the point that it's arguably already moot by use of , if the sole purpose is to reduce build time. However there may be some other advantages, maybe space savings for use on some really storage-constrained systems? I don't know, it's trivial to make the list of targets configurable but the maintenance and support burden is real. What do the Rust team think? cc
Seems fine to me to add an option for this! We won't do it on the bots, but that doesn't mean it can't exist.

Related discussion:
text: (true, true) => "RelWithDebInfo", }; <ins> // NOTE: remember to also update `config.toml.example` when changing the defaults! let llvm_targets = match build.config.llvm_targets { Some(ref s) => s, None => "X86;ARM;AArch64;Mips;PowerPC;SystemZ;JSBackend;MSP430;Sparc", }; </ins> cfg.target(target) .host(&build.config.build) .out_dir(&dst) .profile(profile) .define("LLVM_ENABLE_ASSERTIONS", assertions) <del> .define("LLVM_TARGETS_TO_BUILD", "X86;ARM;AArch64;Mips;PowerPC;SystemZ;JSBackend;MSP430;Sparc") </del> <ins> .define("LLVM_TARGETS_TO_BUILD", llvm_targets) </ins> .define("LLVM_INCLUDE_EXAMPLES", "OFF") .define("LLVM_INCLUDE_TESTS", "OFF") .define("LLVM_INCLUDE_DOCS", "OFF")
Code change:
When building the following code: returns the following error message, which actually indicates the error, but also has a internal compiler error: My output:
Duplicate of , fixed in

Related discussion:
text: // // Such behavior is required for backward compatibility. // The same fallback is used when `a` resolves to nothing. <del> _ if self.primitive_type_table.primitive_types.contains_key(&path[0].name) => { </del> <ins> PathResult::Module(..) | PathResult::Failed(..) if scope == PathScope::Lexical && (ns == TypeNS || path.len() > 1) && self.primitive_type_table.primitive_types.contains_key(&path[0].name) => { </ins> PathResolution { base_def: Def::PrimTy(self.primitive_type_table.primitive_types[&path[0].name]), depth: segments.len() - 1,
Code change:
When building the following code: returns the following error message, which actually indicates the error, but also has a internal compiler error: My output:
Duplicate of , fixed in

Related discussion:
text: <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 main() { // Make sure primitive type fallback doesn't work in value namespace std::mem::size_of(u16); //~^ ERROR unresolved name `u16` //~| ERROR this function takes 0 parameters but 1 parameter was supplied // Make sure primitive type fallback doesn't work with global paths let _: ::u8; //~^ ERROR type name `u8` is undefined or not in scope } </ins>
Code change:
in a file's directory to indicate that the file has unsaved changes. When for features, the rustc development tool will fail if such a lockfile exists in the source tree, with (this part being the actual bug, being that a dirty tree should fail ) a message that doesn't make it clear what happened: (The novice compiler developer wonders: what file?) I think this is likely too obscure to be worth doing anything about, but somehow managed to fall slightly over my subjective threshold of "worth filing an Issue for"; sorry if I'm miscalibrated in this matter.
It looks like the has a two parameter case for reporting path errors, which means it could be fixed by just using
Yes, that's a bit better; thanks! :sparkling_heart: (trivial PR to follow)

Related discussion:
text: } contents.truncate(0); <del> t!(t!(File::open(file)).read_to_string(&mut contents)); </del> <ins> t!(t!(File::open(&file), &file).read_to_string(&mut contents)); </ins> for (i, line) in contents.lines().enumerate() { let mut err = |msg: &str| {
Code change:
It looks like the use of overlapped I/O on stdio ports may cause some problems in Windows. When I try to shell out to using on the stderr port, the command runs successfully but hangs at the end. pointed me to this commit as the likely culprit: Here's the smallest test case I could figure out how to create: I wanted to try to come up with a minimal Node script to shell out to, as opposed to . Unfortunately, I'm not good enough at debugging npm and Node to figure out exactly what they're doing that causes the hang.
Ok I've tested this and it's a stable-to-stable regression that happened between 1.8 and 1.9. I believe the 1.9 release is indeed the first one with , the likely change which is a culprit. Tagging appropriately as such.
It looks like Rust is passing overlapped-mode pipe handles to the child process. The function returns two overlapped HANDLES. I'm not sure the overlapped mode can be changed after the fact -- maybe would work -- but I don't see it used anywhere, and I'd wonder about its use on the server handle. If the child inherits overlapped-mode handles, it would need to do async I/O to stdin/stdout/stderr. By convention, it does sync I/O using lpOverlapped==NULL, but that has undefined behavior if the handles are overlapped pipes. FWIW: the server and client ends of a named pipe aren't quite symmetric, but I'm guessing it doesn't matter whether the child process receives a server pipe or a client pipe? The interesting thing is that writing to a broken pipe returns , but reading from one returns . Apparently this is true for both ends. (I apparently wrote for this back in June'16.) I'd probably pass the client end to the child process, because it doesn't make sense that a program can call DisconnectNamedPipe on its stdio handles. (DisconnectNamedPipe doesn't work on client handles.) I made a Rust + C++ test case demonstrating how passing overlapped handles to the child breaks:
Fascinating! Thanks for the links That perfectly explains I think what's going on here. I think I can see the fix here, so I'll work on that pronto.
Yeah, I think the fix is easy -- use non-overlapped handles for the child but overlapped handles for the parent.

Related discussion:
text: pub const EXCEPTION_MAXIMUM_PARAMETERS: usize = 15; pub const PIPE_ACCESS_INBOUND: DWORD = 0x00000001; <ins> pub const PIPE_ACCESS_OUTBOUND: DWORD = 0x00000002; </ins> pub const FILE_FLAG_FIRST_PIPE_INSTANCE: DWORD = 0x00080000; pub const FILE_FLAG_OVERLAPPED: DWORD = 0x40000000; pub const PIPE_WAIT: DWORD = 0x00000000;
Code change:
It looks like the use of overlapped I/O on stdio ports may cause some problems in Windows. When I try to shell out to using on the stderr port, the command runs successfully but hangs at the end. pointed me to this commit as the likely culprit: Here's the smallest test case I could figure out how to create: I wanted to try to come up with a minimal Node script to shell out to, as opposed to . Unfortunately, I'm not good enough at debugging npm and Node to figure out exactly what they're doing that causes the hang.
Ok I've tested this and it's a stable-to-stable regression that happened between 1.8 and 1.9. I believe the 1.9 release is indeed the first one with , the likely change which is a culprit. Tagging appropriately as such.
It looks like Rust is passing overlapped-mode pipe handles to the child process. The function returns two overlapped HANDLES. I'm not sure the overlapped mode can be changed after the fact -- maybe would work -- but I don't see it used anywhere, and I'd wonder about its use on the server handle. If the child inherits overlapped-mode handles, it would need to do async I/O to stdin/stdout/stderr. By convention, it does sync I/O using lpOverlapped==NULL, but that has undefined behavior if the handles are overlapped pipes. FWIW: the server and client ends of a named pipe aren't quite symmetric, but I'm guessing it doesn't matter whether the child process receives a server pipe or a client pipe? The interesting thing is that writing to a broken pipe returns , but reading from one returns . Apparently this is true for both ends. (I apparently wrote for this back in June'16.) I'd probably pass the client end to the child process, because it doesn't make sense that a program can call DisconnectNamedPipe on its stdio handles. (DisconnectNamedPipe doesn't work on client handles.) I made a Rust + C++ test case demonstrating how passing overlapped handles to the child breaks:
Fascinating! Thanks for the links That perfectly explains I think what's going on here. I think I can see the fix here, so I'll work on that pronto.
Yeah, I think the fix is easy -- use non-overlapped handles for the child but overlapped handles for the parent.

Related discussion:
text: .encode_wide() .chain(Some(0)) .collect::<Vec<_>>(); <ins> let mut flags = c::FILE_FLAG_FIRST_PIPE_INSTANCE | c::FILE_FLAG_OVERLAPPED; if ours_readable { flags |= c::PIPE_ACCESS_INBOUND; } else { flags |= c::PIPE_ACCESS_OUTBOUND; } </ins> let handle = c::CreateNamedPipeW(wide_name.as_ptr(), <del> c::PIPE_ACCESS_INBOUND | c::FILE_FLAG_FIRST_PIPE_INSTANCE | c::FILE_FLAG_OVERLAPPED, </del> <ins> flags, </ins> c::PIPE_TYPE_BYTE | c::PIPE_READMODE_BYTE | c::PIPE_WAIT |
Code change:
It looks like the use of overlapped I/O on stdio ports may cause some problems in Windows. When I try to shell out to using on the stderr port, the command runs successfully but hangs at the end. pointed me to this commit as the likely culprit: Here's the smallest test case I could figure out how to create: I wanted to try to come up with a minimal Node script to shell out to, as opposed to . Unfortunately, I'm not good enough at debugging npm and Node to figure out exactly what they're doing that causes the hang.
Ok I've tested this and it's a stable-to-stable regression that happened between 1.8 and 1.9. I believe the 1.9 release is indeed the first one with , the likely change which is a culprit. Tagging appropriately as such.
It looks like Rust is passing overlapped-mode pipe handles to the child process. The function returns two overlapped HANDLES. I'm not sure the overlapped mode can be changed after the fact -- maybe would work -- but I don't see it used anywhere, and I'd wonder about its use on the server handle. If the child inherits overlapped-mode handles, it would need to do async I/O to stdin/stdout/stderr. By convention, it does sync I/O using lpOverlapped==NULL, but that has undefined behavior if the handles are overlapped pipes. FWIW: the server and client ends of a named pipe aren't quite symmetric, but I'm guessing it doesn't matter whether the child process receives a server pipe or a client pipe? The interesting thing is that writing to a broken pipe returns , but reading from one returns . Apparently this is true for both ends. (I apparently wrote for this back in June'16.) I'd probably pass the client end to the child process, because it doesn't make sense that a program can call DisconnectNamedPipe on its stdio handles. (DisconnectNamedPipe doesn't work on client handles.) I made a Rust + C++ test case demonstrating how passing overlapped handles to the child breaks:
Fascinating! Thanks for the links That perfectly explains I think what's going on here. I think I can see the fix here, so I'll work on that pronto.
Yeah, I think the fix is easy -- use non-overlapped handles for the child but overlapped handles for the parent.

Related discussion:
text: } Stdio::MakePipe => { <del> let (reader, writer) = pipe::anon_pipe()?; let (ours, theirs) = if stdio_id == c::STD_INPUT_HANDLE { (writer, reader) } else { (reader, writer) }; *pipe = Some(ours); </del> <ins> let ours_readable = stdio_id != c::STD_INPUT_HANDLE; let pipes = pipe::anon_pipe(ours_readable)?; *pipe = Some(pipes.ours); </ins> cvt(unsafe { <del> c::SetHandleInformation(theirs.handle().raw(), </del> <ins> c::SetHandleInformation(pipes.theirs.handle().raw(), </ins> c::HANDLE_FLAG_INHERIT, c::HANDLE_FLAG_INHERIT) })?; <del> Ok(theirs.into_handle()) </del> <ins> Ok(pipes.theirs.into_handle()) </ins> } Stdio::Handle(ref handle) => {
Code change:
See the testcase here: I'd normally run this by a few people before filing an issue, but #rust is quiet on a Saturday night. ;-) thoughts?
Trait resolution basically doesn't know how to figure out that two types are equal in the case of "dual traits". This is one of the inevitable issues is going to hit in his Servo script bindings refactor I do wish we had a more formalized notion of type families that could be used to better instruct the compiler in these cases. was talking about this in , and I've personally found the need for a family-trait type situation more than once, both when modeling dualities and when modeling generic abstractions over sets of types like you're trying to do.
This appears to work today; E-needstest.
I don't think it works necessarily -- if you remove the bound that highlighted, you still get an error.
The example that expected to pass (and I think he is right that it should) is :
Current output:

Related discussion:
text: <ins> // check-pass use std::borrow::Borrow; trait TNode: Sized { type ConcreteElement: TElement<ConcreteNode = Self>; } trait TElement: Sized { type ConcreteNode: TNode<ConcreteElement = Self>; } trait DomTraversal<N: TNode> { type BorrowElement: Borrow<N::ConcreteElement>; } #[allow(dead_code)] fn recalc_style_at<E, D>() where E: TElement, D: DomTraversal<E::ConcreteNode>, { } fn main() {} </ins>
Code change:
See the testcase here: I'd normally run this by a few people before filing an issue, but #rust is quiet on a Saturday night. ;-) thoughts?
Trait resolution basically doesn't know how to figure out that two types are equal in the case of "dual traits". This is one of the inevitable issues is going to hit in his Servo script bindings refactor I do wish we had a more formalized notion of type families that could be used to better instruct the compiler in these cases. was talking about this in , and I've personally found the need for a family-trait type situation more than once, both when modeling dualities and when modeling generic abstractions over sets of types like you're trying to do.
This appears to work today; E-needstest.
I don't think it works necessarily -- if you remove the bound that highlighted, you still get an error.
The example that expected to pass (and I think he is right that it should) is :
Current output:

Related discussion:
text: <ins> // check-pass pub trait Test { type Item; type Bundle: From<Self::Item>; } fn fails<T>() where T: Test<Item = String>, { } fn main() {} </ins>
Code change:
See the testcase here: I'd normally run this by a few people before filing an issue, but #rust is quiet on a Saturday night. ;-) thoughts?
Trait resolution basically doesn't know how to figure out that two types are equal in the case of "dual traits". This is one of the inevitable issues is going to hit in his Servo script bindings refactor I do wish we had a more formalized notion of type families that could be used to better instruct the compiler in these cases. was talking about this in , and I've personally found the need for a family-trait type situation more than once, both when modeling dualities and when modeling generic abstractions over sets of types like you're trying to do.
This appears to work today; E-needstest.
I don't think it works necessarily -- if you remove the bound that highlighted, you still get an error.
The example that expected to pass (and I think he is right that it should) is :
Current output:

Related discussion:
text: <ins> // check-pass trait Foo { type FooT: Foo; } impl Foo for () { type FooT = (); } trait Bar<T: Foo> { type BarT: Bar<T::FooT>; } impl Bar<()> for () { type BarT = (); } #[allow(dead_code)] fn test<C: Bar<()>>() { } fn main() { } </ins>
Code change:
See the testcase here: I'd normally run this by a few people before filing an issue, but #rust is quiet on a Saturday night. ;-) thoughts?
Trait resolution basically doesn't know how to figure out that two types are equal in the case of "dual traits". This is one of the inevitable issues is going to hit in his Servo script bindings refactor I do wish we had a more formalized notion of type families that could be used to better instruct the compiler in these cases. was talking about this in , and I've personally found the need for a family-trait type situation more than once, both when modeling dualities and when modeling generic abstractions over sets of types like you're trying to do.
This appears to work today; E-needstest.
I don't think it works necessarily -- if you remove the bound that highlighted, you still get an error.
The example that expected to pass (and I think he is right that it should) is :
Current output:

Related discussion:
text: <ins> // check-pass #![feature(associated_type_bounds)] #![feature(type_alias_impl_trait)] fn main() {} trait Bar { type Assoc; } trait Thing { type Out; fn func() -> Self::Out; } struct AssocIsCopy; impl Bar for AssocIsCopy { type Assoc = u8; } impl Thing for AssocIsCopy { type Out = impl Bar<Assoc: Copy>; fn func() -> Self::Out { AssocIsCopy } } </ins>
Code change:
failure: Needs some retries here as well cc https://travis-
I'm also seeing problems when resolving with what I assume is my ISP's DNS server, but little to no problems resolving with Google's 8.8.8.8 DNS. Maybe we could configure Travis to use that? This could be (and I assume it is) a temporary malfunction.
We also should NOT be hitting the netbsd’s poor ftp server with every single build for 50MB of data.

Related discussion:
text: # Next, download the NetBSD libc and relevant header files mkdir netbsd <del> curl https://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0/amd64/binary/sets/base.tgz |  </del> <ins> # originally from: # https://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0/amd64/binary/sets/base.tgz curl https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-01-16-netbsd-base.tgz |  </ins> tar xzf - -C netbsd ./usr/include ./usr/lib ./lib <del> curl https://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0/amd64/binary/sets/comp.tgz |  </del> <ins> # originally from: # https://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0/amd64/binary/sets/comp.tgz curl https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-01-16-netbsd-comp.tgz |  </ins> tar xzf - -C netbsd ./usr/include ./usr/lib dst=/usr/local/x86_64-unknown-netbsd
Code change:
Will find more multithreading problems.
Nominating for maturity milestone 4, "well-covered".
accepted for well-covered milestone
triage bump
visiting for triage, email from 2013-09-02. Nothing to add.
--fair-sched is new in Valgrind 3.8.0, but Rust now requires Valgrind 3.8.0 for jemalloc anyway (). It also needs platform support, but while --fair-sched=yes will terminate with an error when there is no platform support, --fair-sched=try will fallback. I think we can try this now.
assigning P-low.
Triage: Given sanxiyn's comment, could implement, but not sure where a fix for this goes.

Related discussion:
text: # #   * `CFG_ENABLE_VALGRIND=1` - Run tests under valgrind #   * `VALGRIND_COMPILE=1` - Run the compiler itself under valgrind <del> #                            (may require `CFG_ENABLE_VALGRIND`) </del> <ins> #                            (requires `CFG_ENABLE_VALGRIND`) </ins> # #   * `NO_REBUILD=1` - Don't rebootstrap when testing std #                      (and possibly other crates)
Code change:
Will find more multithreading problems.
Nominating for maturity milestone 4, "well-covered".
accepted for well-covered milestone
triage bump
visiting for triage, email from 2013-09-02. Nothing to add.
--fair-sched is new in Valgrind 3.8.0, but Rust now requires Valgrind 3.8.0 for jemalloc anyway (). It also needs platform support, but while --fair-sched=yes will terminate with an error when there is no platform support, --fair-sched=try will fallback. I think we can try this now.
assigning P-low.
Triage: Given sanxiyn's comment, could implement, but not sure where a fix for this goes.

Related discussion:
text: # see https://blog.mozilla.org/jseward/2012/06/05/valgrind-now-supports-jemalloc-builds-directly/ ifdef CFG_VALGRIND CFG_VALGRIND += --error-exitcode=100  <del> --soname-synonyms=somalloc=NONE  </del> <ins> --fair-sched=try  </ins> --quiet  <ins> --soname-synonyms=somalloc=NONE  </ins> --suppressions=$(CFG_SRC_DIR)src/etc/x86.supp  $(OS_SUPP) ifdef CFG_ENABLE_HELGRIND
Code change:
iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.

Related discussion:
text: #![feature(box_into_raw_non_null)] #![feature(box_patterns)] #![feature(box_syntax)] <ins> #![feature(cfg_sanitize)] </ins> #![feature(cfg_target_has_atomic)] #![feature(coerce_unsized)] #![feature(const_generic_impls_guard)]
Code change:
iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.

Related discussion:
text: /// necessarily) at _exactly_ `MAX_REFCOUNT + 1` references. const MAX_REFCOUNT: usize = (isize::MAX) as usize; <ins> #[cfg(not(sanitize = "thread"))] macro_rules! acquire { ($x:expr) => { atomic::fence(Acquire) }; } // ThreadSanitizer does not support memory fences. To avoid false positive // reports in Arc / Weak implementation use atomic loads for synchronization // instead. #[cfg(sanitize = "thread")] macro_rules! acquire { ($x:expr) => { $x.load(Acquire) }; } </ins> /// A thread-safe reference-counting pointer. 'Arc' stands for 'Atomically /// Reference Counted'. ///
Code change:
iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.

Related discussion:
text: return Err(this); } <del> atomic::fence(Acquire); </del> <ins> acquire!(this.inner().strong); </ins> unsafe { let elem = ptr::read(&this.ptr.as_ref().data);