jiebi/CodeConvo huggingface dataset:
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. // error-pattern:internal error: entered unreachable code: 6 is not prime fn main() { unreachable!("{} is not {}", 6u32, "prime"); } </ins>

Discussion:
In we had the submitter change a to an as follows: We felt that better communicated the intent of "this code should never panic assuming that the implementation is correct" (as opposed to , which communicates "this code should never panic assuming that the user passes in the correct inputs" (cf. indexing, division) and is generally to be avoided in the stdlib). However, I think it's a shame that by expressing the intent more clearly in the code we're simultaneously losing information regarding which invariant was violated in order to reach the unreachable code. Note that this isn't really a huge deal, because we can just move the "Invalid SearchStack" bit over into a comment next to . It's also not really a huge deal for the theoretical bug reporter who's filing an issue upon hitting this code, since still includes a filename and line number in its output. However, given the precedent of optional messages set by , I don't think it would be a stretch to imagine that could also have an optional message. Usage for the typical case would be the same: could optionally look like this:
I'll have a go at implementing this.
Change:
<ins> error[E0726]: implicit elided lifetime not allowed here --> $DIR/skip-reporting-if-references-err.rs:10:9 | LL | impl<T> ToUnit for T {} |         ^^^^^^ expected lifetime parameter | help: indicate the anonymous lifetime | LL | impl<T> ToUnit<'_> for T {} |               ++++ error[E0277]: the trait bound `for<'a> (): ToUnit<'a>` is not satisfied --> $DIR/skip-reporting-if-references-err.rs:15:29 | LL | impl Overlap for for<'a> fn(<() as ToUnit<'a>>::Unit) {} |                             ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `for<'a> ToUnit<'a>` is not implemented for `()` error[E0277]: the trait bound `for<'a> (): ToUnit<'a>` is not satisfied --> $DIR/skip-reporting-if-references-err.rs:15:18 | LL | impl Overlap for for<'a> fn(<() as ToUnit<'a>>::Unit) {} |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `for<'a> ToUnit<'a>` is not implemented for `()` error: aborting due to 3 previous errors Some errors have detailed explanations: E0277, E0726. For more information about an error, try `rustc --explain E0277`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'downgradetodelayedbug: cannot downgrade Warning to DelayedBug: not an error'', 'thread 'rustc' panicked at 'downgradetodelayedbug: cannot downgrade Warning to DelayedBug: not an error'' 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<!-- query stack: [specializationgraphof] building specialization graph of trait [coherent_trait] coherence checking all impls of trait [analysis] running analysis passes on this crate --
Regression in nightly-2023-03-22 commit[0] 2023-03-20: Auto merge of - euclio:windows-rs, r=ChrisDenton commit[1] 2023-03-20: Auto merge of - Zoxc:split-execute-job, r=cjgillot,michaelwoerister commit[2] 2023-03-21: Auto merge of - ChrisDenton:libntdll, r=Mark-Simulacrum commit[3] 2023-03-21: Auto merge of - TDecki:dec2flt-inline, r=thomcc commit[4] 2023-03-21: Auto merge of - saethlin:remove-vec-as-ptr-assume, r=thomcc commit[5] 2023-03-21: Auto merge of - Nilstrieb:rollup-seb5xsa, r=Nilstrieb commit[6] 2023-03-21: Auto merge of - ferrocene:pa-test-metrics, r=Mark-Simulacrum commit[7] 2023-03-21: Auto merge of - compiler-errors:local-key, r=cjgillot commit[8] 2023-03-21: Auto merge of - matthiaskrgr:rollup-odn02wu, r=matthiaskrgr ERROR: no CI builds available between and within last 167 days
oh nevermind, still crashes with next-solver-coherence :cryingcatface:
Change:
#[inline] fn last(self) -> Option<A::Item> { match self.state { <del> ChainState::Both => self.b.last().or(self.a.last()), </del> <ins> ChainState::Both => { // Must exhaust a before b. let a_last = self.a.last(); let b_last = self.b.last(); b_last.or(a_last) }, </ins> ChainState::Front => self.a.last(), ChainState::Back => self.b.last() }

Discussion:
After some discussion about the libs subteam decided that iterator adaptors should always preserve the same semantics in terms of the convenience methods and such. This was not audited for when all the initial specializations landed, so we should take a look and make sure that everything adheres to this policy. Additionally, documentation should be to the trait methods indicating what form of guarantees you are given (e.g. calling is equivalent to exhausting the iterator). triage: I-nominated
I've checked . should exhaust before but that's the only bug I found (and it wasn't my bug for once :tada:). Unless, of course, you care about drop order. I haven't tried to reason about that.
The slice iterators () are fine because they are side-effect free.
and are fine because they are also side-effect free.
I'd appreciate it if someone else double checked but I think that's all of them.
This is relevant as well, because implementations of Drop may also (and usually do, in form of memory deallocation) contain side effects. Can we make a [x] list [x] of iterators which were specialised [x] like this?
I strongly disagree. Drop has side effects but programmers should never rely on drop order except stack drop order because drop order is often unspecified (e.g. within structs). core::iter::Chain::last core::iter::Peekable::last core::iter::Peekable::count (fixable) core::iter::Skip::last (fixable?)[x] core::iter::Chain [x] core::iter::Enumerate [x] core::iter::Peekable [x] core::iter::Skip [x] core::iter::Take [x] core::iter::Fuse [x] core::str::Bytes [x] core::slice::Iter [x] core::slice::IterMut [x] core::slice::Windows [x] core::slice::Chunks [x] core::slice::ChunksMut [x] collections::vec::IntoIter
Ah right, this will be decided by anyway.
Awesome, thanks for the work here
Updated list of out-of-order drops (didn't notice ).
triage: P-medium
(Need to make sure this behavior is documented/explicitly promised.)
Is this done?

(Everything in the list above is :whitecheckmark:'d)
I believe this is left open as to-be-documented. Also, I don't see any decision as to whether out of order drop is ok.
re-tagging as docs
So I believe that all of these are then documented in Iterator's methods, at least as far as I can tell. Can someone from libs double check me here and help provide any specifics as to what's not documented?
Looks good to me, thanks
Change:
per_local.insert(local); } } <del> cx.per_local[IsNotPromotable].insert(local); </del> <ins> cx.per_local[IsNotConst].insert(local); </ins> } LocalKind::Var if mode == Mode::Fn => {

Discussion:
Expected the following code to compile But getting Repro:
Also happens on beta, not on stable
Stable says:
For reference, the function signature as defined is exactly the same.
The actual ICE occurs first in nightly-2019-03-03 (...). But interesting enough, stable (as jonas pointed out) procuces an error, saying, that the third argument must be a constant. Since nightly-2019-02-16 (...) this does not emit an error anymore, but also does not ICE.
I guess for the "does not emit an error anymore" can say something about it. should be responsible for it.
triage: P-high
Note that because of the on the definition, you can't wrap it (without matching on and having 256 separate calls). I don't think this is intentional, but I'm not sure why it would happen, maybe arguments are treated incorrectly in the qualifier. cc
So I agree that this code can't compile, that's the expected behavior; if you want to wrap it, you have to use a macro - Rust functions aren't able to abstract over this type of hardware operations yet. The ICE is a regression over the error message that was being produced before. We should definitely add an ui test for that.
triage, assigning to self to fix the stable-to-beta regression.
The behavior here varies with edition as well as channel. edition 2018 ------------------ ------------------------ stable expected error beta unexpected compile-pass nightly-2019-04-05 ICE I think the most immediate thing to address is the unexpected compile-pass that has leaked into beta.
The easiest thing might be to revert
I have an actual fix in (also easier to backport than a revert)
Okay then I'm reassigning to
Change:
num_trait_args, num_impl_args, def_id, <del> impl_def_id: impl_m.container_id(tcx), </del> <ins> impl_m_def_id: impl_m.def_id, </ins> ty, return_span, }) {

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: expected lifetime parameter, but found another generic parameter', 'error: internal compiler error: expected lifetime parameter, but found another generic parameter' 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<!-- query stack: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of --
cc
Change:
} #[test] <ins> fn test_self_exe_name() { let path = os::self_exe_name(); assert!(path.is_some()); let path = path.unwrap(); debug!("{:?}", path.clone()); // Hard to test this function assert!(path.is_absolute()); } #[test] </ins> fn test_self_exe_path() { let path = os::self_exe_path(); assert!(path.is_some());

Discussion:
On OS X at least, it will think the link itself is the executable, then calculate sysroot based on that. Thanks to kyle for the report.
nominating to change to production ready
accepted for production-ready milestone
triage bump. still annoying.
or could be used to resolve the symlink. Would this issue warrant the badge "E_easy"?
Seems so! Adding the E-easy label.
Note that the relevant code is and it probably needs a check to see whether is a symlink or not.
seems important to fix for polish reasons. Accepted for P-high.
Change:
# Unless you're developing for a target where Rust CI doesn't build a compiler # toolchain or changing LLVM locally, you probably want to leave this enabled. # <del> # All tier 1 targets are currently supported; set this to `"if-available"` if # you are not sure whether you're on a tier 1 target. </del> <ins> # Set this to `"if-available"` if you are not sure whether you're on a tier 1 # target. All tier 1 targets are currently supported; </ins> # # We also currently only support this when building LLVM for the build triple. # <ins> # Set this to `"if-unchanged"` to only download if the llvm-project have not # been modified. (If there are no changes or if built from tarball source, # the logic is the same as "if-available") # </ins> # Note that many of the LLVM options are not currently supported for # downloading. Currently only the "assertions" option can be toggled. #download-ci-llvm = if rust.channel == "dev" { "if-available" } else { false }

Discussion:
The profile is intended not just for people working on LLVM itself, but also anyone who touches codegen but not LLVM. For example, anyone who modifies or is only changing the IR we send to LLVM, not LLVM itself. We should keep on for them but not for , but ideally we wouldn't build LLVM from source if it's unmodified. points out some things that we should fix before enabling that option by default for the profile: Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Should all 3 tasks be in one PR or is it 3 separate PR's?
I'd say it depends how challenging they are - if it's simple to fix all three in one PR that seems fine, but if it takes a more than a day to do one of the tasks, it probably makes sense to open a PR for it early.
I think I can tackle points 1 and 3 by tonight so I'll make that into one PR. I'll open a separate PR for the second point, since I think it has more work involved, if that's alright :)
release-assignment
Change:
.content span.mod, .content a.mod, block a.current.mod { color: #4d76ae; } .content span.enum, .content a.enum, .block a.current.enum { color: #5e9766; } .content span.struct, .content a.struct, .block a.current.struct { color: #e53700; } <del> .content span.fn, .content a.fn, .block a.current.fn { color: #8c6067; } .content span.method, .content a.method, .block a.current.method { color: #8c6067; } .content span.tymethod, .content a.tymethod, .block a.current.tymethod { color: #8c6067; } </del> <ins> .content a.primitive { color: #39a7bf; } .content a.type { color: #e57300; } .content a.macro { color: #068000; } .content span.fn, .content a.fn, .block a.current.fn, .content span.method, .content a.method, .block a.current.method, .content span.tymethod, .content a.tymethod, .block a.current.tymethod, </ins> .content .fnname { color: #8c6067; } .block a.current.crate { font-weight: 500; }

Discussion:
links should have colors to highlight that they are links: ! Some find it difficult to know which items are links. [EDIT] Removed sidebar circles. Never thought they needed changing.
has the same issue: ! [EDIT] Removed sidebar circles. Never thought they needed changing.
Totally agree. Also, instead of colors, we could use dashed underlines to indicate links while still keeping the same feel. (I disagree about the sidebar as well, I think its normal to expect those to be links, because they're in a sidebar without any text)
Sidebar is fine, thats a pretty normal convention to have those as links. At first glance I didn't realize most of the text in the main doc area was clickable however, I really like the idea of having the dashed underlines. +1
Didn't think sidebar necessarily should change. Was just highlighting black links. Edited pictures to removed sidebar circles.
Really quick mockup:  It doesn't show in the screenshot, but the last bool has the mouse over it, so it's darker.
code is and maybe some sort of style so it doesn't show up on the [src] link
CC: Don't have a branch but this is probably a straightforward fix if you decide on a style. Or if you like nightpool's suggestion.
I like that style, I think. I am bad at looks, though.
If there are any other decent styles worth pursuing (different brown variant, solid underline, combo, red...I'm just guess here), a quick mockup of them would allow easy compare and contrast. It would allow an easier/faster decision.
+1 from me
I'm currently playing with rustdoc. I may try to implement this once the docs are built.
Change:
<del> Subproject commit 5afdf8b78507ddf015d192858aef56e72c17de16 </del> <ins> Subproject commit b1d0343749bdc87e5cbbe7f1aeaa9d2a2c9dbc5b </ins>

Discussion:
ARC is beginning to infect more and more types, and they each must have a clone method, but there is no trait to implement.
related
Along with this, we should provide a default implementation of Clonable for all copyable types.
Closing this now that has been implemented. There are no doubt some types left that should have a implementation, but they can be dealt with on a case-by-case basis.
Change:
#[prelude_import] use std::prelude::v1::*; #[macro_use] <del> extern crate std as std; </del> <ins> extern crate std; </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.

Discussion:
Since the check no longer panics on failure. It is obvious in the commit that the invocation is removed from the check, and no other changes are made in the function to remedy it. It can be verified by adding a new pretty test case like: The resulting pretty printed file is slightly different, the comparison fails and the message is logged, but the test continues into the type check, which fails for a different reason and then panics. If you fix the type check (by adding the module and fn main) then the whole test passes and the error message is swallowed even though the source comparison is still not matching.
Change:
<ins> //@ compile-flags: -Clink-dead-code=on --crate-type=lib //@ build-pass #![feature(trivial_bounds)] #![allow(trivial_bounds)] // Make sure we don't monomorphize the drop impl for `Baz`, since it has predicates // that don't hold under a reveal-all param env. trait Foo { type Assoc; } struct Bar; struct Baz(<Bar as Foo>::Assoc) where Bar: Foo; </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Clink-dead-code=true --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: Failed to normalize Alias(Projection, AliasTy { args: [Bar], defid: DefId(0:4 ~ tribo[552e]::Foo::Assoc) }), maybe try to call instead', 'error: internal compiler error: Failed to normalize Alias(Projection, AliasTy { args: [Bar], defid: DefId(0:4 ~ tribo[552e]::Foo::Assoc) }), maybe try to call instead' 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<!-- query stack: [mirshims] generating MIR shim for [collectandpartitionmonoitems] collectandpartitionmonoitems -- label +F-trivialbounds
cc this is the one that still crashes from
Change:
self } <ins> fn groups( &mut self, #[cfg(not(target_os = "vxworks"))] groups: &[u32], #[cfg(target_os = "vxworks")] groups: &[u16], ) -> &mut process::Command { self.as_inner_mut().groups(groups); self } </ins> unsafe fn pre_exec<F>(&mut self, f: F) -> &mut process::Command where F: FnMut() -> io::Result<()> + Send + Sync + 'static,

Discussion:
already offers and methods to control the user identity of the child process (calling respectively). For complete control of Unix credentials, there should also be a way to call and the concept of the supplementary group list are; I would expect this not to be a portability concern.) This feature would eliminate a use of and an unsafe block (to call ) from the program I'm currently writing, which is a port to Rust of a setuid C program. For illustration, this function exists in the C version: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would be prepared to consider a PR to add .
claim
Change:
<del> warning: empty trait list in `derive` </del> <ins> error: unused attribute </ins> --> $DIR/deriving-meta-empty-trait-list.rs:3:1 | LL | #[derive()] | ^^^^^^^^^^^ <ins> | note: lint level defined here --> $DIR/deriving-meta-empty-trait-list.rs:1:9 | LL | #![deny(unused)] |         ^^^^^^ = note: #[deny(unused_attributes)] implied by #[deny(unused)] error: aborting due to previous error </ins>

Discussion:
The following code emits an unsquelchable warning. This warning should be a part of .
empty trait list in should have a lint name ... and that name is .
Does not appear to squelch the warning for me...
It seems eminently reasonable to me to include in since it is an attribute applied with no effect; so let's kick off fcp for that. merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), 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.
Implementing this as part of the existing would be complicated by , but it might also be possible to implement where the existing "empty trait list" warning is issued (possibly as a ).
I need to make a buffered early lint for the same thing with .
Seems reasonable. And a macro that might end up with an empty derive list should have no problem turning off locally.
reviewed I certainly agree with moving warnings to lints.
: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.
Change:
<ins> error[E0277]: the size for values of type `(dyn Trait + 'static)` cannot be known at compilation time --> $DIR/issue-65673.rs:9:5 | LL |     type Ctx; |          --- associated type defined here ... LL | impl<T> WithType for T { | ---------------------- in this `impl` item LL |     type Ctx = dyn Alias<T>; |     ^^^^^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time | = help: the trait `std::marker::Sized` is not implemented for `(dyn Trait + 'static)` = note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait> error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
The following code panics the compiler:
backtrace: <details</details
~Likely diagnostic related :-/~ Disregard that.
Slightly reduced: can also be , but I though this will remove one more warning, so it's worth using here ^^
triage: P-medium. removing nomination label. reasoning: you get the feature flag diagnostic, including the span of the offending code and the suggestion of what to write. So this is reasonable for users to deal with, even with the ICE. (as opposed to cases where the ICE occurs without any useful output for the user.)
Change:
} } <ins> /// Given a 'Span', tries to tell if the next character is '>' /// and the previous charactoer is '<' after skipping white space /// return true if wrapped by '<>' pub fn span_wrapped_by_angle_bracket(&self, span: Span) -> bool { self.span_to_source(span, |src, start_index, end_index| { if src.get(start_index..end_index).is_none() { return Ok(false); } // test the right side to match '>' after skipping white space let end_src = &src[end_index..]; let mut i = 0; while let Some(cc) = end_src.chars().nth(i) { if cc == ' ' { i = i + 1; } else if cc == '>' { // found > in the right; break; } else { // failed to find '>' return false immediately return Ok(false); } } // test the left side to match '<' after skipping white space i = start_index; let start_src = &src[0..start_index]; while let Some(cc) = start_src.chars().nth(i) { if cc == ' ' { if i == 0 { return Ok(false); } i = i - 1; } else if cc == '<' { // found < in the left break; } else { // failed to find '<' return false immediately return Ok(false); } } return Ok(true); }) .map_or(false, |is_accessible| is_accessible) } </ins> /// Given a `Span`, tries to get a shorter span ending just after the first occurrence of `char` /// `c`. pub fn span_through_char(&self, sp: Span, c: char) -> Span {

Discussion:
Given the following code (): The current output is: This suggestion is on the right track, but unfortunately it introduces a parse error. It should be: This suggestion is in . It suggests adding around the type because the type is a slice, but I already have in my program (and the span doesn't include the existing ). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim