jiebi/CodeConvo huggingface dataset:
Code change:
cc
Are you OK with just a PR?
Sure!
Is it worth writing tests for this? I'm not really sure how it could break, but better safe than sorry I suppose...
Yeah but just some simple tests would be fine to have
ping?
Working on it right now. , Steven Allen wrote:
Thanks. I had some free time so I thought I'd check.

Related discussion:
text: Repeat{element: elt} } <ins> /// An iterator that yields nothing. #[unstable(feature="iter_empty", reason = "new addition")] pub struct Empty<T>(marker::PhantomData<T>); #[unstable(feature="iter_empty", reason = "new addition")] impl<T> Iterator for Empty<T> { type Item = T; fn next(&mut self) -> Option<T> { None } fn size_hint(&self) -> (usize, Option<usize>){ (0, Some(0)) } } #[unstable(feature="iter_empty", reason = "new addition")] impl<T> DoubleEndedIterator for Empty<T> { fn next_back(&mut self) -> Option<T> { None } } #[unstable(feature="iter_empty", reason = "new addition")] impl<T> ExactSizeIterator for Empty<T> { fn len(&self) -> usize { 0 } } // not #[derive] because that adds a Clone bound on T, // which isn't necessary. #[unstable(feature="iter_empty", reason = "new addition")] impl<T> Clone for Empty<T> { fn clone(&self) -> Empty<T> { Empty(marker::PhantomData) } } // not #[derive] because that adds a Default bound on T, // which isn't necessary. #[unstable(feature="iter_empty", reason = "new addition")] impl<T> Default for Empty<T> { fn default() -> Empty<T> { Empty(marker::PhantomData) } } /// Creates an iterator that yields nothing. #[unstable(feature="iter_empty", reason = "new addition")] pub fn empty<T>() -> Empty<T> { Empty(marker::PhantomData) } /// An iterator that yields an element exactly once. #[unstable(feature="iter_once", reason = "new addition")] pub struct Once<T> { inner: ::option::IntoIter<T> } #[unstable(feature="iter_once", reason = "new addition")] impl<T> Iterator for Once<T> { type Item = T; fn next(&mut self) -> Option<T> { self.inner.next() } fn size_hint(&self) -> (usize, Option<usize>) { self.inner.size_hint() } } #[unstable(feature="iter_once", reason = "new addition")] impl<T> DoubleEndedIterator for Once<T> { fn next_back(&mut self) -> Option<T> { self.inner.next_back() } } #[unstable(feature="iter_once", reason = "new addition")] impl<T> ExactSizeIterator for Once<T> { fn len(&self) -> usize { self.inner.len() } } /// Creates an iterator that yields an element exactly once. #[unstable(feature="iter_once", reason = "new addition")] pub fn once<T>(value: T) -> Once<T> { Once { inner: Some(value).into_iter() } } </ins> /// Functions for lexicographical ordering of sequences. /// /// Lexicographical ordering through `<`, `<=`, `>=`, `>` requires
Code change:
cc
Are you OK with just a PR?
Sure!
Is it worth writing tests for this? I'm not really sure how it could break, but better safe than sorry I suppose...
Yeah but just some simple tests would be fine to have
ping?
Working on it right now. , Steven Allen wrote:
Thanks. I had some free time so I thought I'd check.

Related discussion:
text: // Can't check len now because count consumes. } <ins> #[test] fn test_once() { let mut it = once(42); assert_eq!(it.next(), Some(42)); assert_eq!(it.next(), None); } #[test] fn test_empty() { let mut it = empty::<i32>(); assert_eq!(it.next(), None); } </ins> #[bench] fn bench_rposition(b: &mut Bencher) { let it: Vec<usize> = (0..300).collect();
Code change:
cc
Are you OK with just a PR?
Sure!
Is it worth writing tests for this? I'm not really sure how it could break, but better safe than sorry I suppose...
Yeah but just some simple tests would be fine to have
ping?
Working on it right now. , Steven Allen wrote:
Thanks. I had some free time so I thought I'd check.

Related discussion:
text: #![feature(slice_patterns)] #![feature(float_from_str_radix)] #![feature(cell_extras)] <ins> #![feature(iter_empty)] #![feature(iter_once)] </ins> extern crate core; extern crate test;
Code change:
This value has not changed in a long time, but to support sxs installation in a single dir it needs to. It should just be hashed from the value of .
So should we pipe the value through e.g. md5sum? That could be awkward on BSDs, where the hash programs have a . I think we can patch over the differences by adding a check to the configure script. Something like this: then in the Makefile we have: But if there's a simpler way then I'm all ears.

Related discussion:
text: T=$(command -v $P 2>&1) if [ $? -eq 0 ] then <del> VER0=$($P --version 2>/dev/null | head -1  |  sed -e 's/[^0-9]*([vV]?[0-9.]+[^ ]*).*/1/' ) </del> <ins> VER0=$($P --version 2>/dev/null  |  grep -o '[vV]?[0-9][0-9.][a-z0-9.-]*' | head -1 ) </ins> if [ $? -eq 0 -a "x${VER0}" != "x" ] then VER="($VER0)"
Code change:
This value has not changed in a long time, but to support sxs installation in a single dir it needs to. It should just be hashed from the value of .
So should we pipe the value through e.g. md5sum? That could be awkward on BSDs, where the hash programs have a . I think we can patch over the differences by adding a check to the configure script. Something like this: then in the Makefile we have: But if there's a simpler way then I'm all ears.

Related discussion:
text: probe_need CFG_GIT     git fi <ins> # Use `md5sum` on GNU platforms, or `md5 -q` on BSD probe CFG_MD5              md5 probe CFG_MD5SUM           md5sum if [ -n "$CFG_MD5" ] then CFG_HASH_COMMAND="$CFG_MD5 -q | head -c 8" elif [ -n "$CFG_MD5SUM" ] then CFG_HASH_COMMAND="$CFG_MD5SUM | head -c 8" else err 'could not find one of: md5 md5sum' fi putvar CFG_HASH_COMMAND </ins> probe CFG_CLANG            clang++ probe CFG_CCACHE           ccache probe CFG_GCC              gcc
Code change:
This value has not changed in a long time, but to support sxs installation in a single dir it needs to. It should just be hashed from the value of .
So should we pipe the value through e.g. md5sum? That could be awkward on BSDs, where the hash programs have a . I think we can patch over the differences by adding a check to the configure script. Something like this: then in the Makefile we have: But if there's a simpler way then I'm all ears.

Related discussion:
text: # versions (section 9) CFG_PRERELEASE_VERSION=.1 <del> CFG_FILENAME_EXTRA=4e7c5e5c </del> <ins> # Append a version-dependent hash to each library, so we can install different # versions in the same place CFG_FILENAME_EXTRA=$(shell printf '%s' $(CFG_RELEASE) | $(CFG_HASH_COMMAND)) </ins> ifeq ($(CFG_RELEASE_CHANNEL),stable) # This is the normal semver version string, e.g. "0.12.0", "0.12.0-nightly"
Code change:
The failure happens in when the output of the command used in the test contains cyrillic letters. Changing the system locale to English (USA) or replacing with something like makes this error go away. cc
Hm interesting! This probably isn't so much connected to locales so much that something in the environment/output isn't valid UTF-8. Could you get a backtrace of this failure? I would be surprised if this was coming from , but the test looks pretty innocuous, so it may very well be coming from std!
The problem may actually reside in compiletest, it captures the output of the test and then can interpret it incorrectly. If the test is run as a standalone program outside of the test suite then no panic happens and the test works as expected. I'm still investigating. Here's the backtrace, but it's not very helpful:
Aha! It looks like . I suspect it would be fine for to just use

Related discussion:
text: $(Q)$(CFG_PYTHON) $(S)src/etc/check-summary.py tmp/*.log # As above but don't bother running tidy. <del> check-notidy: cleantmptestlogs cleantestlibs all check-stage2 </del> <ins> check-notidy: check-sanitycheck cleantmptestlogs cleantestlibs all check-stage2 </ins> $(Q)$(CFG_PYTHON) $(S)src/etc/check-summary.py tmp/*.log # A slightly smaller set of tests for smoke testing. <del> check-lite: cleantestlibs cleantmptestlogs  </del> <ins> check-lite: check-sanitycheck cleantestlibs cleantmptestlogs  </ins> $(foreach crate,$(TEST_TARGET_CRATES),check-stage2-$(crate))  check-stage2-rpass check-stage2-rpass-valgrind  check-stage2-rfail check-stage2-cfail check-stage2-pfail check-stage2-rmake $(Q)$(CFG_PYTHON) $(S)src/etc/check-summary.py tmp/*.log # Only check the 'reference' tests: rpass/cfail/rfail/rmake. <del> check-ref: cleantestlibs cleantmptestlogs check-stage2-rpass check-stage2-rpass-valgrind  check-stage2-rfail check-stage2-cfail check-stage2-pfail check-stage2-rmake </del> <ins> check-ref: check-sanitycheck cleantestlibs cleantmptestlogs check-stage2-rpass  check-stage2-rpass-valgrind check-stage2-rfail check-stage2-cfail check-stage2-pfail  check-stage2-rmake </ins> $(Q)$(CFG_PYTHON) $(S)src/etc/check-summary.py tmp/*.log # Only check the docs. <del> check-docs: cleantestlibs cleantmptestlogs check-stage2-docs </del> <ins> check-docs: check-sanitycheck cleantestlibs cleantmptestlogs check-stage2-docs </ins> $(Q)$(CFG_PYTHON) $(S)src/etc/check-summary.py tmp/*.log # Some less critical tests that are not prone to breakage.
Code change:
The failure happens in when the output of the command used in the test contains cyrillic letters. Changing the system locale to English (USA) or replacing with something like makes this error go away. cc
Hm interesting! This probably isn't so much connected to locales so much that something in the environment/output isn't valid UTF-8. Could you get a backtrace of this failure? I would be surprised if this was coming from , but the test looks pretty innocuous, so it may very well be coming from std!
The problem may actually reside in compiletest, it captures the output of the test and then can interpret it incorrectly. If the test is run as a standalone program outside of the test suite then no panic happens and the test works as expected. I'm still investigating. Here's the backtrace, but it's not very helpful:
Aha! It looks like . I suspect it would be fine for to just use

Related discussion:
text: # except according to those terms. import os <ins> import subprocess </ins> import sys import functools STATUS = 0 def error_unless_permitted(env_var, message): global STATUS if not os.getenv(env_var): sys.stderr.write(message) STATUS = 1 def only_on(platforms): def decorator(func): @functools.wraps(func)
Code change:
The failure happens in when the output of the command used in the test contains cyrillic letters. Changing the system locale to English (USA) or replacing with something like makes this error go away. cc
Hm interesting! This probably isn't so much connected to locales so much that something in the environment/output isn't valid UTF-8. Could you get a backtrace of this failure? I would be surprised if this was coming from , but the test looks pretty innocuous, so it may very well be coming from std!
The problem may actually reside in compiletest, it captures the output of the test and then can interpret it incorrectly. If the test is run as a standalone program outside of the test suite then no panic happens and the test works as expected. I'm still investigating. Here's the backtrace, but it's not very helpful:
Aha! It looks like . I suspect it would be fine for to just use

Related discussion:
text: return inner return decorator <del> @only_on(('linux', 'darwin', 'freebsd', 'openbsd')) </del> <ins> @only_on(['linux', 'darwin', 'freebsd', 'openbsd']) </ins> def check_rlimit_core(): import resource soft, hard = resource.getrlimit(resource.RLIMIT_CORE)
Code change:
The failure happens in when the output of the command used in the test contains cyrillic letters. Changing the system locale to English (USA) or replacing with something like makes this error go away. cc
Hm interesting! This probably isn't so much connected to locales so much that something in the environment/output isn't valid UTF-8. Could you get a backtrace of this failure? I would be surprised if this was coming from , but the test looks pretty innocuous, so it may very well be coming from std!
The problem may actually reside in compiletest, it captures the output of the test and then can interpret it incorrectly. If the test is run as a standalone program outside of the test suite then no panic happens and the test works as expected. I'm still investigating. Here's the backtrace, but it's not very helpful:
Aha! It looks like . I suspect it would be fine for to just use

Related discussion:
text: set ALLOW_NONZERO_RLIMIT_CORE to ignore this warning """ % (soft)) <ins> @only_on(['win32']) def check_console_code_page(): if '65001' not in subprocess.check_output(['cmd', '/c', 'chcp']): sys.stderr.write('Warning: the console output code page is not UTF-8,  some tests may fail. Use `cmd /c "chcp 65001"` to setup UTF-8 code page.n') </ins> def main(): <ins> check_console_code_page() </ins> check_rlimit_core() if __name__ == '__main__':
Code change:
Running on the following code results in a stack overflow: With significantly fewer enum variants, it works. If I remove the use of , it works. This is breaking on one of my PRs (bjz/glfw-rs).
This seems to be fixed.
In my tests, you now need to have around 460+ enum variants in order to get the stack overflow. Can we assume nobody will ever have that many?
should a test still be written for this? Panicking is not correct, better would be that the number of variants is limited explicitly and that this is documented. Better still if there is no limit, of course.
In theory yeah if there's something that overflowed previously and no longer does, we should have a test for that :)
Triage: not aware of a test yet

Related discussion:
text: <ins> // Copyright 2018 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. // ensure this code doesn't stack overflow // aux-build:enum_primitive.rs #[macro_use] extern crate enum_primitive; enum_from_primitive! { pub enum Test { A1,A2,A3,A4,A5,A6, B1,B2,B3,B4,B5,B6, C1,C2,C3,C4,C5,C6, D1,D2,D3,D4,D5,D6, E1,E2,E3,E4,E5,E6, F1,F2,F3,F4,F5,F6, G1,G2,G3,G4,G5,G6, H1,H2,H3,H4,H5,H6, I1,I2,I3,I4,I5,I6, J1,J2,J3,J4,J5,J6, K1,K2,K3,K4,K5,K6, L1,L2,L3,L4,L5,L6, M1,M2,M3,M4,M5,M6, N1,N2,N3,N4,N5,N6, O1,O2,O3,O4,O5,O6, P1,P2,P3,P4,P5,P6, Q1,Q2,Q3,Q4,Q5,Q6, R1,R2,R3,R4,R5,R6, S1,S2,S3,S4,S5,S6, T1,T2,T3,T4,T5,T6, U1,U2,U3,U4,U5,U6, V1,V2,V3,V4,V5,V6, W1,W2,W3,W4,W5,W6, X1,X2,X3,X4,X5,X6, Y1,Y2,Y3,Y4,Y5,Y6, Z1,Z2,Z3,Z4,Z5,Z6, } } </ins>
Code change:
The rust book currently links to, an old beta version of rust, causing some problems using the tutorial. Example: Dining philosophers will not compile.
What's your rust version?
According to the installer: 1.0.0-beta. On windows x64.
It compiles on 1.0.0-beta.2 and up. You should update your compiler.
I believe is right here, so closing, but thanks for the report!

Related discussion:
text: If you're on Windows, please download either the [32-bit installer][win32] or the [64-bit installer][win64] and run it. <del> [win32]: https://static.rust-lang.org/dist/rust-1.0.0-beta-i686-pc-windows-gnu.msi [win64]: https://static.rust-lang.org/dist/rust-1.0.0-beta-x86_64-pc-windows-gnu.msi </del> <ins> [win32]: https://static.rust-lang.org/dist/rust-1.0.0-i686-pc-windows-gnu.msi [win64]: https://static.rust-lang.org/dist/rust-1.0.0-x86_64-pc-windows-gnu.msi </ins> ## Uninstalling
Code change:
The rust book currently links to, an old beta version of rust, causing some problems using the tutorial. Example: Dining philosophers will not compile.
What's your rust version?
According to the installer: 1.0.0-beta. On windows x64.
It compiles on 1.0.0-beta.2 and up. You should update your compiler.
I believe is right here, so closing, but thanks for the report!

Related discussion:
text: You should see the version number, commit hash, commit date and build date: ```bash <del> rustc 1.0.0-beta (9854143cb 2015-04-02) (built 2015-04-02) </del> <ins> rustc 1.0.0 (a59de37e9 2015-05-13) (built 2015-05-14) </ins> ``` If you did, Rust has been installed successfully! Congrats!
Code change:
Here's the problematic piece: On my machine usually can't delete file with "access denied" error. If I insert something like before then the test consistently passes. Supposedly we are trying to delete it too soon when it's still locked after execution.

Related discussion:
text: str::from_utf8(&child_output.stdout).unwrap(), str::from_utf8(&child_output.stderr).unwrap())); <del> fs::remove_dir_all(&child_dir).unwrap(); </del> <ins> let res = fs::remove_dir_all(&child_dir); if res.is_err() { // On Windows deleting just executed mytest.exe can fail because it's still locked std::thread::sleep_ms(1000); fs::remove_dir_all(&child_dir).unwrap(); } </ins> }
Code change:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.

Related discussion:
text: .TP fBRUST_TEST_THREADSfR The test framework Rust provides executes tests in parallel. This variable sets <del> the maximum number of threads used for this purpose. </del> <ins> the maximum number of threads used for this purpose. This setting is overridden by the --test-threads option. </ins> .TP fBRUST_TEST_NOCAPTUREfR
Code change:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.

Related discussion:
text: pub nocapture: bool, pub color: ColorConfig, pub quiet: bool, <ins> pub test_threads: Option<usize>, </ins> } impl TestOpts {
Code change:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.

Related discussion:
text: nocapture: false, color: AutoColor, quiet: false, <ins> test_threads: None, </ins> } } }
Code change:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.

Related discussion:
text: of stdout", "PATH"), getopts::optflag("", "nocapture", "don't capture stdout/stderr of each  task, allow printing directly"), <ins> getopts::optopt("", "test-threads", "Number of threads used for running tests  in parallel", "n_threads"), </ins> getopts::optflag("q", "quiet", "Display one character per test instead of one line"), getopts::optopt("", "color", "Configure coloring of output: auto   = colorize if stdout is a tty and tests are run on serially (default);
Code change:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.

Related discussion:
text: tests whose names contain the filter are run. By default, all tests are run in parallel. This can be altered with the <del> RUST_TEST_THREADS environment variable when running tests (set it to 1). </del> <ins> --test-threads flag or the RUST_TEST_THREADS environment variable when running tests (set it to 1). </ins> All tests have their standard output and standard error captured by default. This can be overridden with the --nocapture flag or setting RUST_TEST_NOCAPTURE