jiebi/CodeConvo huggingface dataset:
Code change:
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.

Related discussion:
text: Changes that do not affect contributors to the compiler or users building rustc from source don't need an update to `VERSION`. <del> If you have any questions, feel free to reach out on the `#t-infra` channel in the [Rust Zulip server][rust-zulip] or ask on internals.rust-lang.org. When you encounter bugs, please file issues on the rust-lang/rust issue tracker. </del> <ins> If you have any questions, feel free to reach out on the `#t-infra/bootstrap` channel at [Rust Bootstrap Zulip server][rust-bootstrap-zulip]. When you encounter bugs, please file issues on the [Rust issue tracker][rust-issue-tracker]. </ins> <del> [rust-zulip]: https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra </del> <ins> [rust-bootstrap-zulip]: https://rust-lang.zulipchat.com/#narrow/stream/t-infra.2Fbootstrap [rust-issue-tracker]: https://github.com/rust-lang/rust/issues </ins>
Code change:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting the error "cannot find type in this scope", so low priority. Affected versions: I tried nightly 2021-11-12 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details
Regressed since , cc
Assigning as and removing .
Another input with a slightly different error message: <details<summary<strongBacktrace</strong</summary<p</p</details
searched nightlies: from nightly-2021-01-07 to nightly-2021-12-24 regressed nightly: nightly-2021-07-26 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This regressed in . cc
No longer ICEs since

Related discussion:
text: <ins> fn main() { 2: n([u8; || 1]) //~^ ERROR cannot find type `n` in this scope //~| ERROR mismatched types } </ins>
Code change:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting the error "cannot find type in this scope", so low priority. Affected versions: I tried nightly 2021-11-12 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details
Regressed since , cc
Assigning as and removing .
Another input with a slightly different error message: <details<summary<strongBacktrace</strong</summary<p</p</details
searched nightlies: from nightly-2021-01-07 to nightly-2021-12-24 regressed nightly: nightly-2021-07-26 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This regressed in . cc
No longer ICEs since

Related discussion:
text: <ins> error[E0412]: cannot find type `n` in this scope --> $DIR/issue-90871.rs:2:8 | LL |     2: n([u8; || 1]) |        ^ expecting a type here because of type ascription error[E0308]: mismatched types --> $DIR/issue-90871.rs:2:15 | LL |     2: n([u8; || 1]) |               ^^^^ expected `usize`, found closure | = note: expected type `usize` found closure `[closure@$DIR/issue-90871.rs:2:15: 2:17]` help: use parentheses to call this closure | LL |     2: n([u8; (|| 1)()]) |               +    +++ error: aborting due to 2 previous errors Some errors have detailed explanations: E0308, E0412. For more information about an error, try `rustc --explain E0308`. </ins>
Code change:
I've rebased this morning and I can't build the repo anymore since landed. It seems there are missing tools in the LLVM CI tarball. AFAICT, these are the tools CI copies in the tarball: And these are the tools bootstrap tries to install in : being defined as: As you can see, there are many tools in that are not included in that step shown above. I'm on macOS, and here is the list of tools that I found in the downloaded LLVM CI tarball: Cc who authored .
I think we should disable copying those tools under ci-llvm for now, and then decide if we want to include them in the ci-llvm artifact or not.
makes sense to me!
Actually the problem seems to be bigger, for now I disabled using the LLVM CI tarball locally and it still failed.
What error are you getting with it disabled?
Exactly the same. I restarted the whole build after running , I'll report back once (if) the error reproduces again.
Ah! The compiler profile sets to , my bad, I'll explicitly override that to in my config and the problem will probably go away. I should have noticed I didn't actually rebuild LLVM hah.
I'll open a PR to make copying the tools conditional on LLVM being built locally.
Or just call , like I suggested originally ... I'm not sure why dist is being treated differently from all the other build commands.
Those tools don't exist in the downloaded archive, so won't help here

Related discussion:
text: // (e.g. the `bootimage` crate). for tool in LLVM_TOOLS { let tool_exe = exe(tool, target_compiler.host); <del> builder.copy(&llvm_bin_dir.join(&tool_exe), &libdir_bin.join(&tool_exe)); </del> <ins> let src_path = llvm_bin_dir.join(&tool_exe); // When using `donwload-ci-llvm`, some of the tools // may not exist, so skip trying to copy them. if src_path.exists() { builder.copy(&src_path, &libdir_bin.join(&tool_exe)); } </ins> } } }
Code change:
The following code works in 1.56.0 but crashes 1.57.0 as well as the most recent nightly &mdash; . <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
According to cargo-bisect-rustc the regression is from &mdash; FYI regressed nightly: nightly-2021-09-06 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Seems that this is duplicate of and ; only triggers with incremental compilation enabled. Unfortunately although I authored the original PR, I don't know a lot about incr-comp or the query system to diagnostic the issue. label: +A-incr-comp
Found the bug, I'll put up a PR in a sec. claim
reopening as this is a stable-to-stable regression, and (I think) we keep those open until a fix lands on stable or we explicitly decline to fix.
was this backported / can we close the issue? :)
The fix was backported and released in 1.58.0
Perfect, thanks for checking !

Related discussion:
text: impl<CTX> HashStable<CTX> for InferTy { fn hash_stable(&self, ctx: &mut CTX, hasher: &mut StableHasher) { use InferTy::*; <ins> discriminant(self).hash_stable(ctx, hasher); </ins> match self { TyVar(v) => v.as_u32().hash_stable(ctx, hasher), IntVar(v) => v.index.hash_stable(ctx, hasher),
Code change:
The following code works in 1.56.0 but crashes 1.57.0 as well as the most recent nightly &mdash; . <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
According to cargo-bisect-rustc the regression is from &mdash; FYI regressed nightly: nightly-2021-09-06 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Seems that this is duplicate of and ; only triggers with incremental compilation enabled. Unfortunately although I authored the original PR, I don't know a lot about incr-comp or the query system to diagnostic the issue. label: +A-incr-comp
Found the bug, I'll put up a PR in a sec. claim
reopening as this is a stable-to-stable regression, and (I think) we keep those open until a fix lands on stable or we explicitly decline to fix.
was this backported / can we close the issue? :)
The fix was backported and released in 1.58.0
Perfect, thanks for checking !

Related discussion:
text: <ins> // check-pass // incremental struct Struct<T>(T); impl<T> std::ops::Deref for Struct<T> { type Target = dyn Fn(T); fn deref(&self) -> &Self::Target { unimplemented!() } } fn main() { let f = Struct(Default::default()); f(0); f(0); } </ins>
Code change:
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.

Related discussion:
text: * other tasks wishing to access the data will block until the closure * finishes running. * <del> * The reason this function is 'unsafe' is because 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. Using MutexArcs * inside of other Arcs is safe in absence of circular references. * </del> * If you wish to nest MutexArcs, one strategy for ensuring safety at * runtime is to add a "nesting level counter" inside the stored data, and * when traversing the arcs, assert that they monotonically decrease.
Code change:
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.

Related discussion:
text: 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() } }
Code change:
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.

Related discussion:
text: } #[test] <del> fn test_unsafe_mutex_arc_nested() { unsafe { // Tests nested mutexes and access // to underlaying data. let arc = ~MutexArc::new(1); let arc2 = ~MutexArc::new(*arc); task::spawn(proc() { (*arc2).unsafe_access(|mutex| { (*mutex).access(|one| { assert!(*one == 1); }) </del> <ins> fn test_mutex_arc_nested() { // Tests nested mutexes and access // to underlaying data. let arc = ~MutexArc::new(1); let arc2 = ~MutexArc::new(*arc); task::spawn(proc() { (*arc2).access(|mutex| { (*mutex).access(|one| { assert!(*one == 1); </ins> }) <del> }); } </del> <ins> }) }); </ins> } #[test]
Code change:
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.

Related discussion:
text: <del> // Copyright 2013 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. extern crate sync; use std::task; use sync::MutexArc; fn test_mutex_arc_nested() { let arc = ~MutexArc::new(1); let arc2 = ~MutexArc::new(*arc); task::spawn(proc() { (*arc2).access(|mutex| { //~ ERROR instantiating a type parameter with an incompatible type }) }); } fn main() {} </del>
Code change:
I was attempting to assign directly to the result of a vector's , which caused this error to fire. That is when I discovered that the help section was telling me to do add an extra let to my while statement, which is not syntactically correct. I tried this code: I expected to see this happen: The code would fail to compile and the help message would tell me to dereference the left side, or at the least give me code that was syntactically correct. Instead, this happened: The could failed to compile, and the help message gave syntactically incorrect code as seen in the backtrace section. <!-- 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<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This minifies to which reports and are related I think, since this example produces the ICE mentioned there on stable
label +A-diagnostics +D-invalid-suggestion +T-compiler
claim

Related discussion:
text: ), .. }) => { <del> // We have a situation like `while Some(0) = value.get(0) {`, where `while let` // was more likely intended. err.span_suggestion_verbose( expr.span.shrink_to_lo(), "you might have meant to use pattern destructuring", "let ".to_string(), Applicability::MachineApplicable, ); </del> <ins> // Check if our lhs is a child of the condition of a while loop let expr_is_ancestor = std::iter::successors(Some(lhs.hir_id), |id| { self.tcx.hir().find_parent_node(*id) }) .take_while(|id| *id != parent) .any(|id| id == expr.hir_id); // if it is, then we have a situation like `while Some(0) = value.get(0) {`, // where `while let` was more likely intended. if expr_is_ancestor { err.span_suggestion_verbose( expr.span.shrink_to_lo(), "you might have meant to use pattern destructuring", "let ".to_string(), Applicability::MachineApplicable, ); } </ins> break; } hir::Node::Item(_)