jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: lifetime may not live long enough --> $DIR/issue-98170.rs:7:9 | LL | impl MyStruct<'_> { |               -- lifetime `'1` appears in the `impl`'s self type LL |     pub fn new<'a>(field: &'a [u32]) -> MyStruct<'a> { |                -- lifetime `'a` defined here LL |         Self { field } |         ^^^^^^^^^^^^^^ associated function was supposed to return data with lifetime `'a` but it is returning data with lifetime `'1` error: lifetime may not live long enough --> $DIR/issue-98170.rs:7:16 | LL | impl MyStruct<'_> { |               -- lifetime `'1` appears in the `impl`'s self type LL |     pub fn new<'a>(field: &'a [u32]) -> MyStruct<'a> { |                -- lifetime `'a` defined here LL |         Self { field } |                ^^^^^ this usage requires that `'a` must outlive `'1` error: lifetime may not live long enough --> $DIR/issue-98170.rs:19:9 | LL | impl<'a> Trait<'a> for MyStruct<'_> { |      --                         -- lifetime `'1` appears in the `impl`'s self type |      | |      lifetime `'a` defined here LL |     fn new(field: &'a [u32]) -> MyStruct<'a> { LL |         Self { field } |         ^^^^^^^^^^^^^^ associated function was supposed to return data with lifetime `'a` but it is returning data with lifetime `'1` error: lifetime may not live long enough --> $DIR/issue-98170.rs:19:16 | LL | impl<'a> Trait<'a> for MyStruct<'_> { |      --                         -- lifetime `'1` appears in the `impl`'s self type |      | |      lifetime `'a` defined here LL |     fn new(field: &'a [u32]) -> MyStruct<'a> { LL |         Self { field } |                ^^^^^ this usage requires that `'a` must outlive `'1` error: aborting due to 4 previous errors </ins>

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details
Changing Self{field} to MyStruct{field} makes it build btw.
I haven't done a search for the exact commit, but on the playground this regressed between beta and nightly. label +regression-from-stable-to-nightly
This is due to the NLL stabilization PR , since it manifests with on 1.61 (with to allow feature flags). I'll be looking at it in a few hours when I get home!
Change:
( StatementKind::Assign(box (_, rhs)), StatementKind::SetDiscriminant { place, variant_index }, <del> ) // we need to make sure that the switch value that targets the bb with SetDiscriminant (y), is the same as the variant index if Some(variant_index.index() as u128) == y_target_and_value.value => { </del> <ins> ) if y_target_and_value.value.is_some() => { </ins> // choose basic block of x, as that has the assign <del> helper(rhs, place, variant_index, x_target_and_value.target) </del> <ins> helper( rhs, place, variant_index, y_target_and_value.value.unwrap(), x_target_and_value.target, ) </ins> } ( StatementKind::SetDiscriminant { place, variant_index }, StatementKind::Assign(box (_, rhs)), <del> ) // we need to make sure that the switch value that targets the bb with SetDiscriminant (x), is the same as the variant index if Some(variant_index.index() as u128) == x_target_and_value.value  => { </del> <ins> ) if x_target_and_value.value.is_some() => { </ins> // choose basic block of y, as that has the assign <del> helper(rhs, place, variant_index, y_target_and_value.target) </del> <ins> helper( rhs, place, variant_index, x_target_and_value.value.unwrap(), y_target_and_value.target, ) </ins> } _ => { trace!("NO: statements `{:?}` and `{:?}` not considered equal", x, y);

Discussion:
Originally found by when experimenting with discriminants starting from 1 in modify labels: +regression-from-stable-to-stable +I-unsound
After a quick it appears that the regression appear with Rust 1.48.0
A bisection seems to lead to , nightly 2020-09-26 from to
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Looks like it is mostly likely caused by which is supposed to cc
Change:
} // Ninja is currently only used for LLVM itself. <del> // Some Linux distros rename `ninja` to `ninja-build`. // CMake can work with either binary name. if building_llvm && build.config.ninja && cmd_finder.maybe_have("ninja-build").is_none() { cmd_finder.must_have("ninja"); </del> <ins> if building_llvm { if build.config.ninja { // Some Linux distros rename `ninja` to `ninja-build`. // CMake can work with either binary name. if cmd_finder.maybe_have("ninja-build").is_none() { cmd_finder.must_have("ninja"); } } // If ninja isn't enabled but we're building for MSVC then we try // doubly hard to enable it. It was realized in #43767 that the msbuild // CMake generator for MSVC doesn't respect configuration options like // disabling LLVM assertions, which can often be quite important! // // In these cases we automatically enable Ninja if we find it in the // environment. if !build.config.ninja && build.config.build.contains("msvc") { if cmd_finder.maybe_have("ninja").is_some() { build.config.ninja = true; } } </ins> } build.config.python = build.config.python.take().map(|p| cmd_finder.must_have(p))

Discussion:
When working locally dmajor has found that apparently disabling LLVM assertions doesn't work on MSVC when compiling LLVM. Despite apparently they're still compiled in! This isn't the first time IIRC of LLVM definitions and such not actually getting communicated to the msbuild build system. My guess is that this is a bug in LLVM's build system or something like that. In any case I think we should at least start using by default if we detect ninja in PATH, and otherwise we may want to print warnings on "known bad" cases saying that msbuild isn't reading configuration options correctly, recommending a download of ninja
It looks like may also be communicated to msbuild but not implemented? It apparently works well though when compiled with ninja!
Change:
passes_unused_var_remove_field = unused variable: `{$name}` passes_unused_var_remove_field_suggestion = try removing the field <ins> passes_unused_variable_args_in_macro = `{$name}` is captured in macro and introduced a unused variable </ins> passes_unused_variable_try_ignore = unused variable: `{$name}` .suggestion = try ignoring the field

Discussion:
Consider the following file in a cargo package: Cargo will warn that is not used. Upon running , cargo will change the second parameter from to , making the compilation fail. Even worse, if contained a field then would change the variable without producing any warning. a new cargo binary project with the above snippet in (presumably with ) No response No response
just applies any  suggestion produced by . In this case, the suggestion from is to replace with . I went ahead and ran to see if it could help me understand what is going on better: ` (I cleaned up the expanded code slightly, but it is the same) Looking at the expanded code, it makes me think that is seeing in as the source of the problem since it expands to and is unused in this case. The normal suggestion is to add an underscore to so it would not be "unused". So suggests to change the being passed to the macro call as it does not understand that the warning is really coming from within the macro, not the call itself. It also could be suggesting this as is not valid rust (macro?) syntax. If you change your example slightly, correctly suggests the problem comes from within the macro call. To me, this seems like a problem with , but I do not know enough about the compiler internals to be 100% certain.
Transferred to rust-lang/rust, since the suggestions are generated by the compiler.
Yes, this issue comes from rustc. The lint is emitted from here Maybe we only point out that there is an unused variable coming from , but without the suggestion? I'm not sure what is a proper lint for this test case. any thoughts on it?
The quick and straightforward way to fix this would be to only emit the suggestion in this lint if the span has the root context, but then a subset of valid suggestions wouldn't be emitted. I had an older PR that I'm having trouble finding that would automatically do that for every diagnostic, but IIRC it had some negative perf impact when not implementing it very simplistic. In this we can probably instead check that all of the spans involved have the same . If they don't, don't suggest changes.
Change:
#[cfg(target_env = "newlib")] pub fn set_cloexec(&self) { unsafe { <del> let previous = libc::fnctl(self.fd, libc::F_GETFD); let ret = libc::fnctl(self.fd, libc::F_SETFD, previous | libc::FD_CLOEXEC); </del> <ins> let previous = libc::fcntl(self.fd, libc::F_GETFD); let ret = libc::fcntl(self.fd, libc::F_SETFD, previous | libc::FD_CLOEXEC); </ins> debug_assert_eq!(ret, 0); } }

Discussion:
I noticed that has this code: I'm pretty sure that should be ("file control"), not : the call is consistent with the use of on other UNIXes, and as far as I can tell, the newlib git repo defines but not . This would need to be fixed in both libstd and liblibc. But there's an explicit mention of this code in the PR introducing it (), and I'm sort of surprised that this would link if it were misspelled, let alone work, so maybe I'm missing something? If this is correct, a comment would be nice. :) cc
You're right, oops (PNaCl isn't testable yet within Rust proper, so I didn't catch it!).
Change:
checksum = "39ec24b3121d976906ece63c9daad25b85969647682eee313cb5779fdd69e14e" [[package]] <ins> name = "unified-diff" version = "0.2.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "496a3d395ed0c30f411ceace4a91f7d93b148fb5a9b383d5d4cff7850f048d5f" dependencies = [ "diff", ] [[package]] </ins> name = "unstable-book-gen" version = "0.1.0" dependencies = [

Discussion:
When running on Linux and a failure happens, a really nice diff of the output vs rustdoc-nightly is produced which very clearly shows the issue. This does not work on Windows for multiple reasons. One the call to fails: Second, the output from rustdoc-nightly seems to exactly match that from the local compiler making it not possible to do manual diffs.
How do you diff directories recursively on Windows? On Linux I would be very surprised for not to be installed. Oh I just thought of something - do you have a rustup overide that defaults to your local toolchain? Right now compiletest assumes the default is nightly, I've been meaning to change it.
No, I only set overrides on specific projects (and rust-lang/rust is not one of them). My default is the stable compiler.
Git for Windows provides : Are you building Rust using Git Bash prompt?
I don't think it'd be a good idea to require testing rustdoc in the Git for Windows bash shell. I'd like for this to work in and PowerShell if possible.
Change:
// The algorithm is now this: // is_niche = tag <= niche_end // discr = if is_niche { <del> //     cast(tag) + (niche_variants.start() - niche_start) </del> <ins> //     cast(tag + (niche_variants.start() - niche_start)) </ins> // } else { //     untagged_variant // } // (the first line may instead be tag >= niche_start, // and may be a signed or unsigned comparison) <ins> // The arithmetic must be done before the cast, so we can // have the correct wrapping behavior. See issue #104519 for // the consequences of getting this wrong. </ins> let is_niche = bx.icmp(predicate, tag, bx.cx().const_uint_big(tag_llty, constant)); <ins> let delta = (niche_variants.start().as_u32() as u128).wrapping_sub(niche_start); let incr_tag = if delta == 0 { tag } else { bx.add(tag, bx.cx().const_uint_big(tag_llty, delta)) }; </ins> let cast_tag = if cast_smaller { <del> bx.intcast(tag, cast_to, false) </del> <ins> bx.intcast(incr_tag, cast_to, false) </ins> } else if niches_ule { <del> bx.zext(tag, cast_to) </del> <ins> bx.zext(incr_tag, cast_to) </ins> } else { <del> bx.sext(tag, cast_to) </del> <ins> bx.sext(incr_tag, cast_to) </ins> }; <del> let delta = (niche_variants.start().as_u32() as u128).wrapping_sub(niche_start); (is_niche, cast_tag, delta) </del> <ins> (is_niche, cast_tag, 0) </ins> } else { // The special cases don't apply, so we'll have to go with // the general algorithm.

Discussion:
I tried this code (reduced from a much larger test): () I expected to see this happen: runs with 0 exit code and no output Instead, this happened: This code works on stable and beta, and as recently as . This reproduces with the 2022-11-16 nightly on the playground. this was introduced by . modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That looks like a real miscompilation :( cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
I've found the problem; it is indeed an issue with my code in . I'll have a PR with a fix some time today.
Since there is some work in progress to fix this: assign
Change:
Def::Variant(..) | Def::Const(..) => { self.record_def(pattern.id, path_res); } <del> Def::Static(..) => { </del> <ins> Def::Static(did, _) => { </ins> resolve_error(&self, path.span, <del> ResolutionError::StaticVariableReference); </del> <ins> ResolutionError::StaticVariableReference( did, None)); </ins> self.record_def(pattern.id, err_path_resolution()); } _ => {

Discussion:
Rustc version: rustc 1.0.0-nightly ( 2015-03-22) (built 2015-03-23)
Hmm, I am not sure if this is a bug or not. I can see it both ways.
As I understand, this error is related to the situation like this
Change:
} } } <del> highlightSourceLines(null); </del> <ins> function expandSection(id) { var elem = document.getElementById(id); if (elem && isHidden(elem)) { var h3 = elem.parentNode.previousSibling; if (h3 && h3.tagName !== 'H3') { h3 = h3.previousSibling; // skip div.docblock } if (h3) { var collapses = h3.getElementsByClassName("collapse-toggle"); if (collapses.length > 0) { // The element is not visible, we need to make it appear! collapseDocs(collapses[0], "show"); } } } } </ins> window.onhashchange = highlightSourceLines; // Gets the human-readable string for the virtual-key code of the

Discussion:
Stable documentation (e.g. ): Click on to collapse everything Click on in Page will be scrolled to the . Nightly documentation (e.g. ): Click on to collapse everything Click on in Nothing will happen, because the is inside a collapsed outer section.
Another example: Click the word in the description on the page Nothing happens, making it appear that the link is broken. Since trait impls are collapsed by default, AFAIK there is no way to properly link to them. I'm guessing this would need to be implemented in and , and check if the block is hidden?
Change:
<ins> // Copyright 2014-2015 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. struct Test { a: isize, b: Option<Box<Test>>, } impl Drop for Test { fn drop(&mut self) { println!("Dropping {}", self.a); } } fn stuff() { let mut t = Test { a: 1, b: None}; let mut u = Test { a: 2, b: Some(Box::new(t))}; t.b = Some(Box::new(u)); //~^ ERROR partial reinitialization of uninitialized structure `t` println!("done"); } fn main() { stuff(); println!("Hello, world!") } </ins>

Discussion:
So I was curious how Drop handles cycles, because this could lead to dangling pointers, which is why . And indeed the below example does not call Drop. But is moved into , so why does this compile at all?
Nominating, seems like a soundness hole.
This is an issue with zeroing dynamic drops (which are going to be removed: rust-lang/rfcs) – when is moved, its drop flag is cleared, which prevents the destructor of from running. A clearer example is:
Structs that implement drop are not supposed to be in a partially initialized state. We already prevents moves out from individual fields, but we also need to prevent individual fields from being re-initialized. cc since (iirc?) he was working on the patches that made us more accepting around re-initializing fields and so forth, and maybe this bug is of interest to him.
So we are not supposed to allow structs that implement drop to be partially initialized. We already disallow going from fully-initialized to partially initialized. But it seems (from the first example) that we missed disallowing going from fully-uninitialized to partially initializd. That needs to be fixed. Assigning P-backcompat-lang, 1.0.
While this will hopefully be fixed soon, as there is a PR up, it seems to have fallen through the cracks as a P-backcompat-lang issue that is only on the 1.0 milestone and not 1.0 beta. Nominating for 1.0 beta. (Also, I guess I will try to run through and find any other such overlooked issues.)
Assigning 1.0 beta.
Change:
<ins> fn foo<'a>(_: impl 'a Sized) {} //~^ ERROR: expected `+` between lifetime and Sized //~| ERROR: expected one of `:`, `@`, or `|`, found `)` //~| ERROR: expected one of `)`, `+`, or `,`, found `Sized` //~| ERROR: at least one trait must be specified fn main(){ } </ins>

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. --I tried this almost-correct code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
Space 6+2:                     compare A Ogham Space Mark 6+2: compare B */ /* */ /*

Discussion:
Note: missing newline after is essential. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I've not been able to reproduce this on the latest nightly, I've bisected it to have been fixed in 2020-07-15 (report used 2020-07-11), probably by ; I've filed with a regression test.
Me neither.
Change:
write_deadline: u64, } <del> unsafe impl Send for UnixStream {} unsafe impl Sync for UnixStream {} </del> impl UnixStream { fn try_connect(p: *const u16) -> Option<libc::HANDLE> { // Note that most of this is lifted from the libuv implementation.

Discussion:
There are quite few os-specific types definitions whose traits implementations are not consistent. With the work happening in OIBIT, I've tried to keep the implementations of built-in traits consistent for both and . Unfortunately, the test suite for these implementations is not unified, therefore there's a high chance that some types for 's implementation may have some traits implemented, whereas the 's implementation doesn't. In theory, we can assume that common types for these implementations should implement the same built-in types, therefore there should be tests that enforce this guarantee in a common place. Some examples may be found in This bug is to track the work there which impacts the of our standard library.
I can mentor on this bug, tagging with
seems interesting. Can i take this bug? :)
it's all yours, lemme know if you need help/reviews
This should be closed now right?
correct. Thanks!
Change:
ctrl = table.GetChildMemberWithName("ctrl").GetChildAtIndex(0) self.size = table.GetChildMemberWithName("items").GetValueAsUnsigned() <del> self.pair_type = table.type.template_args[0].GetTypedefedType() </del> <ins> self.pair_type = table.type.template_args[0] if self.pair_type.IsTypedefType(): self.pair_type = self.pair_type.GetTypedefedType() </ins> self.pair_type_size = self.pair_type.GetByteSize() self.new_layout = not table.GetChildMemberWithName("data").IsValid()

Discussion:
The LLDB provider for hash maps has been broken since . Repro: Run this, notice that it doesn't print any values for the hash map: Using an older version works (1.49 or earler): I don't understand the motivation for , as you can see the older versions are able to display the type. can you clarify what is going on? I did some debugging, and the and values are invalid. Another way to check this is to run the  test. Due to it hasn't been running on CI. It has a check for the following output: But the actual output is:
I checked the issue with two different LLDB: shipped with LLDB built from LLVM 10.0.1 sources with Rust patches by adding the following code to the method: So it seems like the problem only occurs with . Probably this is due to the lack of Rust patches in . AFAIU the Rust patches still have not been to (I remember this related issue ). To fix this problem, the following code should be used insted: I've opened a PR with these changes: However, I believe that should use Rust patches not only to avoid this specific problem but to provide a much better debugging experience, with proper type rendering (e.g. instead of ), some expression evaluation support, and so forth. It is really unfortunate that Rust debugging support is not maintained enough except for some independent forks, for example, and CLion's LLDB.
I may be misunderstanding you, but is just a that runs the system lldb. Building lldb with patches was removed a long time ago (), and I suspect is not coming back in the foreseeable future.
Oh, that's even worse since macOS LLDB has very poor Rust support. I believe that debugging support is crucial for any compiled programming language, surely including Rust. So it would be really great to consider shipping rust-enabled LLDB and, more importantly, to maintain and improve Rust support in both GDB and LLDB.
Change:
<ins> #![crate_type = "lib"] pub mod f {} pub use unresolved::f; //~^ ERROR unresolved import `unresolved` /// [g] pub use f as g; fn main() {} </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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
searched nightlies: from nightly-2023-02-10 to nightly-2023-03-18 regressed nightly: nightly-2023-02-12 searched commit range: regressed commit: cc
Could you assign it to me, I am willing to try to solve the problem
Change:
(FxHashSet::default(), FxHashSet::default(), Vec::new()) }); entry.2.push(p); <del> if cause.span != *item_span { entry.0.insert(cause.span); entry.1.insert((cause.span, "unsatisfied trait bound introduced here")); </del> <ins> if cause_span != *item_span { entry.0.insert(cause_span); entry.1.insert((cause_span, "unsatisfied trait bound introduced here")); </ins> } else { if let Some(trait_ref) = of_trait { entry.0.insert(trait_ref.path.span);

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. --: <!-- 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 --<!-- TRIAGEBOTEND --
Minimized via  and some manual item deletion: I can take a quick look into this one I guess. claim