jiebi/CodeConvo huggingface dataset:
Code change:
Could someone change the bad title? I am not good for english.
Seems like more of a diagnostics issue. is a private constructor, but we're erroring out on type-checking before we realize this. The fix for this specific code is to replace with
Triage: this now has a different, yet still confusing, error:
That error is correct; but either way, the other error you get today is this, which while not ideal, is possibly the best we can do. I guess we could look for a method with a single parameter? But that seems hacky.
It is, but it is a common enough pattern and such a big enhancement in end user experience that I feel it'd be worth it to add it, specially when the ctor is not public. Then, the output should be: Similar output, but not quite the same cause in .
In order to implement this there's a bit of roadblock at the moment. The verification if a struct has a given method is done in , while this error is being emitted in . I believe the error is being bubbled up, but it would have to be delayed on its entirety to the type check step in order to verify wether exists. :-/ You can look for traits that have a given method (), but when I tried it with it returned an empty . We could provide with a generic suggestion about trying out , but I would much rather prefer if we could have some certainty that the method exists instead of potentially misleading the user.
Current output:
The error message seems pretty good... let's close this?
I still think that . Definitely low priority now given the other improvements on the error.
: We still need to look for and suggest it.

Related discussion:
text: <ins> error[E0423]: cannot initialize a tuple struct which contains private fields --> $DIR/suggest-box-new.rs:9:19 | LL |         wtf: Some(Box(U { |                   ^^^ | note: constructor is not visible here due to private fields --> $SRC_DIR/alloc/src/boxed.rs:LL:COL | = note: private field | = note: private field help: you might have meant to use the `new` associated function | LL |         wtf: Some(Box::new(U { |                      +++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0423`. </ins>
Code change:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in

Related discussion:
text: ```rust let captured_var = 10; <del> let closure_no_args = |&:| println!("captured_var={}", captured_var); </del> <ins> let closure_no_args = || println!("captured_var={}", captured_var); </ins> <del> let closure_args = |&: arg: i32| -> i32 { </del> <ins> let closure_args = |arg: i32| -> i32 { </ins> println!("captured_var={}, arg={}", captured_var, arg); arg // Note lack of semicolon after 'arg' };
Code change:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in

Related discussion:
text: } } (Ok(const_int(a)), Ok(const_int(b))) => { <del> let is_a_min_value = |&:| { </del> <ins> let is_a_min_value = || { </ins> let int_ty = match ty::expr_ty_opt(tcx, e).map(|ty| &ty.sty) { Some(&ty::ty_int(int_ty)) => int_ty, _ => return false
Code change:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in

Related discussion:
text: scope: region::CodeExtent, depth: uint) { <del> let origin = |&:| infer::SubregionOrigin::SafeDestructor(span); </del> <ins> let origin = || infer::SubregionOrigin::SafeDestructor(span); </ins> let mut walker = ty_root.walk(); let opt_phantom_data_def_id = rcx.tcx().lang_items.phantom_data();
Code change:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in

Related discussion:
text: // file descriptor. Otherwise, the first file descriptor opened // up in the child would be numbered as one of the stdio file // descriptors, which is likely to wreak havoc. <del> let setup = |&: src: Option<AnonPipe>, dst: c_int| { </del> <ins> let setup = |src: Option<AnonPipe>, dst: c_int| { </ins> let src = match src { None => { let flags = if dst == libc::STDIN_FILENO {
Code change:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in

Related discussion:
text: // Similarly to unix, we don't actually leave holes for the stdio file // descriptors, but rather open up /dev/null equivalents. These // equivalents are drawn from libuv's windows process spawning. <del> let set_fd = |&: fd: &Option<AnonPipe>, slot: &mut HANDLE, </del> <ins> let set_fd = |fd: &Option<AnonPipe>, slot: &mut HANDLE, </ins> is_stdin: bool| { match *fd { None => {
Code change:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in

Related discussion:
text: <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. // Test that we generate obsolete syntax errors around usages of closure kinds: `|:|`, `|&:|` and // `|&mut:|`. fn main() { let a = |:| {};  //~ ERROR obsolete syntax: `:`, `&mut:`, or `&:` let a = |&:| {};  //~ ERROR obsolete syntax: `:`, `&mut:`, or `&:` let a = |&mut:| {};  //~ ERROR obsolete syntax: `:`, `&mut:`, or `&:` } </ins>
Code change:
compiles without any error. Notably this isn't a regression from I noticed it because has a public field that has had no stability attribute from far before . However, that PR did pick up some structs with missing stability attributes, I'm unsure of the exact circumstances when fields will get the errors or when they will not.
As points out in this isn't a bug; I didn't realise that stability propagation literally just ignores , meaning is due to the on . Closing.

Related discussion:
text: f: F, /// The current internal state to be passed to the closure next. <ins> #[unstable(feature = "core")] </ins> pub state: St, }
Code change:
compiles without any error. Notably this isn't a regression from I noticed it because has a public field that has had no stability attribute from far before . However, that PR did pick up some structs with missing stability attributes, I'm unsure of the exact circumstances when fields will get the errors or when they will not.
As points out in this isn't a bug; I didn't realise that stability propagation literally just ignores , meaning is due to the on . Closing.

Related discussion:
text: pub struct Unfold<St, F> { f: F, /// Internal state that will be passed to the closure on the next iteration <ins> #[unstable(feature = "core")] </ins> pub state: St, }
Code change:
Here's a minimal example which results in a runtime error: I'd expect that format string to work (precision=0, so no digits after the decimal point), but here's what I get with RUSTBACKTRACE=1: Ubuntu 14.10 / 64-bit rustc 1.0.0-nightly ( 2015-03-05) (built 2015-03-06) binary: rustc commit-hash: commit-date: 2015-03-05 build-date: 2015-03-06 host: x8664-unknown-linux-gnu release: 1.0.0-nightly
It also happens with 9.5 but not with 9.499. The formatting routine tries to round, but fails to handle the case that rounding extends the digits.
Just to clarify: this is not actually an ICE because the program is panicking, not the compiler. So, compilation is fine, but the program fails at runtime
This issue should be closed as it's now fixed.
Yay!

Related discussion:
text: if i < 0 || buf[i as usize] == b'-' || buf[i as usize] == b'+' { <del> for j in (i as usize + 1..end).rev() { </del> <ins> for j in ((i + 1) as usize..end).rev() { </ins> buf[j + 1] = buf[j]; } buf[(i + 1) as usize] = value2ascii(1);
Code change:
Here's a minimal example which results in a runtime error: I'd expect that format string to work (precision=0, so no digits after the decimal point), but here's what I get with RUSTBACKTRACE=1: Ubuntu 14.10 / 64-bit rustc 1.0.0-nightly ( 2015-03-05) (built 2015-03-06) binary: rustc commit-hash: commit-date: 2015-03-05 build-date: 2015-03-06 host: x8664-unknown-linux-gnu release: 1.0.0-nightly
It also happens with 9.5 but not with 9.499. The formatting routine tries to round, but fails to handle the case that rounding extends the digits.
Just to clarify: this is not actually an ICE because the program is panicking, not the compiler. So, compilation is fine, but the program fails at runtime
This issue should be closed as it's now fixed.
Yay!

Related discussion:
text: <ins> // 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. #[test] fn test_format_float() { assert!("1" == format!("{:.0}", 1.0f64)); assert!("9" == format!("{:.0}", 9.4f64)); assert!("10" == format!("{:.0}", 9.9f64)); assert!("9.9" == format!("{:.1}", 9.85f64)); } </ins>
Code change:
I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.

Related discussion:
text: // empty. } <ins> unsafe impl Send for .. { } </ins> impl<T> !Send for *const T { } impl<T> !Send for *mut T { } impl !Send for Managed { }
Code change:
I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.

Related discussion:
text: // Empty } <ins> unsafe impl Sync for .. { } </ins> impl<T> !Sync for *const T { } impl<T> !Sync for *mut T { } impl !Sync for Managed { }
Code change:
I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.

Related discussion:
text: pub fn trait_has_default_impl(tcx: &ctxt, trait_def_id: DefId) -> bool { populate_implementations_for_trait_if_necessary(tcx, trait_def_id); <del> match tcx.lang_items.to_builtin_kind(trait_def_id) { Some(BoundSend) | Some(BoundSync) => true, _ => tcx.traits_with_default_impls.borrow().contains_key(&trait_def_id), } </del> <ins> tcx.traits_with_default_impls.borrow().contains_key(&trait_def_id) </ins> } /// Records a trait-to-implementation mapping.
Code change:
I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.

Related discussion:
text: } } <ins> ast::ItemDefaultImpl(..) => { self.gate_feature("optin_builtin_traits", i.span, "default trait implementations are experimental  and possibly buggy"); } </ins> ast::ItemImpl(_, polarity, _, _, _, _) => { match polarity { ast::ImplPolarity::Negative => {
Code change:
I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.

Related discussion:
text: impl MyTrait for .. {} //~^ ERROR conflicting implementations for trait `MyTrait` <ins> trait MySafeTrait: MarkerTrait {} unsafe impl MySafeTrait for .. {} //~^ ERROR implementing the trait `MySafeTrait` is not unsafe unsafe trait MyUnsafeTrait: MarkerTrait {} impl MyUnsafeTrait for .. {} //~^ ERROR the trait `MyUnsafeTrait` requires an `unsafe impl` declaration </ins> fn main() {}
Code change:
I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.

Related discussion:
text: // option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(optin_builtin_traits)] </ins> pub mod bar { use std::marker;
Code change:
The references states that is a logical right shift, however it seems that it behaves like an arithmetic right shift for signed integers. For instance the following snippet prints : A logical right shift should produce (assuming 2's complement representation which I think rust guarantees?). In the same spirit the reference does not say if shifting outside the range of an integer is defined. From my quick test it doesn't appear to be: This prints garbage on my computer and on the playpen, so I assume it's UB or at least UV (it doesn't trigger the overflow check in debug builds though, maybe it should?) On a similar topic the reference also states that the following behaviours are safe: Unsigned integer overflow (well-defined as wrapping) Signed integer overflow (well-defined as two's complement representation wrapping) I believe that's not true anymore.
I see that checking for bitshift overflows is going to be implemented in so it seems to confirm that it's UB (UV?) for now.
see PR for the checks. We can go either way on the issue of whether overflow is UB or UV or neither. (That is, it is easy to adapt the PR accordingly; just a matter of deciding, and perhaps measuring the impact on code size, maybe.)
what's the process by which we decide that? I'd like to knock this issue out.
heh, I already made an "executive decision" (though admittedly it was one that was already in favor of), of making overflow panic when checks are on, and when the checks are off, we forcibly mask the RHS to ensure that we do not encounter weirdness such as that documented in and . (Though I still need to put in tests for that fallback behavior.)
That sounds very reasonable, thanks. Right shifts of signed values will remain arithmetic though, right? It's probably what most people will expect since that's how it's done in C/C++ and we'd have to simple way of doing arithmetic shifting otherwise.
right-shift of signed values are still arithmetic shifts, but that is independent of the overflow checking (which is based solely on the value of the right-hand-side compared to the bitwidth of the type of the left-hand-side)
Okay, that makes sense. I wanted to make sure that was the intended behaviour since the reference seems to say otherwise. Thank you!
oh I see; yes that part of the reference has probably been incorrect for a long time.

Related discussion:
text: * Sending signals * Accessing/modifying the file system * Unsigned integer overflow (well-defined as wrapping) <del> * Signed integer overflow (well-defined as two's complement representation </del> <ins> * Signed integer overflow (well-defined as two’s complement representation </ins> wrapping) #### Diverging functions
Code change:
The references states that is a logical right shift, however it seems that it behaves like an arithmetic right shift for signed integers. For instance the following snippet prints : A logical right shift should produce (assuming 2's complement representation which I think rust guarantees?). In the same spirit the reference does not say if shifting outside the range of an integer is defined. From my quick test it doesn't appear to be: This prints garbage on my computer and on the playpen, so I assume it's UB or at least UV (it doesn't trigger the overflow check in debug builds though, maybe it should?) On a similar topic the reference also states that the following behaviours are safe: Unsigned integer overflow (well-defined as wrapping) Signed integer overflow (well-defined as two's complement representation wrapping) I believe that's not true anymore.
I see that checking for bitshift overflows is going to be implemented in so it seems to confirm that it's UB (UV?) for now.
see PR for the checks. We can go either way on the issue of whether overflow is UB or UV or neither. (That is, it is easy to adapt the PR accordingly; just a matter of deciding, and perhaps measuring the impact on code size, maybe.)
what's the process by which we decide that? I'd like to knock this issue out.
heh, I already made an "executive decision" (though admittedly it was one that was already in favor of), of making overflow panic when checks are on, and when the checks are off, we forcibly mask the RHS to ensure that we do not encounter weirdness such as that documented in and . (Though I still need to put in tests for that fallback behavior.)
That sounds very reasonable, thanks. Right shifts of signed values will remain arithmetic though, right? It's probably what most people will expect since that's how it's done in C/C++ and we'd have to simple way of doing arithmetic shifting otherwise.
right-shift of signed values are still arithmetic shifts, but that is independent of the overflow checking (which is based solely on the value of the right-hand-side compared to the bitwidth of the type of the left-hand-side)
Okay, that makes sense. I wanted to make sure that was the intended behaviour since the reference seems to say otherwise. Thank you!
oh I see; yes that part of the reference has probably been incorrect for a long time.

Related discussion:
text: : Exclusive or. Calls the `bitxor` method of the `std::ops::BitXor` trait. * `<<` <del> : Logical left shift. </del> <ins> : Left shift. </ins> Calls the `shl` method of the `std::ops::Shl` trait. * `>>` <del> : Logical right shift. </del> <ins> : Right shift. </ins> Calls the `shr` method of the `std::ops::Shr` trait. #### Lazy boolean operators
Code change:
The following panics: The following works: Apologies in advance if this is intended behavior.
I have found that it also works when using:
This will be fixed by

Related discussion:
text: #[stable(feature = "rust1", since = "1.0.0")] pub fn create_dir_all<P: AsPath + ?Sized>(path: &P) -> io::Result<()> { let path = path.as_path(); <del> if path.is_dir() { return Ok(()) } </del> <ins> if path == Path::new("") || path.is_dir() { return Ok(()) } </ins> if let Some(p) = path.parent() { try!(create_dir_all(p)) } create_dir(path) }
Code change:
The following panics: The following works: Apologies in advance if this is intended behavior.
I have found that it also works when using:
This will be fixed by

Related discussion:
text: <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::env; use std::fs::{self, TempDir}; fn main() { let td = TempDir::new("create-dir-all-bare").unwrap(); env::set_current_dir(td.path()).unwrap(); fs::create_dir_all("create-dir-all-bare").unwrap(); } </ins>
Code change:
For clarity, the second call to ends up using the impl on . cc I had concerns about this kind of thing when these impls were being introduced but I thought I convinced myself that this kind of thing couldn't happen. Did something change in the way we designed these impls since then?
Possible solutions are to either remove the impl for or update to prevent it from invoking . Seems to me like the second is the better approach.
I believe the reason for the was because it was considered a good thing to require callers to explicitly pass references. I think we've actually gone back and forth on that a few times. Are we committed now to allowing callers to just say ?

Related discussion:
text: /// ``` #[macro_export] macro_rules! write { <del> ($dst:expr, $($arg:tt)*) => ((&mut *$dst).write_fmt(format_args!($($arg)*))) </del> <ins> ($dst:expr, $($arg:tt)*) => ($dst.write_fmt(format_args!($($arg)*))) </ins> } /// Equivalent to the `write!` macro, except that a newline is appended after
Code change:
See as an example, goes nowhere
Another example: The type is public in this case, but it's explicitly hidden.
Yeah, there's a lot of these.
For , it could be related to re-exported signatures. The same method in doesn't have this issue: Also, is it a bug that you can have private items in a public signature's ? Or private items in an impl for a public type? cc
I wonder if rustdoc should be resolving qualified paths that it encounters.
Is there still some unresolved issue here?
Still a thing; for example, tries to link to types in rand, but the doc link is broken. (That link goes to 1.19.0, but it's still there in today's nightly docs.) If i were to guess, it probably has to do with rustdoc seeing types that are in dependencies of std, but aren't being documented alongside it.
Wrote a fix for it. Will make the PR tomorrow or after tomorrow.
This issue was actually fixed by The issue i actually referenced in that PR was apparently a duplicate of this one.

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. #![crate_name = "foo"] #[doc(hidden)] pub trait Foo {} trait Dark {} pub trait Bam {} pub struct Bar; struct Hidden; // @!has foo/struct.Bar.html '//*[@id="impl-Foo"]' 'impl Foo for Bar' impl Foo for Bar {} // @!has foo/struct.Bar.html '//*[@id="impl-Dark"]' 'impl Dark for Bar' impl Dark for Bar {} // @has foo/struct.Bar.html '//*[@id="impl-Bam"]' 'impl Bam for Bar' // @has foo/trait.Bam.html '//*[@id="implementors-list"]' 'impl Bam for Bar' impl Bam for Bar {} // @!has foo/trait.Bam.html '//*[@id="implementors-list"]' 'impl Bam for Hidden' impl Bam for Hidden {} </ins>