jiebi/CodeConvo huggingface dataset:
Change:
In the example for is used: This is redundant and might mislead users that they're supposed to explicitly the socket. I think this should be removed. cc ?
Yes, I agree.

Discussion:
/// use std::net::UdpSocket; /// /// # fn foo() -> std::io::Result<()> { <del> /// let mut socket = try!(UdpSocket::bind("127.0.0.1:34254")); </del> <ins> /// { ///     let mut socket = try!(UdpSocket::bind("127.0.0.1:34254")); </ins> /// <del> /// let mut buf = [0; 10]; /// let (amt, src) = try!(socket.recv_from(&mut buf)); </del> <ins> ///     // read from the socket ///     let mut buf = [0; 10]; ///     let (amt, src) = try!(socket.recv_from(&mut buf)); </ins> /// <del> /// // Send a reply to the socket we received data from /// let buf = &mut buf[..amt]; /// buf.reverse(); /// try!(socket.send_to(buf, &src)); /// /// drop(socket); // close the socket /// # Ok(()) </del> <ins> ///     // send a reply to the socket we received data from ///     let buf = &mut buf[..amt]; ///     buf.reverse(); ///     try!(socket.send_to(buf, &src)); ///     # Ok(()) /// } // the socket is closed here </ins> /// # } /// ``` #[stable(feature = "rust1", since = "1.0.0")]
Change:
The book uses both forms several times. It should be consistent. files with : benchmark- borrow-and- guessing- references-and- files with : choosing-your- choosing-your- references-and-
It should generally be "a", since it's "a mutable reference"

Discussion:
mutable. At the same time, there can only be one mutable borrow of the whole `Vec` at a given time. This means that your code cannot simultaneously work on different elements of the vector from different `Rc` handles. However, we are able to push and pop from the `Vec<T>` at will. This is <del> similar to an `&mut Vec<T>` with the borrow checking done at runtime. </del> <ins> similar to a `&mut Vec<T>` with the borrow checking done at runtime. </ins> With the latter, the borrowing is of individual elements, but the overall vector is immutable. Thus, we can independently borrow separate elements, but we cannot push or pop from the vector. This is <del> similar to an `&mut [T]`[^3], but, again, the borrow checking is at runtime. </del> <ins> similar to a `&mut [T]`[^3], but, again, the borrow checking is at runtime. </ins> In concurrent programs, we have a similar situation with `Arc<Mutex<T>>`, which provides shared mutability and ownership.

...(x: &'a i32) ``` <del> If we wanted an `&mut` reference, we’d do this: </del> <ins> If we wanted a `&mut` reference, we’d do this: </ins> ```rust,ignore ...(x: &'a mut i32)

If it wasn’t, we couldn’t take a mutable borrow to an immutable value. You'll also notice we added an asterisk (`*`) in front of `y`, making it `*y`, <del> this is because `y` is an `&mut` reference. You'll also need to use them for </del> <ins> this is because `y` is a `&mut` reference. You'll also need to use them for </ins> accessing the contents of a reference as well. Otherwise, `&mut` references are just like references. There _is_ a large
Change:
I have encountered this problem several times while compiling versions of rustc with errors, but this is the first self-contained example I have found. A single error as the field does not exist Note the fat cascading region error. This reproduces on 1.5/1.6 and current nightly.
cc

Discussion:
.map(|method| resolve_ty(method.ty))) } <ins> pub fn errors_since_creation(&self) -> bool { self.tcx.sess.err_count() - self.err_count_on_creation != 0 } </ins> pub fn node_type(&self, id: ast::NodeId) -> Ty<'tcx> { match self.tables.borrow().node_types.get(&id) { Some(&t) => t, // FIXME <del> None if self.tcx.sess.err_count() - self.err_count_on_creation != 0 => </del> <ins> None if self.errors_since_creation() => </ins> self.tcx.types.err, None => { self.tcx.sess.bug(

free_regions: &FreeRegionMap, subject_node_id: ast::NodeId) { let errors = self.region_vars.resolve_regions(free_regions, subject_node_id); <del> self.report_region_errors(&errors); // see error_reporting.rs </del> <ins> if !self.errors_since_creation() { // As a heuristic, just skip reporting region errors // altogether if other errors have been reported while // this infcx was in use.  This is totally hokey but // otherwise we have a hard time separating legit region // errors from silly ones. self.report_region_errors(&errors); // see error_reporting.rs } </ins> } pub fn ty_to_string(&self, t: Ty<'tcx>) -> String {

<ins> // Copyright 2012 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 do not see uninformative region-related errors // when we get some basic type-checking failure. See #30580. pub struct Foo { a: u32 } pub struct Pass<'a, 'tcx: 'a>(&'a mut &'a (), &'a &'tcx ()); impl<'a, 'tcx> Pass<'a, 'tcx> { pub fn tcx(&self) -> &'a &'tcx () { self.1 } fn lol(&mut self, b: &Foo) { b.c; //~ ERROR no field with that name was found self.tcx(); } } fn main() {} </ins>
Change:
The documentation for the macro claims: But if you read the implementation of , you see that it tests equality in one direction only. Also see the example:
What does "equality in both directions" even mean?
It used to check if .
The commit that introduced this mismatch was debugasserteq internally uses asserteq, and when asserteq was changed to check equality in one direction only (in above commit), the documentation for debugasserteq wasn't adjusted.
As the macro was stabilized when it checked equality in one direction only. I guess it makes most sense to adjust the documentation, and not the code?
Yep, this is a docs issue.

Discussion:
($($arg:tt)*) => (if cfg!(debug_assertions) { assert!($($arg)*); }) } <del> /// Asserts that two expressions are equal to each other, testing equality in /// both directions. </del> <ins> /// Asserts that two expressions are equal to each other. </ins> /// <del> /// On panic, this macro will print the values of the expressions. </del> <ins> /// On panic, this macro will print the values of the expressions with their /// debug representations. </ins> /// /// Unlike `assert_eq!`, `debug_assert_eq!` statements are only enabled in non /// optimized builds by default. An optimized build will omit all
Change:
The DragonflyBSD build is broken the same way the FreeBSD is broken. This is because there isn't a new enough snapshot for the platform. Let me fix that.

Discussion:
bitrig-x86_64 6476e1562df02389b55553b4c88b1f4fd121cd40 freebsd-i386 7e624c50494402e1feb14c743d659fbd71b448f5 freebsd-x86_64 91724d4e655807a2a2e940ac50992ebeaac16ea9 <ins> dragonfly-x86_64 e74d79488e88ac2de3bd03afd5959d2ae6e2b628 </ins> linux-i386 a09c4a4036151d0cb28e265101669731600e01f2 linux-x86_64 97e2a5eb8904962df8596e95d6e5d9b574d73bf4 macos-i386 ca52d2d3ba6497ed007705ee3401cf7efc136ca1
Change:
Not a breaking change since it is an unstable option.
Is it already an unstable option?
this issue is saying that should be changed to . It is already an unstable option.
So can accept as arguments. How would those be specified if were changed to a ?
Hopefully exactly the same way, not sure how possible that is. If it is not possible right now, then this probably isn't an easy issue to fix. I can look into it next week.
We've got kinda our own syntax for the flags so where today you pass it could instead be

Discussion:
pub prints: Vec<PrintRequest>, pub cg: CodegenOptions, pub color: ColorConfig, <del> pub show_span: Option<String>, </del> pub externs: HashMap<String, Vec<String>>, pub crate_name: Option<String>, /// An optional name to use as the crate for std during std injection,

prints: Vec::new(), cg: basic_codegen_options(), color: ColorConfig::Auto, <del> show_span: None, </del> externs: HashMap::new(), crate_name: None, alt_std_name: None,

"don't clear the resolution tables after analysis"), keep_ast: bool = (false, parse_bool, "keep the AST after lowering it to HIR"), <ins> show_span: Option<String> = (None, parse_opt_string, "show spans for compiler debugging (expr|pat|ty)"), </ins> } pub fn default_lib_output() -> CrateType {

`hir` (the HIR), `hir,identified`, or `hir,typed` (HIR with types for each node).", "TYPE"), <del> opt::opt_u("", "show-span", "Show spans for compiler debugging", "expr|pat|ty"), </del> ]); opts }

prints: prints, cg: cg, color: color, <del> show_span: None, </del> externs: externs, crate_name: crate_name, alt_std_name: None,

println!("Pre-expansion node count:  {}", count_nodes(&krate)); } <del> if let Some(ref s) = sess.opts.show_span { </del> <ins> if let Some(ref s) = sess.opts.debugging_opts.show_span { </ins> syntax::show_span::run(sess.diagnostic(), s, &krate); }

}; let cstore = Rc::new(CStore::new(token::get_ident_interner())); <del> let mut sess = build_session(sopts, input_file_path, descriptions, </del> <ins> let sess = build_session(sopts, input_file_path, descriptions, </ins> cstore.clone()); rustc_lint::register_builtins(&mut sess.lint_store.borrow_mut(), Some(&sess)); <del> if sess.unstable_options() { sess.opts.show_span = matches.opt_str("show-span"); } </del> let mut cfg = config::build_configuration(&sess); target_features::add_configuration(&mut cfg, &sess);

fn build_controller(&mut self, sess: &Session) -> CompileController<'a> { let mut control = CompileController::basic(); <del> if sess.opts.parse_only || sess.opts.show_span.is_some() || </del> <ins> if sess.opts.parse_only || sess.opts.debugging_opts.show_span.is_some() || </ins> sess.opts.debugging_opts.ast_json_noexpand { control.after_parse.stop = Compilation::Stop; }
Change:
The in does not actually test the MIR translation path because the attribute on the function is not picked up. There is already PR that fixes the ignoring of attributes on generic functions. Once it has landed, the test method can be used in its current form. Otherwise it would have to be rewritten in a non-generic way.

Discussion:
x.extension_method(a) } <del> // FIXME #30661: Although this function has the #[rustc_mir] attribute it never //               was translated via the MIR implementation because attributes //               where not passed along to trans::base::trans_fn() for generic //               functions. //               Uncomment this test once the thing it tests is fixed. // #[rustc_mir] // fn test6<T: Bar>(x: &T, a: isize) -> isize { //     // Test calling extension method on generic callee //     x.extension_method(a) // } </del> <ins> #[rustc_mir] fn test6<T: Bar>(x: &T, a: isize) -> isize { // Test calling extension method on generic callee x.extension_method(a) } </ins> trait One<T = Self> { fn one() -> T;

assert_eq!(test3(&Foo, 42), 42); assert_eq!(test4(&Foo, 970), 970); assert_eq!(test5(&Foo, 8576), 8576); <del> // see definition of test6() above // assert_eq!(test6(&Foo, 12367), 12367); </del> <ins> assert_eq!(test6(&Foo, 12367), 12367); </ins> assert_eq!(test7(), 1); assert_eq!(test8(), 2);
Change:
says: "It's easy to add, in under 'ifdef CFGENABLEDEBUG'". If this happens, we also need to consider the build; i.e., make the bots use that flag sometimes.

Discussion:
ifdef CFG_ENABLE_DEBUG $(info cfg: enabling more debugging (CFG_ENABLE_DEBUG)) <del> CFG_RUSTC_FLAGS += </del> <ins> CFG_RUSTC_FLAGS += --cfg debug </ins> CFG_GCCISH_CFLAGS += -DRUST_DEBUG else CFG_GCCISH_CFLAGS += -DRUST_NDEBUG
Change:
I can't really pin down the exact cause of this, but a MWE is . Compiling on beta produces a normal error, but the nightly compiler panics. On my machine:
cc since this looks related to your "Structured Errors" PR
I don't know if anyone cares, but that macro is going to get broken for a different reason when the new macro future proofing lands ( and )
The macro was already broken to be fair, but thanks for the heads up.
Its also worth noting that the reason you get that error about "unexpected " is, I believe, because the macro matching does not have the same fine grain classes that the parser does. In particular, is not actually putting arbitrary in there, but rather a subset of expressions that cannot end in . (Examples of the latter include, in particular, struct literals.) Macros do not currently have the ability to express that subclass of expressions. So when the pattern matches against , it ends up trying to parse the latter as (That's right: A range expression, where the high end of the range is a struct literal. Hey, that's what you get when you have such a broad range of expression forms!) And then it fails the parse when it sees a after , when it is expecting a that you get in struct literal expressions But I think the idea from (see ) would I think provide that functionality (of specifying the narrower class of expressions that the user actually wants to match as the following the token). Maybe this is the example we've been looking for to motivate adding that new fragment class.

Discussion:
// We have 2 alternatives here: `x..y` and `x..` The other two variants are // handled with `parse_prefix_range_expr` call above. let rhs = if self.is_at_start_of_range_notation_rhs() { <del> self.parse_assoc_expr_with(op.precedence() + 1, LhsExpr::NotYetParsed).ok() </del> <ins> let rhs = self.parse_assoc_expr_with(op.precedence() + 1, LhsExpr::NotYetParsed); match rhs { Ok(e) => Some(e), Err(mut e) => { e.cancel(); None } } </ins> } else { None };

<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. macro_rules! parallel { ( for $id:ident in $iter:expr { $( $inner:expr; )* } ) => {}; } fn main() { parallel! { for i in 0..n { x += i; //~ ERROR no rules expected the token `+=` } } } </ins>
Change:
Normally, an unused import: Produces this compiler output: Saying the 'unusedimports' lint is 'on by default'. If you explicitly set that lint to deny: Then the error indicates where the lint was set to 'deny': If you instead change warnings to errors: Then you get this error: Which says 'deny(unusedimports)' is 'on by default'. That is not true. unused_imports is warn by default. This case should point to as the source of the error. Discovered while interpreting all the lint regressions in . cc
I took a shot at this and made a PR. Now your example code for deny(warnings) shows the following:
This was fixed by .

Discussion:
fn level_src(&self, lint: &'static Lint) -> Option<LevelSource> { self.lints().levels.get(&LintId::of(lint)).map(|ls| match ls { <del> &(Warn, src) => { </del> <ins> &(Warn, _) => { </ins> let lint_id = LintId::of(builtin::WARNINGS); <del> (self.lints().get_level_source(lint_id).0, src) </del> <ins> let warn_src = self.lints().get_level_source(lint_id); if warn_src.0 != Warn { warn_src } else { *ls } </ins> } _ => *ls })

<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. #![deny(warnings)] //~ NOTE: lint level defined here use std::thread; //~ ERROR: unused import fn main() {} </ins>
Change:
But as far as I understand it, an unsafe block can instead break an invariant that causes a segfault further down the line in safe code. Also, stack overflows can cause a segfault.
You are correct in your understanding: the text could be tweaked to "you can be sure its cause is somewhere in the sections marked unsafe". NB. this is an implementation bug in rustc (), i.e. this doesn't happen in a "perfect" Rust compiler (the book is designed to document the language not the details of rustc).
This is not quite true:
The and disagree.
it depends what is meant by "cause"; a segfault will only occur if the program executes an block at some point, and does some unsafe operation with incorrect arguments, the point the nomicon and Ralf make is that the incorrectness in these arguments may flow from some safe piece of code. In any case, Steve's rewording is better than my proposal.

Discussion:
``` It’s important to be able to explicitly delineate code that may have bugs that <del> cause big problems. If a Rust program segfaults, you can be sure it’s somewhere in the sections marked `unsafe`. </del> <ins> cause big problems. If a Rust program segfaults, you can be sure the cause is related to something marked `unsafe`. </ins> # What does ‘safe’ mean?
Change:
We have no link from to , and it is not good in terms of usability. I guess this is because is a verbatim copy of the raw output from . See how Python documents are organized: ! I think this is the relevant functionality of the Sphinx documentation tool for Python: We should aim for the same level of usability standard and should be flexible enough to achieve it.
Generally, people come to from But that might be a good thing to add it.
Also, I don't think this can be a rustdoc thing, because many, many rustdoc outputs are not hosted on rust-
(Rustdoc already lets you choose where the logo links to, iiirc, but it's usually the docs rather than another site.)
I'm not saying rustdoc should hard-code a link to If you write a Rust library and publicize its documentation, you might want a backlink from the generated HTML to I'm claiming there should be a general mechanism to realize such designs. Thankfully rustdoc supports these command line options which seem promising: I'll try see how they fit my proposal.
now links to , many times
Oh wait, this is the inverse issue, sorry for the noise! There hasn't been any change here.
Triage: may fix this, but there's been no change
redirects to today, but I think we probably want these links from e.g. as well so leaving open.
Triage: this would be pretty easily fixed by modifying the index page for

Discussion:
} </style> <del> Welcome to an overview of the documentation provided by the Rust project. </del> <ins> Welcome to an overview of the documentation provided by the [Rust project]. </ins> All of these projects are managed by the Docs Team; there are other unofficial documentation resources as well!

[The Embedded Rust Book] is targeted at developers familiar with embedded development and familiar with Rust, but have not used Rust for embedded development. [The Embedded Rust Book]: embedded-book/index.html <ins> [Rust project]: https://www.rust-lang.org </ins>
Change:
In , changed the encoding of from serializing the value as a single into serializing two sequential values. Unfortunately this violates the serialization protocol, and causes a span like to be serialized as . Here's the current implementation: Semantically speaking these spans should be serialized as a tuple, which would properly delimit the two values, but since that'd add a bunch of tagging overhead to the output, it'd probably be more efficient to just restore the old encoding:

Discussion:
impl Encodable for Span { fn encode<S: Encoder>(&self, s: &mut S) -> Result<(), S::Error> { <del> try!(s.emit_u32(self.lo.0)); s.emit_u32(self.hi.0) </del> <ins> s.emit_struct("Span", 2, |s| { try!(s.emit_struct_field("lo", 0, |s| { self.lo.encode(s) })); s.emit_struct_field("hi", 1, |s| { self.hi.encode(s) }) }) </ins> } } impl Decodable for Span { fn decode<D: Decoder>(d: &mut D) -> Result<Span, D::Error> { <del> let lo = BytePos(try! { d.read_u32() }); let hi = BytePos(try! { d.read_u32() }); Ok(mk_sp(lo, hi)) </del> <ins> d.read_struct("Span", 2, |d| { let lo = try!(d.read_struct_field("lo", 0, |d| { BytePos::decode(d) })); let hi = try!(d.read_struct_field("hi", 1, |d| { BytePos::decode(d) })); Ok(mk_sp(lo, hi)) }) </ins> } }
Change:
By escaped, I mean stuff like which renders fine in non-search listings (it looks like , instead of a literal iframe element on the page).
I thought we had an issue for this, but cannot find it.
Relevant to inline summary rendering:
Search result descriptions aren't markdown rendered and read/written unaltered from the search-index to the page. Should these descriptions be markdown rendered or html escaped ()?

Discussion:
ty: shortty(item), name: item.name.clone().unwrap(), path: fqp[..fqp.len() - 1].join("::"), <del> desc: shorter(item.doc_value()), </del> <ins> desc: Escape(&shorter(item.doc_value())).to_string(), </ins> parent: Some(did), search_type: get_index_search_type(&item, parent_basename), });

ty: shortty(&item), name: s.to_string(), path: path.join("::").to_string(), <del> desc: shorter(item.doc_value()), </del> <ins> desc: Escape(&shorter(item.doc_value())).to_string(), </ins> parent: parent, search_type: get_index_search_type(&item, parent_basename), });
Change:
This transmutes an to... an ! A more realistic example might be to transmute a byte array to a packed struct.
part of
I took a stab at this:

Discussion:
/// ``` /// use std::mem; /// <del> /// let one = unsafe { mem::transmute_copy(&1) }; </del> <ins> /// #[repr(packed)] /// struct Foo { ///     bar: u8, /// } /// /// let foo_slice = [10u8]; /// /// unsafe { ///     // Copy the data from 'foo_slice' and treat it as a 'Foo' ///     let mut foo_struct: Foo = mem::transmute_copy(&foo_slice); ///     assert_eq!(foo_struct.bar, 10); /// ///     // Modify the copied data ///     foo_struct.bar = 20; ///     assert_eq!(foo_struct.bar, 20); /// } </ins> /// <del> /// assert_eq!(1, one); </del> <ins> /// // The contents of 'foo_slice' should not have changed /// assert_eq!(foo_slice, [10]); </ins> /// ``` #[inline] #[stable(feature = "rust1", since = "1.0.0")]
Change:
subj
Tagging as as should be a pretty good first bug to tackle for libstd!
Going to give this a shot! One question, given that is sort of a non-error (at least according to ), will returning/writing "parse error" be enough to satisfy and ?
ok! Yeah it should be fine to just ensure that something semi-reasonable comes out, it's more likely the case that just having these traits implemented is useful rather than ensuring the implementations themselves are useful :)
Since it's a void enum, you can use the same implementation as clone does in fact: It handles the enum exhaustively (as match forces you to) and makes sure all possible cases (zero cases) are handled. !
PR is up!

Discussion:
} } <ins> #[stable(feature = "str_parse_error2", since = "1.8.0")] impl fmt::Display for ParseError { fn fmt(&self, _: &mut fmt::Formatter) -> fmt::Result { match *self {} } } </ins> #[stable(feature = "str_parse_error", since = "1.5.0")] impl PartialEq for ParseError { fn eq(&self, _: &ParseError) -> bool {

} } <ins> #[stable(feature = "str_parse_error2", since = "1.8.0")] impl Error for string::ParseError { fn description(&self) -> &str { match *self {} } } </ins> // copied from any.rs impl Error + 'static { /// Returns true if the boxed type is the same as `T`