jiebi/CodeConvo huggingface dataset:
Code change:
this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `

Related discussion:
text: let (span, e) = self.interpolated_or_expr_span(e)?; (lo.to(span), ExprKind::Box(e)) } <del> _ => return self.parse_dot_or_call_expr(Some(attrs)) </del> <ins> token::Ident(..) if self.token.is_ident_named("not") => { // `not` is just an ordinary identifier in Rust-the-language, // but as `rustc`-the-compiler, we can issue clever diagnostics // for confused users who really want to say `!` let token_cannot_continue_expr = |t: &token::Token| match *t { // These tokens can start an expression after `!`, but // can't continue an expression after an ident token::Ident(ident, is_raw) => token::ident_can_begin_expr(ident, is_raw), token::Literal(..) | token::Pound => true, token::Interpolated(ref nt) => match nt.0 { token::NtIdent(..) | token::NtExpr(..) | token::NtBlock(..) | token::NtPath(..) => true, _ => false, }, _ => false }; let cannot_continue_expr = self.look_ahead(1, token_cannot_continue_expr); if cannot_continue_expr { self.bump(); // Emit the error ... let mut err = self.diagnostic() .struct_span_err(self.span, &format!("unexpected {} after identifier", self.this_token_descr())); // span the `not` plus trailing whitespace to avoid // trailing whitespace after the `!` in our suggestion let to_replace = self.sess.codemap() .span_until_non_whitespace(lo.to(self.span)); err.span_suggestion_short(to_replace, "use `!` to perform logical negation", "!".to_owned()); err.emit(); // —and recover! (just as if we were in the block // for the `token::Not` arm) let e = self.parse_prefix_expr(None); let (span, e) = self.interpolated_or_expr_span(e)?; (lo.to(span), self.mk_unary(UnOp::Not, e)) } else { return self.parse_dot_or_call_expr(Some(attrs)); } } _ => { return self.parse_dot_or_call_expr(Some(attrs)); } </ins> }; return Ok(self.mk_expr(lo.to(hi), ex, attrs)); }
Code change:
this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `

Related discussion:
text: // Which is valid in other languages, but not Rust. match self.parse_stmt_without_recovery(false) { Ok(Some(stmt)) => { <ins> if self.look_ahead(1, |t| t == &token::OpenDelim(token::Brace)) { // if the next token is an open brace (e.g., `if a b {`), the place- // inside-a-block suggestion would be more likely wrong than right return Err(e); } </ins> let mut stmt_span = stmt.span; // expand the span to include the semicolon, if it exists if self.eat(&token::Semi) {
Code change:
this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `

Related discussion:
text: } } <del> fn ident_can_begin_expr(ident: ast::Ident, is_raw: bool) -> bool { </del> <ins> pub(crate) fn ident_can_begin_expr(ident: ast::Ident, is_raw: bool) -> bool { </ins> let ident_token: Token = Ident(ident, is_raw); !ident_token.is_reserved_ident() ||
Code change:
this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `

Related discussion:
text: self.lifetime().is_some() } <ins> /// Returns `true` if the token is a identifier whose name is the given /// string slice. pub fn is_ident_named(&self, name: &str) -> bool { match self.ident() { Some((ident, _)) => ident.name.as_str() == name, None => false } } </ins> /// Returns `true` if the token is a documentation comment. pub fn is_doc_comment(&self) -> bool { match *self {
Code change:
this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `

Related discussion:
text: <ins> // Copyright 2018 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 gratitude() { let for_you = false; if not for_you { //~^ ERROR unexpected `for_you` after identifier println!("I couldn't"); } } fn qualification() { let the_worst = true; while not the_worst { //~^ ERROR unexpected `the_worst` after identifier println!("still pretty bad"); } } fn should_we() { let not = true; if not  // lack of braces is [sic] println!("Then when?"); //~^ ERROR expected `{`, found `; //~| ERROR unexpected `println` after identifier } fn sleepy() { let resource = not 2; //~^ ERROR unexpected `2` after identifier } fn main() { let be_smothered_out_before = true; let young_souls = not be_smothered_out_before; //~^ ERROR unexpected `be_smothered_out_before` after identifier } </ins>
Code change:
this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `

Related discussion:
text: <ins> error: unexpected `for_you` after identifier --> $DIR/issue-46836-identifier-not-instead-of-negation.rs:13:12 | LL |     if not for_you { |        ----^^^^^^^ |        | |        help: use `!` to perform logical negation error: unexpected `the_worst` after identifier --> $DIR/issue-46836-identifier-not-instead-of-negation.rs:21:15 | LL |     while not the_worst { |           ----^^^^^^^^^ |           | |           help: use `!` to perform logical negation error: unexpected `println` after identifier --> $DIR/issue-46836-identifier-not-instead-of-negation.rs:30:9 | LL |     if not  // lack of braces is [sic] |        ----- help: use `!` to perform logical negation LL |         println!("Then when?"); |         ^^^^^^^ error: expected `{`, found `;` --> $DIR/issue-46836-identifier-not-instead-of-negation.rs:30:31 | LL |     if not  // lack of braces is [sic] |     -- this `if` statement has a condition, but no block LL |         println!("Then when?"); |                               ^ error: unexpected `2` after identifier --> $DIR/issue-46836-identifier-not-instead-of-negation.rs:36:24 | LL |     let resource = not 2; |                    ----^ |                    | |                    help: use `!` to perform logical negation error: unexpected `be_smothered_out_before` after identifier --> $DIR/issue-46836-identifier-not-instead-of-negation.rs:42:27 | LL |     let young_souls = not be_smothered_out_before; |                       ----^^^^^^^^^^^^^^^^^^^^^^^ |                       | |                       help: use `!` to perform logical negation error: aborting due to 6 previous errors </ins>
Code change:
If a procedural macro generates an access to a named struct field like then the may be either defsite or callsite and it works either way. But if accessing an unnamed tuple struct field like then it only works if is call_site. I believe it should work either way in either case.
Sorry for the delay! Fixed in .

Related discussion:
text: // A tuple index may not have a suffix self.expect_no_suffix(sp, "tuple index", suf); <del> let dot_span = self.prev_span; hi = self.span; </del> <ins> let idx_span = self.span; </ins> self.bump(); let invalid_msg = "invalid tuple or struct index";
Code change:
If a procedural macro generates an access to a named struct field like then the may be either defsite or callsite and it works either way. But if accessing an unnamed tuple struct field like then it only works if is call_site. I believe it should work either way in either case.
Sorry for the delay! Fixed in .

Related discussion:
text: n.to_string()); err.emit(); } <del> let id = respan(dot_span.to(hi), n); let field = self.mk_tup_field(e, id); e = self.mk_expr(lo.to(hi), field, ThinVec::new()); </del> <ins> let field = self.mk_tup_field(e, respan(idx_span, n)); e = self.mk_expr(lo.to(idx_span), field, ThinVec::new()); </ins> } None => { let prev_span = self.prev_span;
Code change:
If a procedural macro generates an access to a named struct field like then the may be either defsite or callsite and it works either way. But if accessing an unnamed tuple struct field like then it only works if is call_site. I believe it should work either way in either case.
Sorry for the delay! Fixed in .

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. // ignore-pretty pretty-printing is unhygienic #![feature(decl_macro)] #![allow(unused)] mod foo { pub macro m($s:tt, $i:tt) { $s.$i } } mod bar { struct S(i32); fn f() { let s = S(0); ::foo::m!(s, 0); } } fn main() {} </ins>
Code change:
I'd like to work on this.
This appears to be a regular error, not an ICE.

Related discussion:
text: use rustc::mir::{BasicBlock, Location, Mir}; use rustc::mir::Local; use rustc::ty::{self, Ty, TyCtxt, TypeFoldable}; <ins> use rustc::traits; use rustc::infer::InferOk; </ins> use rustc::util::common::ErrorReported; <ins> use borrow_check::nll::type_check::AtLocation; </ins> use rustc_data_structures::fx::FxHashSet; use syntax::codemap::DUMMY_SP; use util::liveness::LivenessResults;
Code change:
I'd like to work on this.
This appears to be a regular error, not an ICE.

Related discussion:
text: <ins> // Copyright 2018 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(nll)] pub struct DescriptorSet<'a> { pub slots: Vec<AttachInfo<'a, Resources>> } pub trait ResourcesTrait<'r>: Sized { type DescriptorSet: 'r; } pub struct Resources; impl<'a> ResourcesTrait<'a> for Resources { type DescriptorSet = DescriptorSet<'a>; } pub enum AttachInfo<'a, R: ResourcesTrait<'a>> { NextDescriptorSet(Box<R::DescriptorSet>) } fn main() { let _x = DescriptorSet {slots: Vec::new()}; } </ins>
Code change:
/ and / do the same thing.
So, should registertask/unregistertask then be exposed in rust_builtin so it can be called from Rust?
Yes, though I suggest renaming it, since it will no longer just be used for 'registering', nor does it strictly have anything to do with tasks or weak tasks from the kernel's perspective - this count is only for determining when to shutdown the runtime. Maybe for the method name and for the builtin. It's not great either, but is less wed to implementation details.

Related discussion:
text: let task = get_task_id(); // Expect the weak task service to be alive assert service.try_send(RegisterWeakTask(task, shutdown_chan)); <del> unsafe { rust_inc_kernel_live_count(); } </del> <ins> unsafe { rust_dec_kernel_live_count(); } </ins> do fn&() { let shutdown_port = swap_unwrap(&mut *shutdown_port); f(shutdown_port) }.finally || { <del> unsafe { rust_dec_kernel_live_count(); } </del> <ins> unsafe { rust_inc_kernel_live_count(); } </ins> // Service my have already exited service.send(UnregisterWeakTask(task)); }
Code change:
/ and / do the same thing.
So, should registertask/unregistertask then be exposed in rust_builtin so it can be called from Rust?
Yes, though I suggest renaming it, since it will no longer just be used for 'registering', nor does it strictly have anything to do with tasks or weak tasks from the kernel's perspective - this count is only for determining when to shutdown the runtime. Maybe for the method name and for the builtin. It's not great either, but is less wed to implementation details.

Related discussion:
text: let port = swap_unwrap(&mut *port); // The weak task service is itself a weak task debug!("weakening the weak service task"); <del> unsafe { rust_inc_kernel_live_count(); } </del> <ins> unsafe { rust_dec_kernel_live_count(); } </ins> run_weak_task_service(port); }.finally { debug!("unweakening the weak service task"); <del> unsafe { rust_dec_kernel_live_count(); } </del> <ins> unsafe { rust_inc_kernel_live_count(); } </ins> } }
Code change:
Do you have a testcase that reproduces this problem? Also, what version of rustc are you using?
I'm sorry late for your comment. $ rustc this is bad my code. : : rustc 0.6 ( 2013-01-20 20:35:24 -0800)
From my cursory glance, multibyte characters (Hangul in this case) seem to cause this bug.
Not critical for 0.6; removing milestone
Seems to be fixed. Checking in a test case.
Done pending
Test case in , closing

Related discussion:
text: <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 multibyte characters don't crash the compiler fn main() { io::println("마이너스 사인이 없으면"); } </ins>
Code change:
This is a tracking issue for the RFC "Type privacy and private-in-public lints " (rust-lang/rfcs). Steps: [ ] Implement the RFC (cc ) [ ] Adjust documentation ([see instructions on forge][doc-guide]) [ ] Stabilization PR ([see instructions on forge][stabilization-guide]) [stabilization-guide]: [doc-guide]: Unresolved questions: [ ] It's not fully clear if the restriction for associated type definitions required for type privacy soundness, or it's just a workaround for a technical difficulty. [ ] Interactions between macros 2.0 and the notions of reachability / effective visibility used for the lints are unclear. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oops - I didn't mean for that to un-assign you. Is there a way to prevent these lints from becoming insta-stable? Would it make sense to put them behind a feature gate?
Perhaps we could only fire the lints if an unstable compiler flag (maybe ) is passed? This would still make the lint names insta-stable, though.
in core ffi There is a fixme about , how to fixes that?
By implementing this RFC, I guess. Until that workarounds like this sealed trait will need to be used.
Where is the impl, the RFC is already accepted...
An RFC being accepted just means the feature can be implemented, not that it has been implemented. It doesn't even mean that implementing it is a priority. I believe there has been more discussion of this RFC over at as well as other issues that I can't seem to track down right now.
Hello! I know y'all are busy, but I'm curious if there's an update, particularly on for Voldemort Types - which I'd love to see. I was actually a bit surprised to find that it wasn't included in the existing lint. Appreciate the work that y'all are doing, especially who seems to have put in a lot of legwork.
The tentative plan is that will work on this in March-May.
Cool! Good luck! I'm happy to be a guinea pig to try it out or do code review if that would be helpful.
This issue should be closed by Two follow up issues about improving the effective visibility tables

Related discussion:
text: (accepted, type_alias_enum_variants, "1.37.0", Some(49683)), /// Allows macros to appear in the type position. (accepted, type_macros, "1.13.0", Some(27245)), <ins> /// Allows using type privacy lints (`private_interfaces`, `private_bounds`, `unnameable_types`). (accepted, type_privacy_lints, "CURRENT_RUSTC_VERSION", Some(48054)), </ins> /// Allows `const _: TYPE = VALUE`. (accepted, underscore_const_names, "1.37.0", Some(54912)), /// Allows `use path as _;` and `extern crate c as _;`.
Code change:
This is a tracking issue for the RFC "Type privacy and private-in-public lints " (rust-lang/rfcs). Steps: [ ] Implement the RFC (cc ) [ ] Adjust documentation ([see instructions on forge][doc-guide]) [ ] Stabilization PR ([see instructions on forge][stabilization-guide]) [stabilization-guide]: [doc-guide]: Unresolved questions: [ ] It's not fully clear if the restriction for associated type definitions required for type privacy soundness, or it's just a workaround for a technical difficulty. [ ] Interactions between macros 2.0 and the notions of reachability / effective visibility used for the lints are unclear. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oops - I didn't mean for that to un-assign you. Is there a way to prevent these lints from becoming insta-stable? Would it make sense to put them behind a feature gate?
Perhaps we could only fire the lints if an unstable compiler flag (maybe ) is passed? This would still make the lint names insta-stable, though.
in core ffi There is a fixme about , how to fixes that?
By implementing this RFC, I guess. Until that workarounds like this sealed trait will need to be used.
Where is the impl, the RFC is already accepted...
An RFC being accepted just means the feature can be implemented, not that it has been implemented. It doesn't even mean that implementing it is a priority. I believe there has been more discussion of this RFC over at as well as other issues that I can't seem to track down right now.
Hello! I know y'all are busy, but I'm curious if there's an update, particularly on for Voldemort Types - which I'd love to see. I was actually a bit surprised to find that it wasn't included in the existing lint. Appreciate the work that y'all are doing, especially who seems to have put in a lot of legwork.
The tentative plan is that will work on this in March-May.
Cool! Good luck! I'm happy to be a guinea pig to try it out or do code review if that would be helpful.
This issue should be closed by Two follow up issues about improving the effective visibility tables

Related discussion:
text: /// Allows creation of instances of a struct by moving fields that have /// not changed from prior instances of the same struct (RFC #2528) (unstable, type_changing_struct_update, "1.58.0", Some(86555)), <del> /// Allows using type privacy lints (`private_interfaces`, `private_bounds`, `unnameable_types`). (unstable, type_privacy_lints, "1.72.0", Some(48054)), </del> /// Enables rustc to generate code that instructs libstd to NOT ignore SIGPIPE. (unstable, unix_sigpipe, "1.65.0", Some(97889)), /// Allows unnamed fields of struct and union type
Code change:
This is a tracking issue for the RFC "Type privacy and private-in-public lints " (rust-lang/rfcs). Steps: [ ] Implement the RFC (cc ) [ ] Adjust documentation ([see instructions on forge][doc-guide]) [ ] Stabilization PR ([see instructions on forge][stabilization-guide]) [stabilization-guide]: [doc-guide]: Unresolved questions: [ ] It's not fully clear if the restriction for associated type definitions required for type privacy soundness, or it's just a workaround for a technical difficulty. [ ] Interactions between macros 2.0 and the notions of reachability / effective visibility used for the lints are unclear. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oops - I didn't mean for that to un-assign you. Is there a way to prevent these lints from becoming insta-stable? Would it make sense to put them behind a feature gate?
Perhaps we could only fire the lints if an unstable compiler flag (maybe ) is passed? This would still make the lint names insta-stable, though.
in core ffi There is a fixme about , how to fixes that?
By implementing this RFC, I guess. Until that workarounds like this sealed trait will need to be used.
Where is the impl, the RFC is already accepted...
An RFC being accepted just means the feature can be implemented, not that it has been implemented. It doesn't even mean that implementing it is a priority. I believe there has been more discussion of this RFC over at as well as other issues that I can't seem to track down right now.
Hello! I know y'all are busy, but I'm curious if there's an update, particularly on for Voldemort Types - which I'd love to see. I was actually a bit surprised to find that it wasn't included in the existing lint. Appreciate the work that y'all are doing, especially who seems to have put in a lot of legwork.
The tentative plan is that will work on this in March-May.
Cool! Good luck! I'm happy to be a guinea pig to try it out or do code review if that would be helpful.
This issue should be closed by Two follow up issues about improving the effective visibility tables

Related discussion:
text: } declare_lint! { <del> /// The `unreachable_pub` lint triggers for `pub` items not reachable from /// the crate root. </del> <ins> /// The `unreachable_pub` lint triggers for `pub` items not reachable from other crates - that /// means neither directly accessible, nor reexported, nor leaked through things like return /// types. </ins> /// /// ### Example ///