jiebi/CodeConvo huggingface dataset:
Code change:
Right now, The Unstable Book is just a list of unstable lang/lib features. There are other things like compiler flags which are also considered unstable that should be documented in The Unstable Book. This requires adjusting a bit to accommodate other sections. Right now I'm thinking that all sections (features, flags, etc) will live in their own subdirectory.
Relevant thread:
Reminder for future self: remove this hack
This may not be the issue, but there are a number of stable features that are actually just "stable", like target specs and llvm plugins, where we don't even try to maintain stability. It would be nice to have a discussion of those somewhere.
I'm waiting on to merge before I work on this.
Copying text from
This was partially completed in
In suggests that we should keep the library features minimal; I agree. They should exist, so you can see everything that's unstable, but there's no reason to duplicate their docs.
regarding unsafe command line options, one can see them via . it looks like the options are all defined . they seem to all be exposed on . seems like we should be able to autogenerate all the unsafe command line options pages like we do for the other unstable book sections (via )
Triage: we now have , but it doesn't talk about .
I just saw that the Unstable Book already contains a list of unstable compiler flags which I guess means that this issue is already solved right? Maybe we should create a separate issue for the missing -Z description in and close this one? Maybe also create a separate issue to autogenerate the unsafe nightly commands for the Unstable Book. That way we can keep the tasks that need to be done clearly isolated. If you agree I can create these new issues with a nice description of what needs to be done!
Yes! Alternatively, if this is something you'd like to send a PR for, we can just keep this issue open and use that PR to close it. I would prefer not to, I don't think this is the job for the unstable book.
I'll go ahead and do that then! I can understand that you have this view! I do not really have much of a view myself on this, though I do think that we should keep duplication between the docs and other docs to a minimum (or to keep documentation duplication to a minimum in general because its easier to maintain). The docs are probably a better place to document this. However, this does lead me to the following question: Currently, there is already a in the unstable book. For example the flag. I think we should either try to complete this section or remove/move it to the docs all-together. What is your opinion on this?
Moving it to the docs seems appropriate to me!
I created an issue for this here: Then we can use this issue for adding -Z to the compiler flags section!

Related discussion:
text: } let message = "Usage: rustc [OPTIONS] INPUT"; let nightly_help = if nightly_options::is_nightly_build() { <del> "n    -Z help             Print internal options for debugging rustc" </del> <ins> "n    -Z help             Print unstable compiler options" </ins> } else { "" };
Code change:
Right now, The Unstable Book is just a list of unstable lang/lib features. There are other things like compiler flags which are also considered unstable that should be documented in The Unstable Book. This requires adjusting a bit to accommodate other sections. Right now I'm thinking that all sections (features, flags, etc) will live in their own subdirectory.
Relevant thread:
Reminder for future self: remove this hack
This may not be the issue, but there are a number of stable features that are actually just "stable", like target specs and llvm plugins, where we don't even try to maintain stability. It would be nice to have a discussion of those somewhere.
I'm waiting on to merge before I work on this.
Copying text from
This was partially completed in
In suggests that we should keep the library features minimal; I agree. They should exist, so you can see everything that's unstable, but there's no reason to duplicate their docs.
regarding unsafe command line options, one can see them via . it looks like the options are all defined . they seem to all be exposed on . seems like we should be able to autogenerate all the unsafe command line options pages like we do for the other unstable book sections (via )
Triage: we now have , but it doesn't talk about .
I just saw that the Unstable Book already contains a list of unstable compiler flags which I guess means that this issue is already solved right? Maybe we should create a separate issue for the missing -Z description in and close this one? Maybe also create a separate issue to autogenerate the unsafe nightly commands for the Unstable Book. That way we can keep the tasks that need to be done clearly isolated. If you agree I can create these new issues with a nice description of what needs to be done!
Yes! Alternatively, if this is something you'd like to send a PR for, we can just keep this issue open and use that PR to close it. I would prefer not to, I don't think this is the job for the unstable book.
I'll go ahead and do that then! I can understand that you have this view! I do not really have much of a view myself on this, though I do think that we should keep duplication between the docs and other docs to a minimum (or to keep documentation duplication to a minimum in general because its easier to maintain). The docs are probably a better place to document this. However, this does lead me to the following question: Currently, there is already a in the unstable book. For example the flag. I think we should either try to complete this section or remove/move it to the docs all-together. What is your opinion on this?
Moving it to the docs seems appropriate to me!
I created an issue for this here: Then we can use this issue for adding -Z to the compiler flags section!

Related discussion:
text: } fn describe_debug_flags() { <del> println!("nAvailable debug options:n"); </del> <ins> println!("nAvailable options:n"); </ins> print_flag_list("-Z", config::DB_OPTIONS); }
Code change:
Specifically, there are snakecase names that cannot be converted into CamelCase (as interpreted by this lint) without losing semantics: anything that contains two numbers with a separator. E.g does not have a CamelCase equivalent that's accepted by the lint but is not confusable with the conversion result of . Originally discovered in

Related discussion:
text: impl NonCamelCaseTypes { fn check_case(&self, cx: &LateContext, sort: &str, name: ast::Name, span: Span) { <ins> fn char_has_case(c: char) -> bool { c.is_lowercase() || c.is_uppercase() } </ins> fn is_camel_case(name: ast::Name) -> bool { let name = name.as_str(); if name.is_empty() {
Code change:
Specifically, there are snakecase names that cannot be converted into CamelCase (as interpreted by this lint) without losing semantics: anything that contains two numbers with a separator. E.g does not have a CamelCase equivalent that's accepted by the lint but is not confusable with the conversion result of . Originally discovered in

Related discussion:
text: // start with a non-lowercase letter rather than non-uppercase // ones (some scripts don't have a concept of upper/lowercase) <del> !name.is_empty() && !name.chars().next().unwrap().is_lowercase() && !name.contains('_') </del> <ins> !name.is_empty() && !name.chars().next().unwrap().is_lowercase() && !name.contains("__") && !name.chars().collect::<Vec<_>>().windows(2).any(|pair| { // contains a capitalisable character followed by, or preceded by, an underscore char_has_case(pair[0]) && pair[1] == '_' || char_has_case(pair[1]) && pair[0] == '_' }) </ins> } fn to_camel_case(s: &str) -> String { <del> s.split('_') .flat_map(|word| { </del> <ins> s.trim_matches('_') .split('_') .map(|word| { </ins> word.chars().enumerate().map(|(i, c)| if i == 0 { c.to_uppercase().collect::<String>() } else { c.to_lowercase().collect() }) <ins> .collect::<Vec<_>>() .concat() </ins> }) <ins> .filter(|x| !x.is_empty()) </ins> .collect::<Vec<_>>() <del> .concat() </del> <ins> .iter().fold((String::new(), None), |(acc, prev): (String, Option<&String>), next| { // separate two components with an underscore if their boundary cannot // be distinguished using a uppercase/lowercase case distinction let join = if let Some(prev) = prev { let l = prev.chars().last().unwrap(); let f = next.chars().next().unwrap(); !char_has_case(l) && !char_has_case(f) } else { false }; (acc + if join { "_" } else { "" } + next, Some(next)) }).0 </ins> } if !is_camel_case(name) {
Code change:
Specifically, there are snakecase names that cannot be converted into CamelCase (as interpreted by this lint) without losing semantics: anything that contains two numbers with a separator. E.g does not have a CamelCase equivalent that's accepted by the lint but is not confusable with the conversion result of . Originally discovered in

Related discussion:
text: type __ = isize; //~ ERROR type `__` should have a camel case name such as `CamelCase` <ins> struct X86_64; struct X86__64; //~ ERROR type `X86__64` should have a camel case name such as `X86_64` struct Abc_123; //~ ERROR type `Abc_123` should have a camel case name such as `Abc123` struct A1_b2_c3; //~ ERROR type `A1_b2_c3` should have a camel case name such as `A1B2C3` </ins> fn main() { }
Code change:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.

Related discussion:
text: // required. #[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> pub impl<T: Owned> Chan<T> { fn send(&self, x: T) { chan_send(self, x) } fn try_send(&self, x: T) -> bool { chan_try_send(self, x) }
Code change:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.

Related discussion:
text: // Use an inherent impl so that imports are not required: #[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> pub impl<T: Owned> Port<T> { fn recv(&self) -> T { port_recv(self) } fn try_recv(&self) -> Option<T> { port_try_recv(self) }
Code change:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.

Related discussion:
text: // Use an inherent impl so that imports are not required: #[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> pub impl<T:Owned> PortSet<T> { fn recv(&self) -> T { port_set_recv(self) } fn try_recv(&self) -> Option<T> { port_set_try_recv(self) }
Code change:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.

Related discussion:
text: #[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> pub impl<T: Owned> SharedChan<T> { fn send(&self, x: T) { shared_chan_send(self, x) } fn try_send(&self, x: T) -> bool { shared_chan_try_send(self, x) }
Code change:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.

Related discussion:
text: #[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> impl Reader for @Reader { fn read(&self, bytes: &mut [u8], len: uint) -> uint { self.read(bytes, len)
Code change:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.

Related discussion:
text: #[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> impl Writer for @Writer { fn write(&self, v: &[const u8]) { self.write(v) } fn seek(&self, a: int, b: SeekStyle) { self.seek(a, b) }
Code change:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.

Related discussion:
text: #[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> fn mk_tests(cx: &TestCtxt) -> @ast::item { let ext_cx = cx.ext_cx;
Code change:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.

Related discussion:
text: // Allow these methods to be used without import: #[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> pub impl<T:Owned,U:Owned> DuplexStream<T, U> { fn send(&self, x: T) { self.chan.send(x)
Code change:
landed implementations for a number of derived types in collections, but imposes overly strict requirements. For example, for : Given that only the keys are printed, we should only require , not also (unless I'm mistaken?).
Yep, seems overly restrictive.
While we're on it, should only require , and the same change should be applied to and friends.

Related discussion:
text: } #[stable(feature = "collection_debug", since = "1.17.0")] <del> impl<'a, K: 'a + fmt::Debug, V: 'a + fmt::Debug> fmt::Debug for Keys<'a, K, V> { </del> <ins> impl<'a, K: 'a + fmt::Debug, V: 'a> fmt::Debug for Keys<'a, K, V> { </ins> fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { <del> f.debug_list().entries(self.inner.clone()).finish() </del> <ins> f.debug_list().entries(self.clone()).finish() </ins> } }
Code change:
landed implementations for a number of derived types in collections, but imposes overly strict requirements. For example, for : Given that only the keys are printed, we should only require , not also (unless I'm mistaken?).
Yep, seems overly restrictive.
While we're on it, should only require , and the same change should be applied to and friends.

Related discussion:
text: } #[stable(feature = "collection_debug", since = "1.17.0")] <del> impl<'a, K: 'a + fmt::Debug, V: 'a + fmt::Debug> fmt::Debug for Values<'a, K, V> { </del> <ins> impl<'a, K: 'a, V: 'a + fmt::Debug> fmt::Debug for Values<'a, K, V> { </ins> fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { <del> f.debug_list().entries(self.inner.clone()).finish() </del> <ins> f.debug_list().entries(self.clone()).finish() </ins> } }
Code change:
landed implementations for a number of derived types in collections, but imposes overly strict requirements. For example, for : Given that only the keys are printed, we should only require , not also (unless I'm mistaken?).
Yep, seems overly restrictive.
While we're on it, should only require , and the same change should be applied to and friends.

Related discussion:
text: } #[stable(feature = "std_debug", since = "1.16.0")] <del> impl<'a, K: Debug, V: Debug> fmt::Debug for Keys<'a, K, V> { </del> <ins> impl<'a, K: Debug, V> fmt::Debug for Keys<'a, K, V> { </ins> fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { f.debug_list() .entries(self.clone())
Code change:
landed implementations for a number of derived types in collections, but imposes overly strict requirements. For example, for : Given that only the keys are printed, we should only require , not also (unless I'm mistaken?).
Yep, seems overly restrictive.
While we're on it, should only require , and the same change should be applied to and friends.

Related discussion:
text: } #[stable(feature = "std_debug", since = "1.16.0")] <del> impl<'a, K: Debug, V: Debug> fmt::Debug for Values<'a, K, V> { </del> <ins> impl<'a, K, V: Debug> fmt::Debug for Values<'a, K, V> { </ins> fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { f.debug_list() .entries(self.clone())
Code change:
Output is: The first message here is inaccurate. The macro-use does not expand to that macro-use. shows the input to macros, not the output. So instead of "expands to:", it should say "expanding:". But changing the behavior to match what the message says would be even better. ;) This is a regression because the error messages are new. used to just dump token streams to stdout (lol).
Introduced in .
Closing -- I believe fixed this.

Related discussion:
text: } } <ins> fn trace_macros_note(cx: &mut ExtCtxt, sp: Span, message: String) { let sp = sp.macro_backtrace().last().map(|trace| trace.call_site).unwrap_or(sp); let mut values: &mut Vec<String> = cx.expansions.entry(sp).or_insert_with(Vec::new); values.push(message); } </ins> /// Given `lhses` and `rhses`, this is the new macro we create fn generic_extension<'cx>(cx: &'cx mut ExtCtxt, sp: Span,
Code change:
Output is: The first message here is inaccurate. The macro-use does not expand to that macro-use. shows the input to macros, not the output. So instead of "expands to:", it should say "expanding:". But changing the behavior to match what the message says would be even better. ;) This is a regression because the error messages are new. used to just dump token streams to stdout (lol).
Introduced in .
Closing -- I believe fixed this.

Related discussion:
text: rhses: &[quoted::TokenTree]) -> Box<MacResult+'cx> { if cx.trace_macros() { <del> let sp = sp.macro_backtrace().last().map(|trace| trace.call_site).unwrap_or(sp); let mut values: &mut Vec<String> = cx.expansions.entry(sp).or_insert_with(Vec::new); values.push(format!("expands to `{}! {{ {} }}`", name, arg)); </del> <ins> trace_macros_note(cx, sp, format!("expanding `{}! {{ {} }}`", name, arg)); </ins> } // Which arm's failure should we report? (the one furthest along)
Code change:
Output is: The first message here is inaccurate. The macro-use does not expand to that macro-use. shows the input to macros, not the output. So instead of "expands to:", it should say "expanding:". But changing the behavior to match what the message says would be even better. ;) This is a regression because the error messages are new. used to just dump token streams to stdout (lol).
Introduced in .
Closing -- I believe fixed this.

Related discussion:
text: }; // rhs has holes ( `$id` and `$(...)` that need filled) let tts = transcribe(&cx.parse_sess.span_diagnostic, Some(named_matches), rhs); <ins> if cx.trace_macros() { trace_macros_note(cx, sp, format!("to `{}`", tts)); } </ins> let directory = Directory { path: cx.current_expansion.module.directory.clone(), ownership: cx.current_expansion.directory_ownership,
Code change:
Output is: The first message here is inaccurate. The macro-use does not expand to that macro-use. shows the input to macros, not the output. So instead of "expands to:", it should say "expanding:". But changing the behavior to match what the message says would be even better. ;) This is a regression because the error messages are new. used to just dump token streams to stdout (lol).
Introduced in .
Closing -- I believe fixed this.

Related discussion:
text: 14 |     println!("Hello, World!"); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^ | <del> = note: expands to `println! { "Hello, World!" }` = note: expands to `print! { concat ! ( "Hello, World!" , "/n" ) }` </del> <ins> = note: expanding `println! { "Hello, World!" }` = note: to `print ! ( concat ! ( "Hello, World!" , "/n" ) )` = note: expanding `print! { concat ! ( "Hello, World!" , "/n" ) }` = note: to `$crate :: io :: _print ( format_args ! ( concat ! ( "Hello, World!" , "/n" ) ) )` </ins>
Code change:
I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

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. fn main() { let value = 1; match SomeStruct(value) { StructConst1(_) => { }, //~^ ERROR expected tuple struct/variant, found constant `StructConst1` _ => { }, } struct SomeStruct(u8); const StructConst1 : SomeStruct = SomeStruct(1); const StructConst2 : SomeStruct = SomeStruct(2); } </ins>
Code change:
I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

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. #![feature(associated_consts)] trait Foo { const BAR: i32; fn foo(self) -> &'static i32 { //~^ ERROR the trait bound `Self: std::marker::Sized` is not satisfied &<Self>::BAR } } fn main() {} </ins>
Code change:
I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

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. macro_rules! get_opt { ($tgt:expr, $field:ident) => { if $tgt.has_$field() {} } } fn main() { get_opt!(bar, foo); //~^ ERROR expected `{`, found `foo` } </ins>