jiebi/CodeConvo huggingface dataset:
Code change:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.

Related discussion:
text: } impl<T:Copy> Cell<T> { <del> /// Creates a new `Cell` containing the given value. /// /// # Examples /// /// ``` /// use std::cell::Cell; /// /// let c = Cell::new(5); /// ``` #[stable(feature = "rust1", since = "1.0.0")] #[inline] pub const fn new(value: T) -> Cell<T> { Cell { value: UnsafeCell::new(value), } } </del> /// Returns a copy of the contained value. /// /// # Examples
Code change:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.

Related discussion:
text: unsafe{ *self.value.get() } } <del> /// Sets the contained value. /// /// # Examples /// /// ``` /// use std::cell::Cell; /// /// let c = Cell::new(5); /// /// c.set(10); /// ``` #[inline] #[stable(feature = "rust1", since = "1.0.0")] pub fn set(&self, value: T) { unsafe { *self.value.get() = value; } } </del> /// Returns a reference to the underlying `UnsafeCell`. /// /// # Examples
Code change:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.

Related discussion:
text: } #[test] <ins> fn cell_set() { let cell = Cell::new(10); cell.set(20); assert_eq!(20, cell.get()); let cell = Cell::new("Hello".to_owned()); cell.set("World".to_owned()); assert_eq!("World".to_owned(), cell.into_inner()); } #[test] fn cell_replace() { let cell = Cell::new(10); assert_eq!(10, cell.replace(20)); assert_eq!(20, cell.get()); let cell = Cell::new("Hello".to_owned()); assert_eq!("Hello".to_owned(), cell.replace("World".to_owned())); assert_eq!("World".to_owned(), cell.into_inner()); } #[test] fn cell_into_inner() { let cell = Cell::new(10); assert_eq!(10, cell.into_inner()); let cell = Cell::new("Hello world".to_owned()); assert_eq!("Hello world".to_owned(), cell.into_inner()); } #[test] </ins> fn refcell_default() { let cell: RefCell<u64> = Default::default(); assert_eq!(0, *cell.borrow());
Code change:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.

Related discussion:
text: #![feature(ordering_chaining)] #![feature(result_unwrap_or_default)] #![feature(ptr_unaligned)] <ins> #![feature(move_cell)] </ins> extern crate core; extern crate test;
Code change:
Hi, at this point, rust nightly pretty much builds out of the box (assuming you have an already built beta rustc compiler) on Solaris for x86_64. However, it doesn't (yet) build for sparcv9. I will provide a pull request shortly that adds the final, missing piece to support sparcv9 / Solaris.

Related discussion:
text: ostype += 'abi64' elif cputype in {'powerpc', 'ppc', 'ppc64'}: cputype = 'powerpc' <ins> elif cputype == 'sparcv9': pass </ins> elif cputype in {'amd64', 'x86_64', 'x86-64', 'x64'}: cputype = 'x86_64' else:
Code change:
Hi, at this point, rust nightly pretty much builds out of the box (assuming you have an already built beta rustc compiler) on Solaris for x86_64. However, it doesn't (yet) build for sparcv9. I will provide a pull request shortly that adds the final, missing piece to support sparcv9 / Solaris.

Related discussion:
text: // compiler-rt's build system already cfg.flag("-fno-builtin"); cfg.flag("-fvisibility=hidden"); <del> cfg.flag("-fomit-frame-pointer"); </del> <ins> // Accepted practice on Solaris is to never omit frame pointer so that // system observability tools work as expected.  In addition, at least // on Solaris, -fomit-frame-pointer on sparcv9 appears to generate // references to data outside of the current stack frame.  A search of // the gcc bug database provides a variety of issues surrounding // -fomit-frame-pointer on non-x86 platforms. if !target.contains("solaris") && !target.contains("sparc") { cfg.flag("-fomit-frame-pointer"); } </ins> cfg.flag("-ffreestanding"); cfg.define("VISIBILITY_HIDDEN", None); }
Code change:
Hi, at this point, rust nightly pretty much builds out of the box (assuming you have an already built beta rustc compiler) on Solaris for x86_64. However, it doesn't (yet) build for sparcv9. I will provide a pull request shortly that adds the final, missing piece to support sparcv9 / Solaris.

Related discussion:
text: ("armv7s-apple-ios", armv7s_apple_ios), ("x86_64-sun-solaris", x86_64_sun_solaris), <ins> ("sparcv9-sun-solaris", sparcv9_sun_solaris), </ins> ("x86_64-pc-windows-gnu", x86_64_pc_windows_gnu), ("i686-pc-windows-gnu", i686_pc_windows_gnu),
Code change:
Hi, at this point, rust nightly pretty much builds out of the box (assuming you have an already built beta rustc compiler) on Solaris for x86_64. However, it doesn't (yet) build for sparcv9. I will provide a pull request shortly that adds the final, missing piece to support sparcv9 / Solaris.

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. use target::{Target, TargetResult}; pub fn target() -> TargetResult { let mut base = super::solaris_base::opts(); base.pre_link_args.push("-m64".to_string()); // llvm calls this "v9" base.cpu = "v9".to_string(); base.max_atomic_width = Some(64); Ok(Target { llvm_target: "sparcv9-sun-solaris".to_string(), target_endian: "big".to_string(), target_pointer_width: "64".to_string(), data_layout: "E-m:e-i64:64-n32:64-S128".to_string(), // Use "sparc64" instead of "sparcv9" here, since the former is already // used widely in the source base.  If we ever needed ABI // differentiation from the sparc64, we could, but that would probably // just be confusing. arch: "sparc64".to_string(), target_os: "solaris".to_string(), target_env: "".to_string(), target_vendor: "sun".to_string(), options: base, }) } </ins>
Code change:
is this code: yielding:
. I don't know why we do this, the "else" part of "if" or "if-let" is an arbitrary expression: This seems simpler, less error prone and it won't hit arbitrary limitations specific to guards.
The RFC states: This doesn't feel like a compelling reason, particularly since the desugaring is not otherwise user visible. I would call this a bug.
triage: P-medium
This is a great mentoring bug! I'm going to write up some very quick pointers for now. Please reach out for more details. In short, the code that needs to be changed is in the "HIR lowering", which converts from the AST (what the user wrote) to the compiler's internal HIR (also an abstract syntax tree, but somewhat desugared). The code in question is in , specifically right . There is also some more logic. You'll want to change how it is desugaring along the lines that suggested .
I'm interested in taking this bug.
Hello I'm new to open source and Rust project. I wanted to contribute to the project. May I work on this bug?
Sure thing! Let us know how far you get with We're also on IRC.
I'll yield to you -- good luck!
If IfLet expression is desugared to the one shown in desugar_test() then it works as suggested by I have also reproduced the bug after desugaring the expression.

Related discussion:
text: // //   match <sub_expr> { //     <pat> => <body>, <del> //     [_ if <else_opt_if_cond> => <else_opt_if_body>,] </del> //     _ => [<else_opt> | ()] //   }
Code change:
is this code: yielding:
. I don't know why we do this, the "else" part of "if" or "if-let" is an arbitrary expression: This seems simpler, less error prone and it won't hit arbitrary limitations specific to guards.
The RFC states: This doesn't feel like a compelling reason, particularly since the desugaring is not otherwise user visible. I would call this a bug.
triage: P-medium
This is a great mentoring bug! I'm going to write up some very quick pointers for now. Please reach out for more details. In short, the code that needs to be changed is in the "HIR lowering", which converts from the AST (what the user wrote) to the compiler's internal HIR (also an abstract syntax tree, but somewhat desugared). The code in question is in , specifically right . There is also some more logic. You'll want to change how it is desugaring along the lines that suggested .
I'm interested in taking this bug.
Hello I'm new to open source and Rust project. I wanted to contribute to the project. May I work on this bug?
Sure thing! Let us know how far you get with We're also on IRC.
I'll yield to you -- good luck!
If IfLet expression is desugared to the one shown in desugar_test() then it works as suggested by I have also reproduced the bug after desugaring the expression.

Related discussion:
text: <ins> // Copyright 2017 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 Foo; impl Foo { fn bar(&mut self) -> bool { true } } fn error(foo: &mut Foo) { if let Some(_) = Some(true) { } else if foo.bar() {} } fn ok(foo: &mut Foo) { if let Some(_) = Some(true) { } else { if foo.bar() {} } } fn main() {} </ins>
Code change:
fails on emscripten with the following error message: Thus the test is currently ignored on emscripten. Note: it may be that the failure occurs only on when the test is compiled with optimizations. Note: this happens when using LLVM 4.0 (this issue was opened now to get an issue number to reference).

Related discussion:
text: # 32/64-bit MinGW builds. # <del> # The MinGW builds unfortunately have to both download a custom toolchain and # avoid the one installed by AppVeyor by default. Interestingly, though, for # different reasons! </del> <ins> # We are using MinGW with posix threads since LLVM does not compile with # the win32 threads version due to missing support for C++'s std::thread. </ins> # <del> # For 32-bit the installed gcc toolchain on AppVeyor uses the pthread # threading model. This is unfortunately not what we want, and if we compile # with it then there's lots of link errors in the standard library (undefined # references to pthread symbols). # # For 64-bit the installed gcc toolchain is currently 5.3.0 which # unfortunately segfaults on Windows with --enable-llvm-assertions (segfaults # in LLVM). See rust-lang/rust#28445 for more information, but to work around # this we go back in time to 4.9.2 specifically. </del> <ins> # Instead of relying on the MinGW version installed on appveryor we download # and install one ourselves so we won't be surprised by changes to appveyor's # build image. </ins> # # Finally, note that the downloads below are all in the `rust-lang-ci` S3 # bucket, but they cleraly didn't originate there! The downloads originally # came from the mingw-w64 SourceForge download site. Unfortunately # SourceForge is notoriously flaky, so we mirror it on our own infrastructure. <del> # # And as a final point of note, the 32-bit MinGW build using the makefiles do # *not* use debug assertions and llvm assertions. This is because they take # too long on appveyor and this is tested by rustbuild below. </del> - MSYS_BITS: 32 RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-ninja SCRIPT: python x.py test MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z </ins> MINGW_DIR: mingw32 - MSYS_BITS: 64 SCRIPT: python x.py test RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-ninja MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z </ins> MINGW_DIR: mingw64 # 32/64 bit MSVC and GNU deployment
Code change:
fails on emscripten with the following error message: Thus the test is currently ignored on emscripten. Note: it may be that the failure occurs only on when the test is compiled with optimizations. Note: this happens when using LLVM 4.0 (this issue was opened now to get an issue number to reference).

Related discussion:
text: RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-extended --enable-ninja SCRIPT: python x.py dist MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z </ins> MINGW_DIR: mingw32 DEPLOY: 1 - MSYS_BITS: 64 SCRIPT: python x.py dist RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-extended --enable-ninja MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z </ins> MINGW_DIR: mingw64 DEPLOY: 1
Code change:
fails on emscripten with the following error message: Thus the test is currently ignored on emscripten. Note: it may be that the failure occurs only on when the test is compiled with optimizations. Note: this happens when using LLVM 4.0 (this issue was opened now to get an issue number to reference).

Related discussion:
text: COPY build-emscripten.sh /tmp/ RUN ./build-emscripten.sh ENV PATH=$PATH:/tmp/emsdk_portable <del> ENV PATH=$PATH:/tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin </del> <ins> ENV PATH=$PATH:/tmp/emsdk_portable/clang/tag-e1.37.10/build_tag-e1.37.10_32/bin </ins> ENV PATH=$PATH:/tmp/emsdk_portable/node/4.1.1_32bit/bin <del> ENV PATH=$PATH:/tmp/emsdk_portable/emscripten/tag-1.37.1 ENV EMSCRIPTEN=/tmp/emsdk_portable/emscripten/tag-1.37.1 </del> <ins> ENV PATH=$PATH:/tmp/emsdk_portable/emscripten/tag-1.37.10 ENV EMSCRIPTEN=/tmp/emsdk_portable/emscripten/tag-1.37.10 </ins> ENV RUST_CONFIGURE_ARGS --target=asmjs-unknown-emscripten
Code change:
fails on emscripten with the following error message: Thus the test is currently ignored on emscripten. Note: it may be that the failure occurs only on when the test is compiled with optimizations. Note: this happens when using LLVM 4.0 (this issue was opened now to get an issue number to reference).

Related discussion:
text: source emsdk_portable/emsdk_env.sh hide_output emsdk update <del> hide_output emsdk install --build=Release sdk-tag-1.37.1-32bit hide_output emsdk activate --build=Release sdk-tag-1.37.1-32bit </del> <ins> hide_output emsdk install --build=Release sdk-tag-1.37.10-32bit hide_output emsdk activate --build=Release sdk-tag-1.37.10-32bit </ins>
Code change:
fails on emscripten with the following error message: Thus the test is currently ignored on emscripten. Note: it may be that the failure occurs only on when the test is compiled with optimizations. Note: this happens when using LLVM 4.0 (this issue was opened now to get an issue number to reference).

Related discussion:
text: <del> Subproject commit d30da544a8afc5d78391dee270bdf40e74a215d3 </del> <ins> Subproject commit c8a8767c56ad3d3f4eb45c87b95026936fb9aa35 </ins>
Code change:
fails on emscripten with the following error message: Thus the test is currently ignored on emscripten. Note: it may be that the failure occurs only on when the test is compiled with optimizations. Note: this happens when using LLVM 4.0 (this issue was opened now to get an issue number to reference).

Related discussion:
text: } if target.contains("arm") && !target.contains("ios") { <ins> // (At least) udivsi3.S is broken for Thumb 1 which our gcc uses by // default, we don't want Thumb 2 since it isn't supported on some // devices, so disable thumb entirely. // Upstream bug: https://bugs.llvm.org/show_bug.cgi?id=32492 cfg.define("__ARM_ARCH_ISA_THUMB", Some("0")); </ins> sources.extend(&["arm/aeabi_cdcmp.S", "arm/aeabi_cdcmpeq_check_nan.c", "arm/aeabi_cfcmp.S",
Code change:
fails on emscripten with the following error message: Thus the test is currently ignored on emscripten. Note: it may be that the failure occurs only on when the test is compiled with optimizations. Note: this happens when using LLVM 4.0 (this issue was opened now to get an issue number to reference).

Related discussion:
text: <del> Subproject commit 2e951c3ae354bcbd2e50b30798e232949a926b75 </del> <ins> Subproject commit a884d21cc5f0b23a1693d1e872fd8998a4fdd17f </ins>