jiebi/CodeConvo huggingface dataset:
Change:
match value.kind { ast::ExprKind::Paren(ref inner) => { if !Self::is_expr_parens_necessary(inner, followed_by_block) && <del> value.attrs.is_empty() { </del> <ins> value.attrs.is_empty() && !value.span.from_expansion() { </ins> let expr_text = if let Ok(snippet) = cx.sess().source_map() .span_to_snippet(value.span) { snippet

Discussion:
The latest beta contains a new? l lint that triggers on macro by example code. This does not necessarily make sense because macros could be used to construct nearly arbitrary custom syntax for example something requiring to wrap a single element into a parenthesis. The strange thing here is that seems to only happen on beta, not on nightly, not on current stable. Found via Error message: rustc version:
My head can't come up with an example that requires parentheses. macros are hygenic, so there should be no problem in omitting the parentheses and just writing will be fine. Can you give me a counter example?
A real world example is the diesel  macro. Somewhere in the inner it does some clever things to support plain types and tuples by just saying where is some repeated type variable. Depending on the number of actual types there this will result in which is a single type or which is a tuple. It's probably possible to rewrite that code doing the same stuff but that would involve a lot of duplication (Because than you would need to have a special case for a single type everywhere).
So somehing like this: You're right. The question is: should we remove the lint for all macros? Only for macros that contain repetitive expansions? (Is that even possible to detect?)
modify labels: A-lint T-compiler
Would be great to get that fixed till it is part of the next stable release.
This seems to occur first on nightly-2019-11-02
nominating for discussing at T-compiler + T-lang meeting, namely to take peoples' temperature with respect to the idea of just not linting this case when the flagged code appears as part of a macro definition.
also, marking as P-high w.r.t. answer the question(s) posed here. (I personally don't think the severity of the actual impact is likely to be worth a P-high rating; the priority is likely just temporary until the discussion happens.)
The language team discussed this last week. The general consensus was that we can stop linting when the redundant parens are inside the macro (as opposed to e.g. where the spans are from the outside). We believe this is fine as the lint is mostly a style thing which does not protect from anything correctness or performance related.
I've played a bit around with this issue today.

Seems like conditions need to be adjusted to also check if we are in macro expanded code. I've tried something like but that does remove more warnings that we want.
I think the questions have been basically answered in terms of what path we see best going forward. Self-assigning, removing I-nominated.
Change:
} ty::Predicate::TypeOutlives(ref binder) => { <del> // For now, we just check that there are no higher-ranked // regions.  If there are, we will call this obligation an // error. Eventually we should be able to support some // cases here, I imagine (e.g., `for<'a> int : 'a`). </del> <ins> // Check if there are higher-ranked regions. </ins> match selcx.tcx().no_late_bound_regions(binder) { <ins> // If there are, inspect the underlying type further. </ins> None => { <del> errors.push( FulfillmentError::new( obligation.clone(), CodeSelectionError(Unimplemented))) </del> <ins> // Convert from `Binder<OutlivesPredicate<Ty, Region>>` to `Binder<Ty>`. let binder = binder.map_bound_ref(|pred| pred.0); // Check if the type has any bound regions. match selcx.tcx().no_late_bound_regions(&binder) { // If so, this obligation is an error (for now). Eventually we should be // able to support additional cases here, like `for<'a> &'a str: 'a`. None => { errors.push( FulfillmentError::new( obligation.clone(), CodeSelectionError(Unimplemented))) } // Otherwise, we have something of the form // `for<'a> T: 'a where 'a not in T`, which we can treat as `T: 'static`. Some(t_a) => { register_region_obligation(t_a, ty::ReStatic, obligation.cause.clone(), region_obligations); } } </ins> } <ins> // If there aren't, register the obligation. </ins> Some(ty::OutlivesPredicate(t_a, r_b)) => { register_region_obligation(t_a, r_b, obligation.cause.clone(),

Discussion:
The following code fails to compile despite : The exact error is: Per comment , it seems that could imply .
contains the following comment:
I'd be interested in digging into this if you can give me some advice on how to get started.
hmm, probably best would be to privmsg me on IRC, if that's possible (). It should be fairly easy to write a targeted patch covering cases like , where the bound region only appears on the RHS; doing a more general fix (e.g., one that handles ) would be somewhat harder, though some of the recent refactoring I've been doing would help there.
Change:
<ins> // test the deref_nullptr lint #![deny(deref_nullptr)] use std::ptr; struct Struct { field: u8, } fn f() { unsafe { let a = 1; let ub = *(a as *const i32); let ub = *(0 as *const i32); //~^ ERROR dereferencing a null pointer let ub = *ptr::null::<i32>(); //~^ ERROR dereferencing a null pointer let ub = *ptr::null_mut::<i32>(); //~^ ERROR dereferencing a null pointer let ub = *(ptr::null::<i16>() as *const i32); //~^ ERROR dereferencing a null pointer let ub = *(ptr::null::<i16>() as *mut i32 as *mut usize as *const u8); //~^ ERROR dereferencing a null pointer let ub = &*ptr::null::<i32>(); //~^ ERROR dereferencing a null pointer let ub = &*ptr::null_mut::<i32>(); //~^ ERROR dereferencing a null pointer ptr::addr_of!(*ptr::null::<i32>()); //~^ ERROR dereferencing a null pointer ptr::addr_of_mut!(*ptr::null_mut::<i32>()); //~^ ERROR dereferencing a null pointer let offset = ptr::addr_of!((*ptr::null::<Struct>()).field); //~^ ERROR dereferencing a null pointer } } fn main() {} </ins>

Discussion:
I propose we add a lint that detects code like Some people seem to think that this is okay in contexts like or , but that is not the case -- on a NULL pointer is UB even as a place expression. To implement this, you can use the lint as a template: should check for  expressions with a operator, and then check the operand to be either a cast of to a pointer type, or a call to one of the methods. To detect the methods, make them "diagnostic items"; the lint does that e.g. for so it can again serve as a template here. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Ah, turns out clippy already has a lint for this: . So maybe we should just move that to rustc? Cc
claim
awesome. :) Let me know if you need any help.
Thanks :)
Did you mean something slightly different with your "okay in contexts like" examples, perhaps? Neither of those two actually compile as written, since they're just attempts to deference something that isn't even a pointer. You get: in both cases.
oops I screwed up the casts, should be fixed now.
Yeah, happy to have Clippy lints upstreamed to rust, let us know when it's done so we can deprecate it on our end
for detecting a call like you said to use . However I do not know what to use for the symbol argument. There is that defines symbol but nothing looks like creating a null ptr. Should I add one what should it look like ?
You first need to add the diagnostic item attribute to the relevant function inside , like so: This name must be globally unique, e.g. and . Then you add those names to the list in (please keep it alphabetically sorted), and then you can use them for .
Change:
--> $DIR/error-festival.rs:25:5 | LL |     0u32 as char; <del> |     ^^^^^^^^^^^^ invalid cast | help: try `char::from_u32` instead --> $DIR/error-festival.rs:25:5 | LL |     0u32 as char; </del> |     ^^^^^^^^^^^^ <ins> |     | |     invalid cast |     help: try `char::from_u32` instead: `char::from_u32(0u32)` </ins> error[E0605]: non-primitive cast: `u8` as `Vec<u8>` --> $DIR/error-festival.rs:29:5

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Et Voila! ! Here's the final result, pushing a PR soon
Should be fixed by
Change:
len: usize, out_len: &mut usize, ) -> *const u8; <del> pub fn LLVMRustLTOGetDICompileUnit(M: &Module, CU1: &mut *mut c_void, CU2: &mut *mut c_void); pub fn LLVMRustLTOPatchDICompileUnit(M: &Module, CU: *mut c_void); </del> <ins> pub fn LLVMRustThinLTOGetDICompileUnit( M: &Module, CU1: &mut *mut c_void, CU2: &mut *mut c_void, ); pub fn LLVMRustThinLTOPatchDICompileUnit(M: &Module, CU: *mut c_void); </ins> pub fn LLVMRustLinkerNew(M: &Module) -> &mut Linker<'_>; pub fn LLVMRustLinkerAdd(

Discussion:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?
Change:
rx2.recv(); }) <ins> iotest!(fn clone_while_reading() { let addr = next_test_ip6(); let listen = TcpListener::bind(addr.ip.to_str().as_slice(), addr.port); let mut accept = listen.listen().unwrap(); // Enqueue a task to write to a socket let (tx, rx) = channel(); let (txdone, rxdone) = channel(); let txdone2 = txdone.clone(); spawn(proc() { let mut tcp = TcpStream::connect(addr.ip.to_str().as_slice(), addr.port).unwrap(); rx.recv(); tcp.write_u8(0).unwrap(); txdone2.send(()); }); // Spawn off a reading clone let tcp = accept.accept().unwrap(); let tcp2 = tcp.clone(); let txdone3 = txdone.clone(); spawn(proc() { let mut tcp2 = tcp2; tcp2.read_u8().unwrap(); txdone3.send(()); }); // Try to ensure that the reading clone is indeed reading for _ in range(0i, 50) { ::task::deschedule(); } // clone the handle again while it's reading, then let it finish the // read. let _ = tcp.clone(); tx.send(()); rxdone.recv(); rxdone.recv(); }) </ins> }

Discussion:
When using libgreen on Windows (verified not to occur with libnative) when I'm reading from a TcpStream and the remote host closes the stream (specifically I'm closing the client by pressing ctrl + c), the server silently terminates with no error messages. It appears SIGSEGV is being called. The code I was writing which caused this issue can be found here: Using Windows 8.1 x64 with latest Rust nightly. Attempts to backtrace using gdb have failed:
cc
I have acquired a backtrace by attaching gdb to a running process rather than running the process from gdb to begin with (why this works I have no idea)
After debugging with visual studio I figured out the exact line causing the segfault. At it is . here is a null reference, which was transmuted from getting the data of the handle, which is apparently 0. I don't know what is setting it to 0 though.
It appears even sending packets to the connection causes it to die. Has anyone even tested libgreen on Windows with TCP?
I have determined the cause of the bug to be a race condition. Specifically every time I open up a connection, is called 3 times and is called once. If the 3 new streams all occur before the read call, the pointer remains non-zero. If one of them occurs after the read call, then the pointer becomes zero, and the read callback segfaults. I have verified this through multiple runs and statements everywhere.
To further expand, is called when a TcpStream is created, and also everytime I clone the . Since cloning a is the only way to share it across tasks (it doesn't impl ), I had to spawn two tasks, one to read and one to write. Because I spawned the reading one first it would start a read before I cloned the tcp for the writing task, and once I cloned it, the data pointer got reset so the data pointer the read callback received was null thereby causing the segfault.
Yes, no commit gets pushed to master unless it passes all tests on windows, and that includes many networking tests. Do you have a small test case which reproduces this bug? It's likely that there's just some different callback-invoking behavior on windows than on unix that was accidentally not dealt with.
Here is a minimal code example:
Change:
} } <del> let access_levels = tcx.privacy_access_levels(impl_def_id.krate); if let Some(id) = tcx.hir().as_local_hir_id(impl_def_id) { if access_levels.is_exported(id) || access_levels.is_public(id) { for cause in &overlap.intercrate_ambiguity_causes { cause.add_intercrate_ambiguity_hint(&mut err); } } </del> <ins> for cause in &overlap.intercrate_ambiguity_causes { cause.add_intercrate_ambiguity_hint(&mut err); </ins> } if overlap.involves_placeholder {

Discussion:
PR had removed the notes from the tests for the upstream/downstream printing logic, so now that logic is not tested: Plus, the new error messages are worse: an upstream impl can indeed be , even if the crate is private. I think that even in the OP case, some sort of note should be , unless we change coherence. Again, the test case: There, the error message is a coherence conflict for , where this impl conflicts with the libcore impl, because the compiler can't prove that . Now, the error message says that the reason that the compiler can't prove is because of a possible downstream impl. Of course, no downstream impl can exist as the trait is private, however, I don't think we want to change coherence to account for that, especially not without an RFC. Maybe a wording change is in order? I don't think the "upstream" message needs to change any (see the test diff), it's still good in the private case. Maybe it should try to mention a non-private trait, but that would be some work. Say, for non-exported trait, change the note to say: I'm not even sure the note is a problem, I personally like the state before the PR the best. cc
Actually, I think the version of the note I came up with is even more confusing than the "downstream crate" note, and the current version is worse than both.
That PR was also submitted with no "positive" test to see that it fixes the error message it is purported to fix. That feels clearly wrong to me.
Change:
pub trait LateLintPass: LintPass { fn check_name(&mut self, _: &LateContext, _: Span, _: ast::Name) { } fn check_crate(&mut self, _: &LateContext, _: &hir::Crate) { } <ins> fn check_crate_post(&mut self, _: &LateContext, _: &hir::Crate) { } </ins> fn check_mod(&mut self, _: &LateContext, _: &hir::Mod, _: Span, _: ast::NodeId) { } fn check_foreign_item(&mut self, _: &LateContext, _: &hir::ForeignItem) { } fn check_item(&mut self, _: &LateContext, _: &hir::Item) { } <ins> fn check_item_post(&mut self, _: &LateContext, _: &hir::Item) { } </ins> fn check_local(&mut self, _: &LateContext, _: &hir::Local) { } fn check_block(&mut self, _: &LateContext, _: &hir::Block) { } <ins> fn check_block_post(&mut self, _: &LateContext, _: &hir::Block) { } </ins> fn check_stmt(&mut self, _: &LateContext, _: &hir::Stmt) { } fn check_arm(&mut self, _: &LateContext, _: &hir::Arm) { } fn check_pat(&mut self, _: &LateContext, _: &hir::Pat) { }

Discussion:
For clippy's lint, I made use of a so I could stop clippy from linting the same macro multiple times while being reasonably fast. However, this unfortunately means the lint ignores .. attributes below the crate level. To solve this and other related problems, I propose any of allow a lint to check anything from anywhere in the analysis by moving up the parent chain to check the level allow a lint to opt out of calls for the duration of a specific node including its child nodes add methods to the {Early, Late}LintPass trait, so lints can decide themselves The third option is probably the easiest to implement, yet the most flexible. This would bring the trait closer to other stream parser implementations like SAX.
Seeing that we already have a few, _post methods, I think adding some more will be an acceptable solution here. I'll have a PR shortly.
Change:
<ins> fn main() {} fn v() -> isize { //~ ERROR mismatched types mod _ { //~ ERROR expected identifier pub fn g() -> isizee { //~ ERROR cannot find type `isizee` in this scope mod _ { //~ ERROR expected identifier pub    g() -> is //~ ERROR missing `fn` for function definition (), w20); } (), w20); //~ ERROR expected item, found `;` } </ins>

Discussion:
I'm getting an internal compiler error on the following program (found by ): I'm seeing the error on stable, beta, and nightly. As with , the error occurs on () but not on (). , the proposed fix for , does not fix this error. cc
Change:
<ins> error[E0770]: the type of const parameters must not depend on other generic parameters --> $DIR/issue-90364.rs:4:28 | LL | pub struct Foo<T, const H: T>(T) |                            ^ the type must not depend on the parameter `T` error: aborting due to previous error For more information about this error, try `rustc --explain E0770`. </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --() <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Also tested on the playground: . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details modify labels: +A-const-generics +F-genericconstexprs +requires-nightly
Change:
} // Extra help text for some commands match subcommand.as_str() { <del> "build" => { </del> <ins> "build" | "b" => { </ins> subcommand_help.push_str( "n Arguments:

Discussion:
currently supports , and a few others even though not so discoverable (). It would be good to let supports the aliases supported by , such as , and such. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> //! This test checks that we allow subtyping predicates that contain opaque types. //! No hidden types are being constrained in the subtyping predicate, but type and //! lifetime variables get subtyped in the generic parameter list of the opaque. use std::iter; mod either { pub enum Either<L, R> { Left(L), Right(R), } impl<L: Iterator, R: Iterator<Item = L::Item>> Iterator for Either<L, R> { type Item = L::Item; fn next(&mut self) -> Option<Self::Item> { todo!() } } pub use self::Either::{Left, Right}; } pub enum BabeConsensusLogRef<'a> { NextEpochData(BabeNextEpochRef<'a>), NextConfigData, } impl<'a> BabeConsensusLogRef<'a> { pub fn scale_encoding( &self, ) -> impl Iterator<Item = impl AsRef<[u8]> + Clone + 'a> + Clone + 'a { //~^ ERROR is not satisfied //~| ERROR is not satisfied //~| ERROR is not satisfied match self { BabeConsensusLogRef::NextEpochData(digest) => either::Left(either::Left( digest.scale_encoding().map(either::Left).map(either::Left), )), BabeConsensusLogRef::NextConfigData => either::Right( // The Opaque type from ``scale_encoding` gets used opaquely here, while the `R` // generic parameter of `Either` contains type variables that get subtyped and the // opaque type contains lifetime variables that get subtyped. iter::once(either::Right(either::Left([1]))) .chain(std::iter::once([1]).map(either::Right).map(either::Right)), ), } } } pub struct BabeNextEpochRef<'a>(&'a ()); impl<'a> BabeNextEpochRef<'a> { pub fn scale_encoding( &self, ) -> impl Iterator<Item = impl AsRef<[u8]> + Clone + 'a> + Clone + 'a { std::iter::once([1]) } } fn main() {} </ins>

Discussion:
https://crater- https://crater- https://crater- https://crater- https://crater- https://crater- probably cc
Yeah Matthias also found . Think it hasn't been fixed b/c oli is on holiday -- I assume he will investigate when he's back next week.
MCVE in
WG-prioritization assigning priority (). I'll mark this as because it seems an unintended breaking change and therefore should probably be fixed before entering into stable. label -I-prioritize +P-critical

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: opaque types got hidden types registered from within subtype predicate: Alias(Opaque, AliasTy { args: [], defid: DefId(0:25 ~ ice[ee90]::Tait::{opaque}) }) vs Continuation', 'error: internal compiler error: opaque types got hidden types registered from within subtype predicate: Alias(Opaque, AliasTy { args: [], defid: DefId(0:25 ~ ice[ee90]::Tait::{opaque}) }) vs Continuation' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate -- label +F-typealiasimpl_trait
bit smaller