jiebi/CodeConvo huggingface dataset:
Change:
all: $(RUSTC) --crate-type rlib -lbar_cli bar.rs <del> $(RUSTC) foo.rs -lfoo_cli --crate-type staticlib --print native-static-libs 2>&1  </del> <ins> $(RUSTC) foo.rs -lfoo_cli -lfoo_cli --crate-type staticlib --print native-static-libs 2>&1  </ins> | grep 'note: native-static-libs: '  | sed 's/note: native-static-libs: (.*)/1/' > $(TMPDIR)/libs.txt

Discussion:
Hi there, In we use to try and keep our crate's linking instructions up-to-date across supported platforms. We've noticed that in some build configurations the output can change in surprising ways. For instance, using rustc nightly (1.70.0) on Windows (x8664-pc-windows-msvc) in a configuration driven by we see many consecutive duplicate libraries in the output. I understand duplicates are to be expected, and can be meaningful on some platforms, but seeing so many consecutive repeats seems unexpected and unlikely to be meaningful for the build process. Is this perhaps a regression? Or are we making a mistake by relying on the stability of this output across versions/build configurations? This feature is as having a known prefix to "make it easier to fetch the output." leading to the idea that it is expected to be machine consumable. I tried this code: I expected to see this happen: A list produced, with some duplicates (e.g. multiple ), but not many consecutive duplicates. E.g.: Instead, this happened: A list with many consecutive duplicates is produced: </detailsrustc nightly (1.70.0) on Windows (x8664-pc-windows-msvc) in a configuration. rustc nightly (1.70.0) on Windows (x8664-pc-windows-msvc) in a configuration. Project: Build task: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hm, I thought we usually removed consecutive duplicates but apparently only in release. A workaround would be to do so manually. For the msvc targets all duplicates can be removed so long as the order is preserved. This isn't true of many other targets though. It would be much better to have a proper fix though.
Thanks for the quick reply :-) That's we landed on for the short term :+1: Great, thanks for clarifying.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
claim
Error: Parsing assign command in failed: ...' assign' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Thanks !
Change:
<del> Subproject commit e8d5a9e95c145a3a9be89c582d8a6f88d4ea7037 </del> <ins> Subproject commit 8ab24d76dd6990394e72e94d08021df9a7e4e6c9 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium. Removing I-nominated.
There is opening PR to fix this:
Change:
ret fld.fold_obj(env, fields, meths); } <ins> fn fold_view_item[ENV](&ENV env, ast_fold[ENV] fld, @view_item vi) -> @view_item { let ENV env_ = fld.update_env_for_view_item(env, vi); if (!fld.keep_going(env_)) { ret vi; } alt (vi.node) { case (ast.view_item_use(?ident, ?meta_items, ?def_id)) { // FIXME: what other folding should be done in here? ret fld.fold_view_item_use(env_, vi.span, ident, meta_items, def_id); } case (ast.view_item_import(?idents, ?def_id)) { // FIXME: what other folding should be done in here? ret fld.fold_view_item_import(env_, vi.span, idents, def_id); } } fail; } </ins> fn fold_item[ENV](&ENV env, ast_fold[ENV] fld, @item i) -> @item { let ENV env_ = fld.update_env_for_item(env, i);

Discussion:
I was trying to build the stdlibs for the target like this: However, the build fails with the following error: Here is the full build log: I'm using Xubuntu 15.10. At the time of building, the Rust master was at .
Unfortunately is a which means that we don't guarantee that it builds in-tree right now. Patches are certainly welcome to fix this, however! We tend to not keep issues tracking build support for all Tier 3 platforms, however, so I'm going to close this. If you're interested in promoting this to at least tier 2 you could also help modify out to be able to support this target!
Change:
<ins> // Regression test for #60218 // // This was reported to cause ICEs. use std::iter::Map; pub trait Foo {} pub fn trigger_error<I, F>(iterable: I, functor: F) where for<'t> &'t I: IntoIterator, for<'t> Map<<&'t I as IntoIterator>::IntoIter, F>: Iterator, for<'t> <Map<<&'t I as IntoIterator>::IntoIter, F> as Iterator>::Item: Foo, { } fn main() { trigger_error(vec![], |x: &u32| x) //~ ERROR E0277 } </ins>

Discussion:
The following code: results in an ICE Tested this on stable and nightly. May be somehow related to .
Backtrace: Happens on stable, beta, nightly
Litte bit simplified:
Bisection show ICE was introduced in , but I'm not sure how related that is, because it's a very very big PR. CC
I will investigate.
ping , any progress here?
I did some investigation. This bugs turns out to have been fixed -- well, more likely it was worked around by I'm going to land a test for it so that when I get around to reversing , I can fix it then.
Change:
})?); if let ty::Projection(..) = placeholder_self_ty.kind() { <del> for predicate in tcx.predicates_of(def_id).instantiate_own(tcx, substs).predicates { </del> <ins> let predicates = tcx.predicates_of(def_id).instantiate_own(tcx, substs).predicates; debug!(?predicates, "projection predicates"); for predicate in predicates { </ins> let normalized = normalize_with_depth_to( self, obligation.param_env,

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. --Within an , a GAT bound of does not compile, asking me to add an explicit bound. This code results in two errors: I believe that the error is a bug, as since is known in this to be , must outlive and the suggested bound should thus already be implied by . Applying the suggested fix removes this error, but obviously cannot compile (as the GAT impl now has a stricter than in the declaration). The first error seems incorrect too, as there is no visible difference between the highlighted lines other than : Adding the type bound on the declaration avoids these errors, but is less generic. <!-- 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. --: I have also encountered this bug on . </details
label +F-genericassociatedtypes +T-compiler
It's both rude and unconstructive to suggest that issues are not tracked. First and foremost, this is an unstable feature. Second, this issue was filed 15 days ago, right in the middle of holidays. Third, its labeled appropriately, and I'll either triage or fix it when I can. I'm going to delete the above comment since it's not constructive at all.
I forgot what I said before, but if I said something bad, I'm really sorry for that
Change:
#[inline] fn size_hint(&self) -> (usize, Option<usize>) { <del> let (low, high) = self.chars.size_hint(); // every char gets either one u16 or two u16, // so this iterator is between 1 or 2 times as // long as the underlying iterator. (low, high.and_then(|n| n.checked_mul(2))) </del> <ins> let len = self.chars.iter.len(); // The highest bytes:code units ratio occurs for 3-byte sequences, // since a 4-byte sequence results in 2 code units. The lower bound // is therefore determined by assuming the remaining bytes contain as // many 3-byte sequences as possible. The highest bytes:code units // ratio is for 1-byte sequences, so use this for the upper bound. // `(len + 2)` can't overflow, because we know that the `slice::Iter` // belongs to a slice in memory which has a maximum length of // `isize::MAX` (that's well below `usize::MAX`) if self.extra == 0 { ((len + 2) / 3, Some(len)) } else { // We're in the middle of a surrogate pair, so add the remaining // surrogate to the bounds. ((len + 2) / 3 + 1, Some(len + 1)) } </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. --I tried this code: I expected to see this happen: 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. --: The reason is that the iterator calculates its size hint in terms of the contained iterator size hint, assuming that each character can correspond to either 1 or 2 code units. In the case that the iterator is NOT in the middle of a surrogate pair, this leads to too-low lower bounds and too high upper-bounds. In the case that the iterator IS in the middle of a surrogate pair, the remaining code unit is not taken into account as the iterator has advanced past this point. The actual calculation should be done in terms of the remaining bytes: The lower bound is achieved by assuming the remaining bytes consist of as many 3-byte sequences as possible, optionally followed by a 1 or 2-byte sequence, leading to a lower bound of The upper bound is achieved by assuming the remaining bytes consist of 1-byte sequences, leading to an upper bound of . In the case of the iterator being positioned in the middle of a surrogate pair, both these values should be increased by 1.
, size hints are allowed to be looser than necessary. As the documentation says But if it can be made tighter while still being correct for all values that's fine. Edit: Oh, yeah. This one is actually a bug since the iterator is not exhausted at that point.
Change:
&& argmap.iter().enumerate().all(|(i, (&(j, _), _))| i == j) && arguments.iter().skip(1).all(|arg| !may_contain_yield_point(&arg.expr)); <del> let args = if use_simple_array { </del> <ins> let args = if arguments.is_empty() { // Generate: //    &<core::fmt::Argument>::none() // // Note: //     `none()` just returns `[]`. We use `none()` rather than `[]` to limit the lifetime. // //     This makes sure that this still fails to compile, even when the argument is inlined: // //     ``` //     let f = format_args!("{}", "a"); //     println!("{f}"); // error E0716 //     ``` // //     Cases where keeping the object around is allowed, such as `format_args!("a")`, //     are handled above by the `allow_const` case. let none_fn = ctx.arena.alloc(ctx.expr_lang_item_type_relative( macsp, hir::LangItem::FormatArgument, sym::none, )); let none = ctx.expr_call(macsp, none_fn, &[]); ctx.expr(macsp, hir::ExprKind::AddrOf(hir::BorrowKind::Ref, hir::Mutability::Not, none)) } else if use_simple_array { </ins> // Generate: //     &[ //         <core::fmt::Argument>::new_display(&arg0),

Discussion:
Before , this gave an error: But after , that no longer gives an error. Ideally it shouldn't give an error in any case, but that's . Inlining/flattening format_args shouldn't change what compiles and what doesn't compile, so, for now, this still shouldn't compile.
Luckily the fix is easy. We just need to make sure that any with arguments still results in an expansion that involves borrowing a temporary.
Fix here:
Change:
//! Shareable mutable containers. //! <ins> //! Rust memory safety is based on this rule: Given an object `T`, it is only possible to //! have one of the following: //! //! - Having several immutable references (`&T`) to the object (also known as **aliasing**). //! - Having one mutable reference (`&mut T`) to the object (also known as **mutability**). //! //! This is enforced by the Rust compiler. However, there are situations where this rule is not //! flexible enough. Sometimes it is required to have multiple references to an object and yet //! mutate it. //! //! Shareable mutable containers exist to permit mutability in a controlled manner, even in the //! presence of aliasing. Both `Cell<T>` and `RefCell<T>` allows to do this in a single threaded //! way. However, neither `Cell<T>` nor `RefCell<T>` are thread safe (they do not implement //! `Sync`). If you need to do aliasing and mutation between multiple threads it is possible to //! use [`Mutex`](../../std/sync/struct.Mutex.html), //! [`RwLock`](../../std/sync/struct.RwLock.html) or //! [`atomic`](../../core/sync/atomic/index.html) types. //! </ins> //! Values of the `Cell<T>` and `RefCell<T>` types may be mutated through shared references (i.e. //! the common `&T` type), whereas most Rust types can only be mutated through unique (`&mut T`) //! references. We say that `Cell<T>` and `RefCell<T>` provide 'interior mutability', in contrast

Discussion:
EDIT: also
Without consent from there might be license issues, as rust docs are under the Apache2/MIT dual license and stack overflow posts are CC-BY-SA.
I am perfectly happy to give consent, and for the content to be reused in whole or in parts, altered or not, and without citation (as it would I think disturb the flow of reading).
Hi there! I would love to help work on this bug if it's still available!
yep, it's still available! if you have any questions or need any help, don't hesitate to ask!
did you make any progress on this or is it open for someone else to start work on it?
Unfortunately I wasn't able to - please open it for other individuals to take a shot
If its ok I would like to do this
Sounds great If you want any help or don't know where to start or have any questions, don't hesitate to ask!
Change:
= help: use `//` for a plain comment error: unused doc comment <del> --> $DIR/unused-doc-comments-edge-cases.rs:33:5 </del> <ins> --> $DIR/unused-doc-comments-edge-cases.rs:59:5 </ins> | LL |       /// unused doc comment |       ^^^^^^^^^^^^^^^^^^^^^^

Discussion:
The same warning is produced at other places like statements, expressions, functions etc. For completeness and consistency it should be produced for pattern and expression fields too. No response rustc 1.74.0-nightly ( 2023-09-01) binary: rustc commit-hash: commit-date: 2023-09-01 host: x8664-pc-windows-msvc release: 1.74.0-nightly LLVM version: 17.0.0 rustc version older than 1.74.0 may ICE on this code. The ICE was fixed in 1.74.0 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reason these warnings are not produced is because the lint infrastructure currently exposes no hooks for and , i.e. there are no and methods on (or for that matter). To fix the issue, these methods may have to be here: and then invoked from here: and here: Alternatively, we can emit the warning from the already existing and methods of and not bother with the above changes at all.
Yeah, I would expect this is the best way of doing it.
claim
label -needs-triage
Change:
} _ => {} }; <del> match a.format { FormatSpec { width: Count::CountIsName(s, _), .. } | FormatSpec { precision: Count::CountIsName(s, _), .. } => { used_argument_names.insert(s); } _ => {} }; </del> <ins> if let Count::CountIsName(s, _) = a.format.width { used_argument_names.insert(s); } if let Count::CountIsName(s, _) = a.format.precision { used_argument_names.insert(s); } </ins> } } for (symbol, (index, span)) in names { if !used_argument_names.contains(symbol.as_str()) { let msg = format!("named argument `{}` is not used by name", symbol.as_str()); <del> let arg_span = cx.arg_spans[index]; </del> <ins> let arg_span = cx.arg_spans.get(index).copied(); </ins> cx.ecx.buffered_early_lint.push(BufferedEarlyLint { span: MultiSpan::from_span(span), msg: msg.clone(),

Discussion:
Running clippy or build on the Vaultwarden code-base using breaks. It is broken since and still works on Tried to run before running this without luck. If you need any more information, please let me know. Vaultwarden: Working: Broken since: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Looks like this is a duplicate of , , , , , and Sorry for the clutter ;)

<!-- 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. --Upon running , the compiler panics when having as a dependency. and complete without error. Probably this is related to ? <!-- 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. --: and : : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p: </p</details
Appears to be a duplicate of
Change:
<ins> //@ compile-flags: --crate-name foo pub fn foo() {} </ins>

Discussion:
Running on my checkout with the current master commit fails with tons of errors. here's the last few screens of messages:
Is the check looking for in the full path? My rustc checkout is in a directory called (it's my 2nd of 3 checkouts), and I suspect tidy gets confused by that.
It does CC
That code should probably use .
Oops, I will try to fix this ASAP
Submitted a fix for this at .
Change:
let i = ExpnIndex::from_u32(i); if let Some(hash) = self.root.expn_hashes.get(self, i) { map.insert(hash.decode(self), i); <del> } else { panic!("Missing expn_hash entry for {:?}", i); </del> } } map

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. --Assuming that you copied to . <!-- 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
I reproduced this ICE locally. On my end I did it by copying the git checkout of into , because I wasn't able to figure out the right invocation to get it setup with files in (Oh, whoops, I think I was accidentally passing instead of . Of course that wasn't going to work.) well, not 100%, my query stack was a little different: but it seemed like a similar bug, nonetheless.
modify labels: +I-prioritize
Assigning as discussed as part of the and removing .
Now happens for when retrying the repro. (with replaced with as it was changed in rustc) <details<summarybacktrace</summary</detailsIt also gives an unstable fingerprint ICE for when compiling : <details<summarybacktrace</summary</details
The compilation now fails when accessing session in : It looks that decodes which in turn decodes which in turn requires access to a session, but by the time of call, the session in no longer threaded through. cc
I can confirm it works now. Pushed to re-enable incremental compilation for compiling the sysroot.
Change:
Unspecified, /// This error will be surfaced elsewhere by rustc, so don't surface it. UnknownLayout, <ins> /// Overflow size SizeOverflow, </ins> TypeError(ErrorGuaranteed), }

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
Crashes since 1.65.0.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
visitor.assignments[local] = Set1::One(LocationExtended::Arg); } <del> if body.basic_blocks.len() > 2 { for (bb, data) in traversal::reverse_postorder(body) { visitor.visit_basic_block_data(bb, data); } } else { for (bb, data) in body.basic_blocks.iter_enumerated() { visitor.visit_basic_block_data(bb, data); } </del> <ins> // For SSA assignments, a RPO visit will see the assignment before it sees any use. // We only visit reachable nodes: computing `dominates` on an unreachable node ICEs. for (bb, data) in traversal::reverse_postorder(body) { visitor.visit_basic_block_data(bb, data); </ins> } for var_debug_info in &body.var_debug_info {

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
cc
reduced further:
reduced further:
Change:
.warn = {-passes_previously_accepted} .label = not a function or static <ins> passes_linkage = attribute should be applied to a function or static .label = not a function definition or static </ins> passes_macro_export = `#[macro_export]` only has an effect on macro definitions

Discussion:
I tried this code: I expected to see this happen: compilation failure because of attribute on an item where it makes no sense Instead, this happened: compiled successfully : cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
| = note: cannot satisfy `<T as Default>::Id == _` <del> error[E0282]: type annotations needed --> $DIR/specialization-transmute.rs:13:23 | LL |     default type Id = T; |                       ^ cannot infer type for associated type `<T as Default>::Id` error: aborting due to 2 previous errors; 1 warning emitted </del> <ins> error: aborting due to previous error; 1 warning emitted </ins> <del> Some errors have detailed explanations: E0282, E0284. For more information about an error, try `rustc --explain E0282`. </del> <ins> For more information about this error, try `rustc --explain E0284`. </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. --I tried this code: I expected to see this happen: compiles, or a helpful error message Instead, this happened: Confusing error message, there doesn't seem to be a future that could be awaited?... Interestingly if the default implementation is removed, it compiles. Playground: <!-- 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
The error message on the playground is a bit different, seems to be correlating with the actual problem more, but even more confusing: Expected and found are the same!
Minimal: Something funky going on with the default projection predicate installed for the GAT. I'll look into it
I'm impressed by the speedy handling of this issue! Was hoping this would get a fix in a few weeks . You're awesome!
Once the pr is merged, it will be available the next day on nightly, correct? Btw, the pr failed some tests.