jiebi/CodeConvo huggingface dataset:
Change:
let sockaddr_p = &mut sockaddr as *mut libc::sockaddr_storage; match unsafe { <del> getsockname(handle, sockaddr_p as *mut libc::sockaddr, &mut namelen) </del> <ins> getsockname(&*handle, sockaddr_p as *mut libc::sockaddr, &mut namelen) </ins> } { 0 => Ok(sockaddr_to_addr(&sockaddr, namelen as uint)), n => Err(uv_error_to_io_error(UvError(n)))

Discussion:
For example, this program prints on unix, and on windows:
The appears to be different on windows for both libgreen and libnative.
I believe this happens because the arguments end up being quoted for Windows. Simplest fix would be to drop empty arguments. Thoughts?
(Alternatively, we could quote empty arguments on Unix.)
I would expect the empty arguments to be passed through as significant argument position. I ran into this in cargo because passed on unix but on windows it would try to consume the next argument for the test args. It looks like to fix this we just need to alter to see if the argument is 0-length, and if so we quote it. Libuv already does . I'm investigating a fix for libgreen, it looks like it should be working...
Change:
The goal of each stage is to (a) leverage Cargo as much as possible and failing that (b) leverage Rust as much as possible! <del> ## Incremental builds You can configure rustbuild to use incremental compilation with the `--incremental` flag: ```sh $ ./x.py build --incremental ``` The `--incremental` flag will store incremental compilation artifacts in `build/<host>/stage0-incremental`. Note that we only use incremental compilation for the stage0 -> stage1 compilation -- this is because the stage1 compiler is changing, and we don't try to cache and reuse incremental artifacts across different versions of the compiler. You can always drop the `--incremental` to build as normal (but you will still be using the local nightly as your bootstrap). </del> ## Directory Layout This build system houses all output under the `build` directory, which looks

Discussion:
Right now, there are docs for x.py in a bunch of different places: https://rustc-dev- https://rustc-dev- It would be nice to consolidate these some; e.g. can probably just point to the README, and lots of the information in the readme is duplicated in the dev-guide and can be deleted and replaced with a link. cc - do you have strong opinions on this? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
No, seems good to consolidate. I personally think we might get something out of ending up with two guides, one of which discusses the content from an internal perspective (e.g., Step, how to add new targets) and another from an external perspective, focusing on what users need to know. I think most of the existing documentation is sort of in the second of those, but also (potentially correctly, hard for me to say) treats things as a very leaky abstraction and documents a lot of the internals too. I think some of this is our audience, but I do wonder if a much simpler message is possible with just a few standard commands depending on what they want to build, and documenting specific outputs rather than the whole layout. I think right now we're trying to explain things by teaching everything, but perhaps we can get away with not teaching the internals of the abstraction. Anyway, mostly musing, no strong opinions here.
We should also document that we support suffixes instead of full paths (e.g. instead of ):
Hello, Should I start working on adding doc-comments in bootstrap ?
more doc-comments are always welcome :) but when I wrote the issue I was imagining coming up for a plan for how to organize the standalone documentation. maybe we can put the internal documentation in src/bootstrap/README and the user facing documentation in the guide?
claim
I like the idea and I think this standard should be applied in general since this seperation reduces cost of the maintaince and makes dev-guide more understandable and simple for users. I will follow that idea in the refactoring.
Change:
<ins> // Copyright 2014 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(dead_code)] const LOW_RANGE: char = '0'; const HIGH_RANGE: char = '9'; fn main() { match '5' { LOW_RANGE...HIGH_RANGE => (), _ => () }; } </ins>

Discussion:
This may be related to but here is some test code for this specific case: Which prints: Ideally this would not issue a warning.
Change:
/// # Examples /// /// ```rust <del> /// #![feature(nonnull_slice_from_raw_parts)] </del> /// use std::ptr::NonNull; /// /// let slice: NonNull<[i8]> = NonNull::slice_from_raw_parts(NonNull::dangling(), 3);

Discussion:
This is a tracking issue for the method proposed in PR The feature gates for the issue are , and for using as a . Docs: [x] Implementation: [x] FCP: [ ] Stabilization PR
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.
I'm willing to file the stabilization report for this if the library team is on board for stabilization.
I'd certainly appreciate one!
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
Change:
= help: consider adding an explicit import of `foo` to disambiguate error[E0659]: `foo` is ambiguous (glob import vs glob import in the same module) <del> --> $DIR/duplicate.rs:36:8 | LL |     g::foo(); //~ ERROR `foo` is ambiguous |        ^^^ ambiguous name | note: `foo` could refer to the function imported here --> $DIR/duplicate.rs:29:13 | LL |     pub use a::*; |             ^^^^ = help: consider adding an explicit import of `foo` to disambiguate note: `foo` could also refer to the unresolved item imported here --> $DIR/duplicate.rs:30:13 | LL |     pub use f::*; |             ^^^^ = help: consider adding an explicit import of `foo` to disambiguate error[E0659]: `foo` is ambiguous (glob import vs glob import in the same module) </del> --> $DIR/duplicate.rs:49:9 | LL |         foo::bar(); //~ ERROR `foo` is ambiguous

Discussion:
the code i tried: noticed there was a typo, fixed it, still getting an ICE i expected: cargo-generate/pull/135, to not compile and give an error about typo cargo-generate/pull/136, to compile (and no longer display 2018 warnings about path clarity) instead, what happened: system info:
i also get this on stable and earlier nightlies, if that is at all useful.
(also please feel free to let me know if i can provide any more info- this is my first time filing a compiler bug! thanks for all your hardwork and help <3)
Nominating -- we should keep focus on Rust 2018-related bugs like this, I think.
Did you? I mean, there is a typo, right? Do you mean, you expected a controller error? Specifically I see this in the diff: and I think it should be ?
I guess you are saying you get the same ICE from , which has a fix... did you try a cargo clean? (I'm wondering if it is related to incremental compilation.)
yeah, so i noticed the typo, and then fixed it (hence the 2 PRs- i included both on the offchance that there were 2 issues.) i expected the 2nd one to compile, and the first one (after i noticed the typo, to not compile but give an error re: the typo). i will run a cargo clean and see if it helps!
OK, thanks for the clarification.
just ran and then and have the same error message.
Fixed in
Change:
let mut p = cx.new_parser_from_tts(tts); let mut es = Vec::new(); while p.token != token::EOF { <del> es.push(cx.expand_expr(p.parse_expr())); </del> <ins> es.push(cx.expander().fold_expr(p.parse_expr())); </ins> if p.eat(&token::COMMA) { continue; }

Discussion:
I believe this should output the string : But I get this error: Rust version:
Note that standard recursive macros work fine, e.g., And outputs . Maybe the bug here is that expanding macros within other macros is using an older environment that doesn't include the name ?
It's even worse than that. only uses the compiler built-in macros:
I think this might be a dupe of
Does fixing mean that also gets fixed? I wouldn't assume so, but it might be possible depending on the implementation. (Sorry I missed that issue. I searched for 'recursive macro' instead of 'nested macro'!)
both and use , which doesn't work with non-builtin macros.
Right. I'm referring to the recursive aspect. Wasn't sure if that would make a difference. (I just don't know enough about how macros are expanded to know. Pure guesswork on my part.)
Change:
fn main() { let x = -5; <del> if x<-1 { //~ ERROR expected `{`, found `<-` </del> <ins> if x<-1 { //~ ERROR unexpected token: `<-` </ins> println!("ok"); } }

Discussion:
produces: It would be nice if it produced a suggestion to split it up: (This , but was broken in a previous change.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi I'd like to try this one. Just found the removed suggestion.
claim
assign Hmm, triagebot is not well...
It doesn't look like you're still working on this. Is it ok if I take over?
Sure. Thanks for your help.
Change:
<del> //@ known-bug: rust-lang/rust#130372 fn bar() -> impl Fn() { wrap() } fn wrap(...: impl ...) -> impl Fn() {} </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at /rust/deps/itertools- 'itertools: .zipeq() reached end of one iterator before the other'', 'thread 'rustc' panicked at /rust/deps/itertools- 'itertools: .zipeq() reached end of one iterator before the other'' 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 [analysis] running analysis passes on this crate -- label +F-cvariadic +F-fndelegation <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
lol
Thanks! I will take a look. (I'm glad we the check!)
another one that does not need delegation I think
claim
Change:
//! normal visitor, which just walks the entire body in one shot, the //! `ExprUseVisitor` determines how expressions are being used. <ins> use hir::def::DefKind; </ins> // Export these here so that Clippy can use them. pub use rustc_middle::hir::place::{Place, PlaceBase, PlaceWithHirId, Projection};

Discussion:
The following ICE was found migrating . cc which was very similar, but has been fixed. Also found in: - https://crater- <!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Change:
<ins> error[E0133]: call to unsafe function `unsafe_fn` is unsafe and requires unsafe block --> $DIR/unsafe-env.rs:15:9 | LL |         unsafe_fn(); |         ^^^^^^^^^^^ call to unsafe function | = note: for more information, see issue #71668 <https://github.com/rust-lang/rust/issues/71668> = note: consult the function's documentation for information on how to avoid undefined behavior note: an unsafe function restricts its caller, but its body is safe by default --> $DIR/unsafe-env.rs:9:1 | LL | unsafe fn unsafe_fn() { | ^^^^^^^^^^^^^^^^^^^^^ note: the lint level is defined here --> $DIR/unsafe-env.rs:8:8 | LL | #[deny(unsafe_op_in_unsafe_fn)] |        ^^^^^^^^^^^^^^^^^^^^^^ </ins> error[E0133]: call to unsafe function `unsafe_fn` is unsafe and requires unsafe function or block <del> --> $DIR/unsafe-env.rs:23:5 </del> <ins> --> $DIR/unsafe-env.rs:33:5 </ins> | LL |     unsafe_fn(); |     ^^^^^^^^^^^ call to unsafe function

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. --I tried this code: I expected to see this happen: will become in Rust 2024, the above code is using Rust 2021, so this should compile with no issue. Instead, this happened: <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<pNot needed </p</detailsI think the root cause is the lint , commenting it out would make the code compile: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Thanks for the report! That should not happen. We did a so I don't know how this is even possible... any ideas? This seems to be some bad interaction with .
claim Hmmm, weird that crater run didn't catch this.
I posted a PR fixing this: . Does crater maybe restrict lints?
I don't think it does. Is this code part of the "nix" crate?
If you are asking if this problem originates from the nix crate, then yes, see
I am wondering whether the nix crate as published on fails to build with latest nightly due to this issue.
I think yes, the has been in Nix for a long time. One should be able to reproduce the build failure on a UNIX platform other than: I am currently on Linux, will try reproducing it on my mac tomorrow.
Looks like crater tested nix 0.26.4 and that failed already before the removevar/setvar change (). That's due to the which makes the build fail even when there are just warnings. I guess we can add this to the list of why having deny(warnings) in the code is considered bad practice.
I created an issue and a PR against nix-rust.
Yeah, we can reproduce this on macOS
The reason this was missed is a combination of and
WG-prioritization assigning priority (). label -I-prioritize +P-high
Fix already exists, just needs a review: .
Change:
fn statement_effect(&self, sets: &mut BlockSets<Local>, loc: Location) { <ins> let stmt = &self.mir[loc.block].statements[loc.statement_index]; </ins> BorrowedLocalsVisitor { sets, <del> }.visit_statement(loc.block, &self.mir[loc.block].statements[loc.statement_index], loc); </del> <ins> }.visit_statement(loc.block, stmt, loc); // StorageDead invalidates all borrows and raw pointers to a local match stmt.kind { StatementKind::StorageDead(l) => sets.kill(&l), _ => (), } </ins> } fn terminator_effect(&self,

Discussion:
cc
cc
I'm hitting this a lot at the moment-- any idea what the cause might be? I'd love to help get this resolved.
I'm sometimes able to fix it by moving conditions that out of the body of an expression.
It also seems to have regressed between and -- updating the compiler caused this to happen in more places.
Possibly related to ? cc
Trying to fix in more places and it looks like it's always related to temporaries-- if I make it and then use in the place I was using it usually solves the issue.
Smaller example: ()
cc this is blocking roll out of async/await in Fuchsia
Looked at this and pointed out that it looks like typechecking thinks that isn't live at the point (which is correct) but that MIR thinks it is live (which is incorrect). I tried searching through the diff to see if there were any related PRs, but so far the only thing I've found that touches MIR is , which seems like it shouldn't be related.
Is working on bisecting this.
I think the problem is that is borrowed by and because of this the generator transformation only uses and statements to calculate liveness. However we generate a statement for before its initialiser which contains the statement. So appears live during the statement, even though its storage isn't used for anything.
Bisection pointed to as the PR that made this worse (more code ICEs now), although the minimal test case still fails before and after. cc
minimal repro: This ICE only surfaces after
using instead of makes the ICE "go away"
Ah you need at the very least to use and initializations, not . AFAIK the type of a variable could be dead at a (lifetimes not ready yet). Arguably you could also have the time before moving out and a reinitialization also count as dead, e.g. doesn't really need to keep alive.
Change:
} } <ins> pub(crate) fn suggest_clone_for_ref( &self, diag: &mut Diagnostic, expr: &hir::Expr<'_>, expr_ty: Ty<'tcx>, expected_ty: Ty<'tcx>, ) -> bool { if let ty::Ref(_, inner_ty, hir::Mutability::Not) = expr_ty.kind() && let Some(clone_trait_def) = self.tcx.lang_items().clone_trait() && expected_ty == *inner_ty && self .infcx .type_implements_trait( clone_trait_def, [self.tcx.erase_regions(expected_ty)], self.param_env ) .must_apply_modulo_regions() { diag.span_suggestion_verbose( expr.span.shrink_to_hi(), "consider using clone here", ".clone()", Applicability::MachineApplicable, ); return true; } false } </ins> pub(crate) fn suggest_copied_or_cloned( &self, diag: &mut Diagnostic,

Discussion:
we should suggest cloning. Also, we should suggest <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
If we suggest add bound, we don't need dervie , This code will compile:
Change:
<ins> //! This test tests two things at once: //! 1. we error if a const evaluation hits the deny-by-default lint limit //! 2. we do not ICE on invalid follow-up code // compile-flags: -Z tiny-const-eval-limit </ins> fn main() { // Tests the Collatz conjecture with an incorrect base case (0 instead of 1). // The value of `n` will loop indefinitely (4 - 2 - 1 - 4). <del> let _ = [(); { </del> <ins> let s = [(); { </ins> let mut n = 113383; // #20 in https://oeis.org/A006884 while n != 0 { //~^ ERROR is taking a long time

Discussion:
File: auto-reduced (treereduce-rust): original: Version 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
Regression in nightly-2023-06-02 Regression in cc
Change:
code = ret.wait() if code != 0: err = "failed to run: " + ' '.join(args) <del> if help_on_error is not None: err += "n" + help_on_error </del> if verbose or exception: raise RuntimeError(err) # For most failures, we definitely do want to print this error, or the user will have no

Discussion:
I accidentally missed this when porting it to rustbuild: It would be nice to add it back. Mentoring instructions: Add a new parameter to and pass it down from : This code moved around in so you may want to base your changes off that PR until it lands. label +E-easy +E-mentor +A-rustbuild <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Please also remove the dead code from at the same time:
claim
Change:
<ins> #![crate_name = "foo"] #![feature(generic_associated_types)] pub trait Trait { type Gat<'a>; } // Make sure that the elided lifetime shows up // @has foo/type.T.html // @has - "pub type T = " // @has - "&lt;'_&gt;" pub type T = fn(&<() as Trait>::Gat<'_>); </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. --Minimized example: Command: <!-- 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. --Platform: See backtrace <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'll look into it! claim
Minimized this to a local-crate-only test, and working on a solution currently:
Change:
impl<T:Clone+Send+Freeze> Clone for CowArc<T> { /// Duplicate a Copy-on-write Arc. See arc::clone for more details. <del> #[inline] </del> fn clone(&self) -> CowArc<T> { CowArc { x: self.x.clone() } }

Discussion:
contains two sets of methods to access the Arc's wrapped object. and are tagged unsafe as "it is possible to construct a circular reference among multiple Arcs by mutating the underlying data. This creates potential for deadlock, but worse, this will guarantee a memory leak of all involved Arcs." There are also and methods defined when the inner type is freezable as that guarantees the type can't contain a . However, it's still trivially easy to deadlock using the safe methods: It seems that the consensus in was that possibility of deadlock is inherently unsafe, so should and be removed? cc
Perhaps access should fail when it is called by the same task twice? It would be nice if people didn't have to use unsafe blocks just to get normal stuff done.
Nested locks in the same task aren't the only way you can run into deadlock:
I am aware of that, but it seems to me this particular error would be easy and cheap to catch, so if we aren't doing that yet, we probably should. Personally I don't think the possibility of a deadlock should require an unsafe block.
Consensus in the past has been that deadlock is not unsafe (). You can deadlock with pipes too, with just two lines of code. The non- accessors for are unsafe for a totally different reason, which is documented in . Regarding "cheap and easy to catch" - I don't believe we should try to fail in the single-task deadlock case unless we can reliably fail in all deadlock cases (which is not out of the question but requires scheduler support, see ). A user who is used to seeing a failure message from their previous attempts which had deadlocked would be all the more confused when they find their cross-task deadlocking code does not fail.
Is the possibility of memory leakage really considered unsafe? doesn't seem to share that assumption, but I may be missing something there.
Neither or provides a way to leak memory via the safe constructors.
We currently don't officially consider leaks to be , but I think leaking past the lifetime of tasks with references is a very questionable thing to allow.
The box annihilator is not a good solution to rc reference cycles, but it is at least a solution. Cycles of MutexArcs will produce valgrind errors.
now provides a way to leak with the safe constructors.