jiebi/CodeConvo huggingface dataset:
Change:
The current implementation of is not valid in a const context, but it can easily be tweaked so that it is:
At this point you can just enable the feature gate and use . There's no need for unions anymore
I thought was explicitly not going to become as per the discussion in .
Alternatively, why can't we make DST constructors work for simple wrappers like this? Why can't it be, e.g. &CStr{ bytes: *bytes } Where it looks kind of like the opposite of a deref coercion, and the compiler just reinterprets the fat pointer? This would eliminate the need for any besides what's necessary for the API contract.
Yes I would like such constructors, too. But that needs and RFC and probably has a lot of caveats that we want to think about. I did not know about that issue. I commented there.

Discussion:
/// ``` #[inline] #[stable(feature = "cstr_from_bytes", since = "1.10.0")] <del> pub unsafe fn from_bytes_with_nul_unchecked(bytes: &[u8]) -> &CStr { </del> <ins> #[rustc_const_unstable(feature = "const_cstr_unchecked")] pub const unsafe fn from_bytes_with_nul_unchecked(bytes: &[u8]) -> &CStr { </ins> &*(bytes as *const [u8] as *const CStr) }

assert_eq!(&*rc2, cstr); assert_eq!(&*arc2, cstr); } <ins> #[test] fn cstr_const_constructor() { const CSTR: &'static CStr = unsafe { CStr::from_bytes_with_nul_unchecked(b"Hello, world!0") }; assert_eq!(CSTR.to_str().unwrap(), "Hello, world!"); } </ins> }

#![feature(min_const_fn)] #![feature(const_int_ops)] #![feature(const_ip)] <ins> #![feature(const_raw_ptr_deref)] #![feature(const_cstr_unchecked)] </ins> #![feature(core_intrinsics)] #![feature(dropck_eyepatch)] #![feature(exact_size_is_empty)]
Change:
Rustc 1.30.0-nightly ( 2018-09-29) suggests turning into , which changes the meaning of the program. warning: unnecessary parentheses around condition -- | 5 | if (break { return true }) { | ^^^^^^^^^^^^^^^^^^^^^^^ help: remove these parentheses | = note: #[warn(unused_parens)] on by default

Discussion:
msg: &str, followed_by_block: bool) { if let ast::ExprKind::Paren(ref inner) = value.node { <del> let necessary = followed_by_block && if let ast::ExprKind::Ret(_) = inner.node { true } else { parser::contains_exterior_struct_lit(&inner) </del> <ins> let necessary = followed_by_block && match inner.node { ast::ExprKind::Ret(_) | ast::ExprKind::Break(..) => true, _ => parser::contains_exterior_struct_lit(&inner), </ins> }; if !necessary { let expr_text = if let Ok(snippet) = cx.sess().source_map()

// We want to suggest the properly-balanced expression `1 / (2 + 3)`, not // the malformed `1 / (2 + 3` let _a = (1 / (2 + 3)); <ins> f(); } fn f() -> bool { loop { if (break { return true }) { } } false </ins> }
Change:
Since I got an error message "Illegal lifetime 'self: the lifetime must be declared" on several lines, I declare like below and it doesn't occur any error now.
works on latest. seems no more issue.

Discussion:
fn test_ascii_vec() { let test = &[40u8, 32u8, 59u8]; assert_eq!(test.to_ascii(), v2ascii!([40, 32, 59])); <del> assert_eq!("( ;".to_ascii(),                 v2ascii!([40, 32, 59])); // FIXME: #5475 borrowchk error, owned vectors do not live long enough // if chained-from directly </del> <ins> assert_eq!("( ;".to_ascii(), v2ascii!([40, 32, 59])); </ins> let v = box [40u8, 32u8, 59u8]; assert_eq!(v.to_ascii(), v2ascii!([40, 32, 59])); <del> let v = "( ;".to_strbuf(); assert_eq!(v.as_slice().to_ascii(), v2ascii!([40, 32, 59])); </del> <ins> assert_eq!("( ;".to_strbuf().as_slice().to_ascii(), v2ascii!([40, 32, 59])); </ins> assert_eq!("abCDef&?#".to_ascii().to_lower().into_str(), "abcdef&?#".to_strbuf()); assert_eq!("abCDef&?#".to_ascii().to_upper().into_str(), "ABCDEF&?#".to_strbuf());
Change:
Implemented in
The documentation needs to be made slightly more strict. For example: Should be replaced with The distinction is important, because at the exact moment this function returns might already be executed/resolved, without it necessarily happening “immediately after”. To avoid people shotgunning their feet off, I would suggest to add some guidance on how this should be used. For example, doing something useful based on this function returning a is somewhat likely to be a bug. And yet, examples do not really result in such an impression.
CC for nagisa’s comment above.
It's been 9 months since this was implemented. Can this be stabilized now?
Is there anything preventing this method from being stabilized? It looks like there was some bikesheding in but it's now been just past a year since initial adoption.
Note that I am personally no longer directly interested in having this method: in , I ended-up copy-pasting the whole of anyway. That said, this does look like straightforward addition, which allows to do more with the thing, without actually expanding it's surface area greatly.

Discussion:
///   * `call_once` was called, but has not yet completed, ///   * the `Once` instance is poisoned /// <del> /// It is also possible that immediately after `is_completed` /// returns false, some other thread finishes executing /// `call_once`. </del> <ins> /// This function returning `false` does not mean that `Once` has not been /// executed. For example, it may have been executed in the time between /// when `is_completed` starts executing and when it returns, in which case /// the `false` return value would be stale (but still permissible). </ins> /// /// # Examples /// /// ``` <del> /// #![feature(once_is_completed)] </del> /// use std::sync::Once; /// /// static INIT: Once = Once::new();

/// ``` /// /// ``` <del> /// #![feature(once_is_completed)] </del> /// use std::sync::Once; /// use std::thread; ///

/// assert!(handle.join().is_err()); /// assert_eq!(INIT.is_completed(), false); /// ``` <del> #[unstable(feature = "once_is_completed", issue = "54890")] </del> <ins> #[stable(feature = "once_is_completed", since = "1.44.0")] </ins> #[inline] pub fn is_completed(&self) -> bool { // An `Acquire` load is enough because that makes all the initialization
Change:
I expected just a compiler error . Compiler panicked: Meta
This is fixed in the beta version (1.30).

Discussion:
<ins> error[E0596]: cannot borrow data in a `&` reference as mutable --> $DIR/issue-52240.rs:9:27 | LL |     if let (Some(Foo::Bar(ref mut val)), _) = (&arr.get(0), 0) { |                           ^^^^^^^^^^^ cannot borrow as mutable error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </ins>

<ins> // issue-52240: Can turn immutable into mut with `ref mut` enum Foo { Bar(i32), } fn main() { let arr = vec!(Foo::Bar(0)); if let (Some(Foo::Bar(ref mut val)), _) = (&arr.get(0), 0) { //~^ ERROR cannot borrow field of immutable binding as mutable *val = 9001; } match arr[0] { Foo::Bar(ref s) => println!("{}", s) } } </ins>

<ins> error[E0596]: cannot borrow field of immutable binding as mutable --> $DIR/issue-52240.rs:9:27 | LL |     if let (Some(Foo::Bar(ref mut val)), _) = (&arr.get(0), 0) { |                           ^^^^^^^^^^^ cannot mutably borrow field of immutable binding error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </ins>

<ins> // issue-54966: ICE returning an unknown type with impl FnMut fn generate_duration() -> Oper<impl FnMut()> {} //~^ ERROR cannot find type `Oper` in this scope fn main() {} </ins>

<ins> error[E0412]: cannot find type `Oper` in this scope --> $DIR/issue-54966.rs:3:27 | LL | fn generate_duration() -> Oper<impl FnMut()> {} |                           ^^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0412`. </ins>
Change:
(updated test case for bug) The following test inputs: or, more elaborately: yields the ICE failure: (original bug test case follows)
This may or may not be the same failure as which fails with .
Visited for triage. Was able to reproduce. Nominating for "maturity number 5 - production ready".
accepted for production-ready milestone
just a bug, removing milestone/nomination.
Both the smaller and the bigger versions still ICE as of

Discussion:
// make sure that the thing we are pointing out stays valid // for the lifetime `scope_r` of the resulting ptr: <del> let scope_r = ty_region(tcx, ex.span, ty::expr_ty(tcx, ex)); this.guarantee_valid(ex.id, ex.span, base_cmt, LoanMutability::from_ast_mutability(mutbl), scope_r); </del> <ins> let expr_ty = ty::expr_ty(tcx, ex); if !ty::type_is_bot(expr_ty) { let scope_r = ty_region(tcx, ex.span, expr_ty); this.guarantee_valid(ex.id, ex.span, base_cmt, LoanMutability::from_ast_mutability(mutbl), scope_r); } </ins> visit::walk_expr(this, ex, ()); }

<ins> // Copyright 2013 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. // error-pattern:explicit failure fn main() { &fail!() } </ins>
Change:
Consider the following code (): This code doesn't compile because that all type parameters are in scope for the concrete type. This get fixed eventually, but for the time being, we can work around it using (rust-lang/rfcs; ): However, this pattern does not compose. This example fails to compile (): with the error I'm not entirely sure why this fails, but it seems like the code should be accepted? /cc
Or a somewhat simpler example with just a single existential ():
Maybe also tag with since it's related to existentials? And possibly (or is this terretority?)
Replacing with compiles fine.

Discussion:
<ins> // check-pass // Regression test for issue #55099 // Tests that we don't incorrectly consider a lifetime to part // of the concrete type #![feature(type_alias_impl_trait)] trait Future { } struct AndThen<F>(F); impl<F> Future for AndThen<F> { } struct Foo<'a> { x: &'a mut (), } type F = impl Future; impl<'a> Foo<'a> { fn reply(&mut self) -> F { AndThen(|| ()) } } fn main() {} </ins>
Change:
This code snippet () results in the following lint output: The should contain the literal string , not the expanded macro that it repreesnts.
Ah, I think this is because we should be using (to get the code the user actually wrote) (to render the AST); I could PR this tonight.

Discussion:
let necessary = struct_lit_needs_parens && parser::contains_exterior_struct_lit(&inner); if !necessary { <del> let pattern = pprust::expr_to_string(value); Self::remove_outer_parens(cx, value.span, &pattern, msg); </del> <ins> let expr_text = if let Ok(snippet) = cx.sess().source_map() .span_to_snippet(value.span) { snippet } else { pprust::expr_to_string(value) }; Self::remove_outer_parens(cx, value.span, &expr_text, msg); </ins> } } }

value: &ast::Pat, msg: &str) { if let ast::PatKind::Paren(_) = value.node { <del> let pattern = pprust::pat_to_string(value); Self::remove_outer_parens(cx, value.span, &pattern, msg); </del> <ins> let pattern_text = if let Ok(snippet) = cx.sess().source_map() .span_to_snippet(value.span) { snippet } else { pprust::pat_to_string(value) }; Self::remove_outer_parens(cx, value.span, &pattern_text, msg); </ins> } }

while true { //~^ WARN denote infinite loops //~| HELP use `loop` <del> let mut a = (1); </del> <ins> let mut registry_no = (format!("NX-{}", 74205)); </ins> //~^ WARN does not need to be mutable //~| HELP remove this `mut` //~| WARN unnecessary parentheses

//~^ WARN this pattern is redundant //~| HELP remove this } <del> println!("{} {}", a, b); </del> <ins> println!("{} {}", registry_no, b); </ins> } }

warning: unnecessary parentheses around assigned value <del> --> $DIR/suggestions.rs:59:21 </del> <ins> --> $DIR/suggestions.rs:59:31 </ins> | <del> LL |         let mut a = (1); |                     ^^^ help: remove these parentheses </del> <ins> LL |         let mut registry_no = (format!("NX-{}", 74205)); |                               ^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove these parentheses </ins> | note: lint level defined here --> $DIR/suggestions.rs:13:21

warning: variable does not need to be mutable --> $DIR/suggestions.rs:59:13 | <del> LL |         let mut a = (1); |             ----^ </del> <ins> LL |         let mut registry_no = (format!("NX-{}", 74205)); |             ----^^^^^^^^^^^ </ins> |             | |             help: remove this `mut` |
Change:
When compiling with the wasm32-unknown-emscripten target, the recent nightly compilers can't seem to find the rustehpersonality symbol. https://travis- It works just fine with the asmjs-unknown-emscripten target.
I've seen this too, but only when is enabled. Is that enabled for your project?
Yeah I have it set to abort.

Discussion:
pub mod personalities { #[no_mangle] #[cfg(not(any( <del> target_arch = "wasm32", </del> <ins> all( target_arch = "wasm32", not(target_os = "emscripten"), ), </ins> all( target_os = "windows", target_env = "gnu",
Change:
Trying to build 1.30.0 with remap-debuginfo enabled results in rustbuild tries to get the sha from the current commit when we are not in a git repository

Discussion:
let path = match which { GitRepo::Rustc => { <del> let sha = self.rust_info.sha().expect("failed to find sha"); </del> <ins> let sha = self.rust_sha().unwrap_or(channel::CFG_RELEASE_NUM); </ins> format!("/rustc/{}", sha) } GitRepo::Llvm => format!("/rustc/llvm"),
Change:
Environment: rustc 1.31.0-nightly ( 2018-10-25) and rustc 1.30.0 ( 2018-10-24) Rustc produces E0704 error code on the following (syntactically wrong) code: But but neither nor is aware of this error
I can pick this up unless you'd want to do it yourself! This will be the first the I am writing docs for errors (unless Undin wants to do it of course). I guess the general structure looks a bit like this?: Short description of the error Example of bad syntax Example of good syntax Or should there be something else I can add?
Unfortunately, at this moment I don't have enough time to fix it myself so I will be glad if you fix it
I will try my best this week! Hopefully I'll be able to create a PR on Wednesday. I'll tag you once it's done :)

Discussion:
"##, <ins> E0704: r##" This error indicates that a incorrect visibility restriction was specified. Example of erroneous code: ```compile_fail,E0704 mod foo { pub(foo) struct Bar { x: i32 } } ``` To make struct `Bar` only visible in module `foo` the `in` keyword should be used: ``` mod foo { pub(in crate::foo) struct Bar { x: i32 } } # fn main() {} ``` For more information see the Rust Reference on [Visibility]. [Visibility]: https://doc.rust-lang.org/reference/visibility-and-privacy.html "##, </ins> E0705: r##" A `#![feature]` attribute was declared for a feature that is stable in the current edition, but not in all editions.

E0693, // incorrect `repr(align)` attribute format E0694, // an unknown tool name found in scoped attributes E0703, // invalid ABI <del> E0704, // incorrect visibility restriction </del> E0717, // rustc_promotable without stability attribute }

error: aborting due to 5 previous errors <ins> For more information about this error, try `rustc --explain E0704`. </ins>
Change:
The following code builds successfully but causes a compiler panic when running : Compiler error Toolchain Changing to another name, either in the doc comment or the actual function name (but not both), causes to succeed with a warning that the link cannot be resolved, as expected. Using a normal public function in a non-procmacro library also does not cause a panic, e.g.
Same stack trace as .
Good find. That one is also a procedural macro, might be appropriate to add a label to both.
Doing a little digging... The first rustdoc code in that stack trace is this part in , which attempts to load up a macro definition for the given path text: The call to successfully returns a Def, but it's the call to that's ultimately failing. The reasoning behind this can be explained in the function, which we're not calling, but handles the same code with a bit more overhead. In that function, there's a branch that gives me a hint to what's going on: In effect: proc-macros are not available to the crate that defines them. This makes sense in terms of making sure they don't infinitely recurse, but leaves rustdoc out to dry when all it wants is to make sure that the macro in question is a Macros 2.0 macro. I'm waiting on a build right now, but we may be able to skip the call to by looking at the Def returned by and seeing whether it's a . That way, we can handle those differently and avoid the problematic call to .
Update: Skipping the call to for macros of kind seems to have fixed this issue! I've opened to fix this.

Discussion:
let parent_scope = resolver.dummy_parent_scope(); if let Ok(def) = resolver.resolve_macro_to_def_inner(&path, MacroKind::Bang, &parent_scope, false, false) { <del> if let SyntaxExtension::DeclMacro { .. } = *resolver.get_macro(def) { return Some(def); </del> <ins> if let Def::Macro(_, MacroKind::ProcMacroStub) = def { // skip proc-macro stubs, they'll cause `get_macro` to crash } else { if let SyntaxExtension::DeclMacro { .. } = *resolver.get_macro(def) { return Some(def); } </ins> } } if let Some(def) = resolver.all_macros.get(&Symbol::intern(path_str)) {

#![crate_type="proc-macro"] #![crate_name="some_macros"] <ins> // @has some_macros/index.html // @has - '//a/[@href="attr.some_proc_attr.html"]' 'some_proc_attr' //! include a link to [some_proc_attr] to make sure it works. </ins> extern crate proc_macro; use proc_macro::TokenStream;
Change:
Docs for keyword should mention (I guess issue titles still can't have code :/)
FYI, there are some existing docs about in the Reference:
a PR would be welcome.

Discussion:
// /// The `for` keyword. /// <del> /// `for` is primarily used in for-in-loops, but it has a few other pieces of syntactic uses such as /// `impl Trait for Type` (see [`impl`] for more info on that). for-in-loops, or to be more /// precise, iterator loops, are a simple syntactic sugar over an exceedingly common practice /// within Rust, which is to loop over an iterator until that iterator returns `None` (or `break` /// is called). </del> <ins> /// The `for` keyword is used in many syntactic locations: /// /// * `for` is used in for-in-loops (see below). /// * `for` is used when implementing traits as in `impl Trait for Type` (see [`impl`] for more info ///   on that). /// * `for` is also used for [higher-ranked trait bounds] as in `for<'a> &'a T: PartialEq<i32>`. /// /// for-in-loops, or to be more precise, iterator loops, are a simple syntactic sugar over a common /// practice within Rust, which is to loop over an iterator until that iterator returns `None` (or /// `break` is called). </ins> /// /// ```rust /// for i in 0..5 {

/// For more information on for-loops, see the [Rust book] or the [Reference]. /// /// [`impl`]: keyword.impl.html <ins> /// [higher-ranked trait bounds]: /// https://doc.rust-lang.org/nightly/reference/trait-bounds.html#higher-ranked-trait-bounds </ins> /// [`IntoIterator`]: iter/trait.IntoIterator.html /// [Rust book]: /// https://doc.rust-lang.org/book/2018-edition/ch03-05-control-flow.html#looping-through-a-collection-with-for
Change:
Compiling the above code generates this error message: However, this compiles: Note that for the invokation both versions and just works. Is this intended behaviour or a bug? Try it yourself at .
This may be related to the issue where macros (it seems limited to built-in ones) don't work when called qualified with their path.
is not defined in the library, it's a built-in macro defined by the language. in its turn is indeed defined in , so it can be used as . It should be possible to make a proxy macro in calling built-in , it may require some care about what rusdoc shows for that macro though.
This is a bug. I understand that there is nuance around built-in macros but it's clear to me that should be accepted.
Triage: the docs of libcore should probably be updated.
Is the request for to be accepted or for rustdoc to stop documenting ? If the former, this should be tagged or , not .
you've said contradicting things: said should be accepted as-is and said the docs shouldn't show as valid. Which is it? Does it need an RFC?
needs to work. It does not require an RFC. According to OP, already works. It's possible there was a rustdoc issue also. According to , rustdoc was showing in core even though it was not exposed by core in a way that was callable.
Heh, after all that it turns out this compiles as-is (maybe assert was moved to core recently?). I'll add a test for it.

Discussion:
<ins> // compile-flags: --crate-type=lib // check-pass // issue #55482 #![no_std] macro_rules! foo { ($e:expr) => { $crate::core::assert!($e); $crate::core::assert_eq!($e, true); }; } pub fn foo() { foo!(true); } </ins>
Change:
After we have chased down a bug in our multiprocess application, which caused messages passed between processes to get lost sometimes, I would like to suggest including a small hint in the Rust documentation of . Maybe a lint implementation for clippy also would be possible. The messages got (sometimes partly) lost, because I repeatedly created a instance on the same reference for every line I wanted to read off the stream. This instance got then dropped at the end of the scope. Retroperspective this was not a wise decision in my implementation and I understand that this can cause parts of stream data to get lost when the instance gets dropped. But when implementing it I did not think of such a possibility and finding the source of this bug was quite difficult. It ended up searching the libstd source, after having found out that a crude self implementation of somehow fixed the bug. Only this brought up the idea, that the buffering of could be the cause of our issues. The issue can be reproduced by the following simple application and one file with some lines of text in the execution directory. The read lines are written for comparison into . To decrease the chance for others repeating the same mistake, I would suggest a short hint in the documentation of , that creating multiple instances on a referenced stream (especially in some sort of loop) can cause data loss. Maybe it might even be possible to implement a clippy lint to fetch such a pitfall. The related users topic can be found .

Discussion:
/// times. It also provides no advantage when reading from a source that is /// already in memory, like a `Vec<u8>`. /// <ins> /// When the `BufReader` is dropped, the contents of its buffer will be /// discarded. Creating multiple instances of a `BufReader` on the same /// stream can cause data loss. /// </ins> /// [`Read`]: ../../std/io/trait.Read.html /// [`TcpStream::read`]: ../../std/net/struct.TcpStream.html#method.read /// [`TcpStream`]: ../../std/net/struct.TcpStream.html