jiebi/CodeConvo huggingface dataset:
Code change:
cc Maybe related to
Also affects eclectica-0.0.9 cc
Also igo-0.2.1 cc
Also isbfc-0.0.1 cc
Also cargo-update-0.8.0 () cc
Also cc
Rust commit: (looks like bug isn't here) Cargo commit: , which seems correct. is the stable/nightly issue, is the PR updating cargo submodule to fix this, which probably needs to be backported to beta. I'm uncertain, though.
cc sorry to tag you in again, but if you could help take a look at this that'd be great! If not no worries!
Hi this definitely looks related to my changes in cargo. I've investigated and this crate defines two bins ( and ). I suppose they were intended to be aliases and this was possible because of a original "bug" in cargo (falling back to ). I have mixed feelings about this. I would say that cargo should fail here instead of falling back to , but I suppose we cannot do that because of backwards compatibility. Right? fails because it defines bin targets inside directly, instead of . Seems easy and I'll try to fix this today in the evening. Could you please provide me with the cargo's output for the other crates (especially )? That would be great.
Ah yeah for now our priority is to stem the breakage, and afterwards we can evaluate warnings cycles/etc to push further towards the desired behavior here. Thanks for investigating this
I think I have fixed this, just need one more day to do some more testing and I should open a pull request tomorrow.
Added a proposed fix.
Ah we should actually leave this open to track the inclusion into beta, I'll close when all the backports are done.
Ok I've , updated our and updated our , this'll get closed when those start merging. Thanks again for fixing this
Ok, I think everything's landed here

Related discussion:
text: let path = @{span: span, global: false, idents: ~[nm], rp: None, types: ~[]}; @{id: self.next_id(), <del> node: ast::pat_ident(ast::bind_by_implicit_ref, </del> <ins> node: ast::pat_ident(ast::bind_by_ref(ast::m_imm), </ins> path, None), span: span}
Code change:
cc Maybe related to
Also affects eclectica-0.0.9 cc
Also igo-0.2.1 cc
Also isbfc-0.0.1 cc
Also cargo-update-0.8.0 () cc
Also cc
Rust commit: (looks like bug isn't here) Cargo commit: , which seems correct. is the stable/nightly issue, is the PR updating cargo submodule to fix this, which probably needs to be backported to beta. I'm uncertain, though.
cc sorry to tag you in again, but if you could help take a look at this that'd be great! If not no worries!
Hi this definitely looks related to my changes in cargo. I've investigated and this crate defines two bins ( and ). I suppose they were intended to be aliases and this was possible because of a original "bug" in cargo (falling back to ). I have mixed feelings about this. I would say that cargo should fail here instead of falling back to , but I suppose we cannot do that because of backwards compatibility. Right? fails because it defines bin targets inside directly, instead of . Seems easy and I'll try to fix this today in the evening. Could you please provide me with the cargo's output for the other crates (especially )? That would be great.
Ah yeah for now our priority is to stem the breakage, and afterwards we can evaluate warnings cycles/etc to push further towards the desired behavior here. Thanks for investigating this
I think I have fixed this, just need one more day to do some more testing and I should open a pull request tomorrow.
Added a proposed fix.
Ah we should actually leave this open to track the inclusion into beta, I'll close when all the backports are done.
Ok I've , updated our and updated our , this'll get closed when those start merging. Thanks again for fixing this
Ok, I think everything's landed here

Related discussion:
text: let pat_node = if pats.is_empty() { ast::pat_ident( <del> ast::bind_by_implicit_ref, </del> <ins> ast::bind_by_ref(ast::m_imm), </ins> cx.path(span, ~[v_name]), None )
Code change:
cc Maybe related to
Also affects eclectica-0.0.9 cc
Also igo-0.2.1 cc
Also isbfc-0.0.1 cc
Also cargo-update-0.8.0 () cc
Also cc
Rust commit: (looks like bug isn't here) Cargo commit: , which seems correct. is the stable/nightly issue, is the PR updating cargo submodule to fix this, which probably needs to be backported to beta. I'm uncertain, though.
cc sorry to tag you in again, but if you could help take a look at this that'd be great! If not no worries!
Hi this definitely looks related to my changes in cargo. I've investigated and this crate defines two bins ( and ). I suppose they were intended to be aliases and this was possible because of a original "bug" in cargo (falling back to ). I have mixed feelings about this. I would say that cargo should fail here instead of falling back to , but I suppose we cannot do that because of backwards compatibility. Right? fails because it defines bin targets inside directly, instead of . Seems easy and I'll try to fix this today in the evening. Could you please provide me with the cargo's output for the other crates (especially )? That would be great.
Ah yeah for now our priority is to stem the breakage, and afterwards we can evaluate warnings cycles/etc to push further towards the desired behavior here. Thanks for investigating this
I think I have fixed this, just need one more day to do some more testing and I should open a pull request tomorrow.
Added a proposed fix.
Ah we should actually leave this open to track the inclusion into beta, I'll close when all the backports are done.
Ok I've , updated our and updated our , this'll get closed when those start merging. Thanks again for fixing this
Ok, I think everything's landed here

Related discussion:
text: <ins> #[forbid(deprecated_pattern)]; </ins> extern mod std; // These tests used to be separate files, but I wanted to refactor all
Code change:
cc Maybe related to
Also affects eclectica-0.0.9 cc
Also igo-0.2.1 cc
Also isbfc-0.0.1 cc
Also cargo-update-0.8.0 () cc
Also cc
Rust commit: (looks like bug isn't here) Cargo commit: , which seems correct. is the stable/nightly issue, is the PR updating cargo submodule to fix this, which probably needs to be backported to beta. I'm uncertain, though.
cc sorry to tag you in again, but if you could help take a look at this that'd be great! If not no worries!
Hi this definitely looks related to my changes in cargo. I've investigated and this crate defines two bins ( and ). I suppose they were intended to be aliases and this was possible because of a original "bug" in cargo (falling back to ). I have mixed feelings about this. I would say that cargo should fail here instead of falling back to , but I suppose we cannot do that because of backwards compatibility. Right? fails because it defines bin targets inside directly, instead of . Seems easy and I'll try to fix this today in the evening. Could you please provide me with the cargo's output for the other crates (especially )? That would be great.
Ah yeah for now our priority is to stem the breakage, and afterwards we can evaluate warnings cycles/etc to push further towards the desired behavior here. Thanks for investigating this
I think I have fixed this, just need one more day to do some more testing and I should open a pull request tomorrow.
Added a proposed fix.
Ah we should actually leave this open to track the inclusion into beta, I'll close when all the backports are done.
Ok I've , updated our and updated our , this'll get closed when those start merging. Thanks again for fixing this
Ok, I think everything's landed here

Related discussion:
text: let ebml_w = &EBWriter::Serializer(wr); a1.serialize(ebml_w) }; <del> let d = EBReader::Doc(@bytes); </del> <ins> let d = EBReader::Doc(@move bytes); </ins> let a2: A = deserialize(&EBReader::Deserializer(d)); assert *a1 == a2; }
Code change:
About to submit a PR for exposing intrinsics::needs_drop under mem. Needs a tracking issue. Here it is!
The PR is
fcp merge Seems like this may be good to stabilize!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.

Related discussion:
text: #![feature(core_intrinsics)] #![feature(dropck_eyepatch)] #![feature(generic_param_attrs)] <del> #![feature(needs_drop)] </del> #![cfg_attr(test, feature(test))] #![allow(deprecated)]
Code change:
About to submit a PR for exposing intrinsics::needs_drop under mem. Needs a tracking issue. Here it is!
The PR is
fcp merge Seems like this may be good to stabilize!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.

Related discussion:
text: /// Here's an example of how a collection might make use of needs_drop: /// /// ``` <del> /// #![feature(needs_drop)] </del> /// use std::{mem, ptr}; /// /// pub struct MyCollection<T> {
Code change:
About to submit a PR for exposing intrinsics::needs_drop under mem. Needs a tracking issue. Here it is!
The PR is
fcp merge Seems like this may be good to stabilize!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.

Related discussion:
text: /// } /// ``` #[inline] <del> #[unstable(feature = "needs_drop", issue = "41890")] </del> <ins> #[stable(feature = "needs_drop", since = "1.22.0")] </ins> pub fn needs_drop<T>() -> bool { unsafe { intrinsics::needs_drop::<T>() } }
Code change:
About to submit a PR for exposing intrinsics::needs_drop under mem. Needs a tracking issue. Here it is!
The PR is
fcp merge Seems like this may be good to stabilize!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.

Related discussion:
text: #![feature(macro_reexport)] #![feature(macro_vis_matcher)] #![feature(needs_panic_runtime)] <del> #![feature(needs_drop)] </del> #![feature(never_type)] #![feature(num_bits_bytes)] #![feature(old_wrapping)]
Code change:
Test case: Compiling this stuck forever in the "expansion" pass. cc ( tracking issue). Since can match "nothing", the macro should error with "repetition matches empty token tree".

Related discussion:
text: TokenTree::Sequence(span, ref seq) => { if seq.separator.is_none() && seq.tts.iter().all(|seq_tt| { match *seq_tt { <ins> TokenTree::MetaVarDecl(_, _, id) => id.name == "vis", </ins> TokenTree::Sequence(_, ref sub_seq) => sub_seq.op == quoted::KleeneOp::ZeroOrMore, _ => false,
Code change:
Test case: Compiling this stuck forever in the "expansion" pass. cc ( tracking issue). Since can match "nothing", the macro should error with "repetition matches empty token tree".

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(macro_vis_matcher)] macro_rules! foo { ($($p:vis)*) => {} //~ ERROR repetition matches empty token tree } foo!(a); </ins>
Code change:
The fix is shown in , but I couldn't complete it because the line length linter doesn't like the long lines and didn't have enough time to adjust the tidy checker

Related discussion:
text: trait_obj.method_two(); ``` <del> You can read more about trait objects in the Trait Object section of the Reference: </del> <ins> You can read more about trait objects in the [Trait Objects] section of the Reference. </ins> <del> https://doc.rust-lang.org/reference.html#trait-objects </del> <ins> [Trait Objects]: https://doc.rust-lang.org/reference/types.html#trait-objects </ins> "##, E0034: r##"
Code change:
The fix is shown in , but I couldn't complete it because the line length linter doesn't like the long lines and didn't have enough time to adjust the tidy checker

Related discussion:
text: optional namespacing), a dereference, an indexing expression or a field reference. <del> More details can be found here: https://doc.rust-lang.org/reference.html#lvalues-rvalues-and-temporaries </del> <ins> More details can be found in the [Expressions] section of the Reference. [Expressions]: https://doc.rust-lang.org/reference/expressions.html#lvalues-rvalues-and-temporaries </ins> Now, we can go further. Here are some erroneous code examples:
Code change:
The fix is shown in , but I couldn't complete it because the line length linter doesn't like the long lines and didn't have enough time to adjust the tidy checker

Related discussion:
text: } ``` <del> PhantomData can also be used to express information about unused type parameters. You can read more about it in the API documentation: </del> <ins> [PhantomData] can also be used to express information about unused type parameters. </ins> <del> https://doc.rust-lang.org/std/marker/struct.PhantomData.html </del> <ins> [PhantomData]: https://doc.rust-lang.org/std/marker/struct.PhantomData.html </ins> "##, E0393: r##"
Code change:
The fix is shown in , but I couldn't complete it because the line length linter doesn't like the long lines and didn't have enough time to adjust the tidy checker

Related discussion:
text: println!("x: {}, y: {}", variable.x, variable.y); ``` <del> For more information see The Rust Book: https://doc.rust-lang.org/book/ </del> <ins> For more information about primitives and structs, take a look at The Book: https://doc.rust-lang.org/book/first-edition/primitive-types.html https://doc.rust-lang.org/book/first-edition/structs.html </ins> "##, E0611: r##"
Code change:
The fix is shown in , but I couldn't complete it because the line length linter doesn't like the long lines and didn't have enough time to adjust the tidy checker

Related discussion:
text: } ``` <del> To fix this error, you need to pass variables corresponding to C types as much as possible. For better explanations, see The Rust Book: https://doc.rust-lang.org/book/ </del> <ins> Certain Rust types must be cast before passing them to a variadic function, because of arcane ABI rules dictated by the C standard. To fix the error, cast the value to the type specified by the error message (which you may need to import from `std::os::raw`). </ins> "##, E0618: r##"
Code change:
After discussing it on the forums I bit I decided to look into what the optimizer spends time on, and inlining seems to be a significant part of it. There seems to be a lot of room for improvement here. Tested by compiling syntex in rustc-benchmarks (though the inlining time seem quite significant in other crates as well.). I counted which functions were inlined the most, and and to a lesser extent , which are when automatically deriving , and which simply wrap two other functions inside fmt::builder show up a lot. Maybe derive(debug) could output the wrapped functions instead, or the equivalent code, so llvm doesn't have to spend time inlining them (unless this causes problems for debug info). is also inlined a lot, and also plays a role in derive(Debug). Maybe something could be done about that one as well, as it's that creates a struct but doesn't do anything else. <details<summaryOutput from time-llvm-passes</summaryUsing in the syntex-0.42.2 directory in rustc-benchmarks. It's a bit hard to say which crate is which, as the output from llvm and cargo isn't synced, though these are the bottom three (excluding the benchmark dummy) in reverse order: </details<details<summaryMost inlined functions: </summaryRunning , and filtering the output using this: (Yeah it's a bit of a monstrosity, and takes a long time, maybe I could look into making some tool analyze this if it turns out to be useful.) gives: <pre1865 ZN4core3ptr13dropinplace17hffb7ed55089717f8E inlined into 917 ZN50Tascore..convert..FromTGT$4from17h99c56b7d2123957eE inlined into <b677 ZN4core3fmt9Arguments6newv117h0a32116e8ade096aE inlined into</b549 ZN4core3ptr13dropinplace17h8905708a4bea3261E inlined into <b517 ZN4core3fmt9Formatter11debugtuple17h312acfb009988478E inlined into</b484 ZN50Tascore..convert..FromTGT$4from17hf6536c6dc214691bE inlined into 438 ZN5alloc9allocator6Layout4size17h278602cb6317171dE inlined into 402 ZN63alloc..allocator..LayoutasGT$5clone17hba86f6db001903cdE inlined into 381 ZN61u20u20GT$7dealloc17h3db9762b4fdfd21eE inlined into 344 ZN5alloc4heap15exchangemalloc17he9800f033a6330e4E inlined into 341 ZN4core3ptr13dropinplace17hb5325e51b98a161aE inlined into ... <b82 ZN4core3fmt9Formatter12debug_struct17h5cfb920e90696799E inlined into</b... </pre</details<details<summaryrustc --version</summary</details
We should just drop the from those functions - debug printing is something we want to be optimizing on code size/compile time rather than perf.
Yup, that's a good point. EDIT: Actually since they're just generic over lifetimes it looks like that's not an issue.

Related discussion:
text: /// println!("{:?}", Foo { bar: 10, baz: "Hello World".to_string() }); /// ``` #[stable(feature = "debug_builders", since = "1.2.0")] <del> #[inline] </del> pub fn debug_struct<'b>(&'b mut self, name: &str) -> DebugStruct<'b, 'a> { builders::debug_struct_new(self, name) }
Code change:
After discussing it on the forums I bit I decided to look into what the optimizer spends time on, and inlining seems to be a significant part of it. There seems to be a lot of room for improvement here. Tested by compiling syntex in rustc-benchmarks (though the inlining time seem quite significant in other crates as well.). I counted which functions were inlined the most, and and to a lesser extent , which are when automatically deriving , and which simply wrap two other functions inside fmt::builder show up a lot. Maybe derive(debug) could output the wrapped functions instead, or the equivalent code, so llvm doesn't have to spend time inlining them (unless this causes problems for debug info). is also inlined a lot, and also plays a role in derive(Debug). Maybe something could be done about that one as well, as it's that creates a struct but doesn't do anything else. <details<summaryOutput from time-llvm-passes</summaryUsing in the syntex-0.42.2 directory in rustc-benchmarks. It's a bit hard to say which crate is which, as the output from llvm and cargo isn't synced, though these are the bottom three (excluding the benchmark dummy) in reverse order: </details<details<summaryMost inlined functions: </summaryRunning , and filtering the output using this: (Yeah it's a bit of a monstrosity, and takes a long time, maybe I could look into making some tool analyze this if it turns out to be useful.) gives: <pre1865 ZN4core3ptr13dropinplace17hffb7ed55089717f8E inlined into 917 ZN50Tascore..convert..FromTGT$4from17h99c56b7d2123957eE inlined into <b677 ZN4core3fmt9Arguments6newv117h0a32116e8ade096aE inlined into</b549 ZN4core3ptr13dropinplace17h8905708a4bea3261E inlined into <b517 ZN4core3fmt9Formatter11debugtuple17h312acfb009988478E inlined into</b484 ZN50Tascore..convert..FromTGT$4from17hf6536c6dc214691bE inlined into 438 ZN5alloc9allocator6Layout4size17h278602cb6317171dE inlined into 402 ZN63alloc..allocator..LayoutasGT$5clone17hba86f6db001903cdE inlined into 381 ZN61u20u20GT$7dealloc17h3db9762b4fdfd21eE inlined into 344 ZN5alloc4heap15exchangemalloc17he9800f033a6330e4E inlined into 341 ZN4core3ptr13dropinplace17hb5325e51b98a161aE inlined into ... <b82 ZN4core3fmt9Formatter12debug_struct17h5cfb920e90696799E inlined into</b... </pre</details<details<summaryrustc --version</summary</details
We should just drop the from those functions - debug printing is something we want to be optimizing on code size/compile time rather than perf.
Yup, that's a good point. EDIT: Actually since they're just generic over lifetimes it looks like that's not an issue.

Related discussion:
text: /// println!("{:?}", Foo(10, "Hello World".to_string())); /// ``` #[stable(feature = "debug_builders", since = "1.2.0")] <del> #[inline] </del> pub fn debug_tuple<'b>(&'b mut self, name: &str) -> DebugTuple<'b, 'a> { builders::debug_tuple_new(self, name) }