jiebi/CodeConvo huggingface dataset:
Change:
impl Target { /// Given a function ABI, turn it into the correct ABI for this target. <del> pub fn adjust_abi(&self, abi: Abi) -> Abi { </del> <ins> pub fn adjust_abi(&self, abi: Abi, c_variadic: bool) -> Abi { </ins> match abi { Abi::C { .. } => self.default_adjusted_cabi.unwrap_or(abi), <del> Abi::System { unwind } if self.is_like_windows && self.arch == "x86" => { </del> <ins> // On Windows, `extern "system"` behaves like msvc's `__stdcall`. // `__stdcall` only applies on x86 and on non-variadic functions: // https://learn.microsoft.com/en-us/cpp/cpp/stdcall?view=msvc-170 Abi::System { unwind } if self.is_like_windows && self.arch == "x86" && !c_variadic => { </ins> Abi::Stdcall { unwind } } Abi::System { unwind } => Abi::C { unwind },

Discussion:
While testing variadic function support with I discovered that Rust requires such functions to use either "C" or "cdecl" ABIs but requires the "system" ABI on non-x86 Windows. My undertstanding from discussing with is that this is not an issue with itself but with Rust's insistence that such functions aren't allowed to use the "system" ABI. It's just that is very strict about calling convention so that's where the issue surfaced. On x64 I should be able to compile this but Rust says no: This example works if I change the ABI to "cdecl" but that's not meant to be a valid ABI on x64 and so when I try to compile this with it fails: The practical result is that it is impossible to link this function with on non-x86.
cc which originally variadics support to some other calling conventions (though not it seems) behind the feature gate .
A workaround is to use "C" on non-x86 as I implemented here:
Thoughts on permitting variadic parameters with the calling convention for non-x86 Windows? If gets merged then we'll be pushing folks to use so that they get the correct calling convention for Windows APIs on all architectures, but that breaks compatibility with variadic parameters.
This work-around is . Would be great if there was a way that it could be avoided. :)
There's a comment saying this can't work: I don't understand anything about these ABIs so I can't say how accurate this is. Also I see nothing here special-casing x86, so why does the issue specifically mention non-x86?
Happy to update as soon as there's a way to avoid it.
Can we make equal to when applied to a variadic function? It's supposed to be whatever ABI is correct for the system api and is the correct ABI for a variadic win32 function. According to the acts as when applied to a variadic function.
Went ahead and opened for this.
Change:
/// A faster version of the validation pass that only checks those things which may break when /// instantiating any generic parameters. <ins> /// /// `caller_body` is used to detect cycles in MIR inlining and MIR validation before /// `optimized_mir` is available. </ins> pub fn validate_types<'tcx>( tcx: TyCtxt<'tcx>, mir_phase: MirPhase, param_env: ty::ParamEnv<'tcx>, body: &Body<'tcx>, <ins> caller_body: &Body<'tcx>, </ins> ) -> Vec<(Location, String)> { <del> let mut type_checker = TypeChecker { body, tcx, param_env, mir_phase, failures: Vec::new() }; </del> <ins> let mut type_checker = TypeChecker { body, caller_body, tcx, param_env, mir_phase, failures: Vec::new() }; </ins> type_checker.visit_body(body); type_checker.failures } struct TypeChecker<'a, 'tcx> { body: &'a Body<'tcx>, <ins> caller_body: &'a Body<'tcx>, </ins> tcx: TyCtxt<'tcx>, param_env: ParamEnv<'tcx>, mir_phase: MirPhase,

Discussion:
on commit If you don't set a you will OOM while optimizing syn with these very silly flags. I also have another example of this that produces a "but found ConstICE. They look similar, I'll post the other one later if someone wants.
I've been able to minimize to this:
Here is a further minimized -only repro: The came out of the innards of . The use of is not critical, but the use of a type with both a lifetime and a type generic is; for example, will do too. Tested with the above RUSTFLAGS, under . T/ <details<summaryBacktrace</summary</details
Change:
compile_fail: bool, mut error_codes: Vec<String>, opts: &TestOptions, maybe_sysroot: Option<PathBuf>, linker: Option<PathBuf>, edition: Edition, persist_doctests: Option<PathBuf>) { <del> // The test harness wants its own `main` and top-level functions, so // never wrap the test in `fn main() { ... }`. let (test, line_offset) = make_test(test, Some(cratename), as_test_harness, opts); </del> <ins> let (test, line_offset) = match panic::catch_unwind(|| { make_test(test, Some(cratename), as_test_harness, opts) }) { Ok((test, line_offset)) => (test, line_offset), Err(cause) if cause.is::<errors::FatalErrorMarker>() => { // If the parser used by `make_test` panicked due to a fatal error, pass the test code // through unchanged. The error will be reported during compilation. (test.to_owned(), 0) }, Err(cause) => panic::resume_unwind(cause), }; </ins> // FIXME(#44940): if doctests ever support path remapping, then this filename // needs to be the result of `SourceMap::span_to_unmapped_path`. let path = match filename {

Discussion:
Doc test with missing closing back quotes fail without any explanation. rust /// let x = 7; /// asserteq!(x, a()); /// // <- HERE /// fn a() -i32 { 7 } rustc 1.35.0-nightly ( 2019-03-22) binary: rustc commit-hash: commit-date: 2019-03-22 host: x8664-unknown-linux-gnu release: 1.35.0-nightly LLVM version: 8.0 rustc 1.33.0 ( 2019-02-28) binary: rustc commit-hash: commit-date: 2019-02-28 host: x86_64-unknown-linux-gnu release: 1.33.0 LLVM version: 8.0
~I believe this is related to . The second <coderust</codeline is unable to be lexed, so the lexer bails with an unbuffered fatal error.~ I was wrong. I have a fix incoming.
Oh hey, this looks to be related to and , cc
Change:
<ins> // Regression test for issue 123053, where associated types with lifetimes caused generation of the // trait object type to fail, causing an ICE. // //@ needs-sanitizer-cfi //@ compile-flags: -Ccodegen-units=1 -Clto -Ctarget-feature=-crt-static -Zsanitizer=cfi --edition=2021 //@ no-prefer-dynamic //@ only-x86_64-unknown-linux-gnu //@ build-pass trait Iterable { type Item<'a> where Self: 'a; type Iter<'a>: Iterator<Item = Self::Item<'a>> where Self: 'a; fn iter<'a>(&'a self) -> Self::Iter<'a>; } impl<T> Iterable for [T] { type Item<'a> = <std::slice::Iter<'a, T> as Iterator>::Item where T: 'a; type Iter<'a> = std::slice::Iter<'a, T> where T: 'a; fn iter<'a>(&'a self) -> Self::Iter<'a> { self.iter() } } fn get_first<'a, I: Iterable + ?Sized>(it: &'a I) -> Option<I::Item<'a>> { it.iter().next() } fn main() { let v = vec![1, 2, 3]; assert_eq!(Some(&1), get_first(&*v)); } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zsanitizer=cfi -Ccodegen-units=1 -Clto -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: typeidforinstance: couldn't get fnabi of instance Layout(ReferencesError(ErrorGuaranteed(())))', 'error: internal compiler error: typeidforinstance: couldn't get fnabi of instance Layout(ReferencesError(ErrorGuaranteed(())))' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Change:
generate_link_to_definition, call_locations, no_emit_shared: false, <ins> html_no_source, </ins> }; Ok((options, render_options)) }

Discussion:
Kind of related to and the  attribute. The behaviour would be the same as the latter but wouldn't require any source code changes. My use-case here is to generate docs on the CI and reduce the size (400MB just for docs for each version is a bit much), but if people want to generate docs locally they should still be able to get the source code pages if they want. suggested to create an issue for this.
To reduce the global documentation size, I suggested in to group items that don't have impls by kinds. Would require an RFC though. In any case, I think it's a good idea to add an option to have this done in the command line.
Change:
// DotDotDot is no longer supported, but we need some way to display the error token::DotDotDot => Some(DotDotEq), token::Colon => Some(Colon), <ins> // `<-` should probably be `< -` token::LArrow => Some(Less), </ins> _ if t.is_keyword(kw::As) => Some(As), _ => None }

Discussion:
produces: It would be nice if it produced a suggestion to split it up: (This , but was broken in a previous change.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi I'd like to try this one. Just found the removed suggestion.
claim
assign Hmm, triagebot is not well...
It doesn't look like you're still working on this. Is it ok if I take over?
Sure. Thanks for your help.
Change:
<del> #![feature(postfix_match)] fn main() { let val = Some(42); val.match { Some(_) => 2, _ => 1 }; Some(2).match { Some(_) => true, None => false }.match { false => "ferris is cute", true => "I turn cats in to petted cats", }.match { _ => (), } } </del>

Discussion:
As of current nightly, produces this: which is not valid Rust syntax. The correct output would contain . tracking issue:
Change:
num == 3 } <ins> fn doc_comment_on_expr_field() -> bool { struct S { foo: i32 } let x = S { /// useless doc comment //~^ ERROR: unused doc comment foo: 3 }; true } fn doc_comment_on_pat_field() -> bool { struct S { foo: i32 } let S { /// useless doc comment //~^ ERROR: unused doc comment foo } = S { foo: 3 }; true } </ins> fn doc_comment_on_generic<#[doc = "x"] T>(val: T) {} //~^ ERROR: 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:
<ins> error[E0433]: failed to resolve: could not find `hahmap` in `std` --> $DIR/missing-in-namespace.rs:2:29 | LL |     let _map = std::hahmap::HashMap::new(); |                             ^^^^^^^ not found in `std::hahmap` | help: consider importing this struct | LL | use std::collections::HashMap; | error: aborting due to previous error For more information about this error, try `rustc --explain E0433`. </ins>

Discussion:
Test program: This produces the following error messages: Both the error and the help seem entirely unhelpful. The error suggests that it looked for a function in the crate root, but in fact it looked for a crate . The whole "possible candidate" help seems incorrect, and adding that line would lead to a compilation failure.
cc
This is still an issue, but at least the incorrect help message is no longer displayed:
Change:
|        ^^^^^^^^^^^^^^ pattern `(_, _)` not covered | = note: the matched value is of type `(isize, bool)` <ins> = note: `isize` does not have a fixed maximum value, so a wildcard `_` is necessary to match exhaustively = help: add `#![feature(precise_pointer_size_matching)]` to the crate attributes to enable precise `isize` matching </ins> help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown | LL |         match $s { $($t)+ => {}, (_, _) => todo!() }

Discussion:
Sorry about the long title :sweat_smile: Given the following code (): The current output is: Note how the first diagnostic, emitted when matching on a , contains additional information about why this exhaustive match does not pass the exhaustiveness check. Ideally, this information should be to the second diagnostic as well: modify labels: +A-exhaustiveness-checking +A-patterns +D-terse
Hm, even though has a different size on different architectures, should always be exhaustive, right? Then that code would be accepted, but the following would still error: We could have the error for this say "missing pattern: ", which would also work if there's a around it. That said, pretty sure what you describe also happens for enums too, and there we'll want to do what you suggest.
see also
I forgot this issue existed, but yeah this is a lint we want. I explained a bit about how this might be done in , if anyone wants to tackle this feel free to ping me
Change:
use core::fmt::Debug; use core::hash::{Hash, Hasher}; use core::iter::{Map, FromIterator, IntoIterator}; <del> use core::ops::{Index, IndexMut}; </del> <ins> use core::ops::{Index}; </ins> use core::{iter, fmt, mem, usize}; use Bound::{self, Included, Excluded, Unbounded};

Discussion:
I believe we intend to eventually extend the index traits with the ability to override the syntax specifically using a trait like . This would allow hashmaps to be used like and have that insert the key, unlike today where will panic if is not already present. To pave the way, the simplest thing is to remove the operator from those collections where we would anticipate growing on demand. I believe that would be , , and possible and . Thoughts? cc
triage: P-backcompat-libs I-needs-decision (1.0 beta)
triage: P-backcompat-libs (1.0 beta)
I was just starting to prep a PR to resolve this by removing the impl, as you suggested. :)
Don't we want to keep the implementation on for example to do something like ?
Depending on the exact way that is done, it may not be possible to provide both modes of use. That is, we want to be able to write -- which we cannot today -- but it's not clear that you can do that and also support examples like the one you gave. In particular, that involves adjusting inference to determine whether or not a deref is in play. For now, removing these impls will give us the most freedom when we do incorporate .
It seems weird to have this and insert -- insert has a return value, though. This would be a super-annoying ergonomic regression in the interim. What's the expected timeline for something like IndexSet? 1.1?
Oh actually upon reflection most usages I know are Index, not IndexMut. Not as awful a regression.
It should be possible to move in, out, and take references with the operator. If that's not possible with the current design then the current design has to be changed instead of committing to yet another subpar design until 2.0.
sounds powerful and interesting, is there any RFC for it now?
It feels odd that does not support . I don't buy the argument that would be confused with - no other container supports insertion via the syntax. Now if you would add some hypothetical and support insertion into a via , then someone would just get confused that they can't use to insert into a .. (doesn't really makes sense, but what if entries are default constructible!) Not even talking about the pandora box of accidentally inserting elements into the container. Imho we should keep consistent as an accessor to get references to data already existing in the container.
Change:
<ins> error[E0131]: `main` function return type is not allowed to have generic parameters --> $DIR/return-ty-has-bound-vars.rs:3:28 | LL | fn main<'a>(_: &'a i32) -> &'a () { &() } |                            ^^^^^^ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0131`. </ins>

Discussion:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'Normalizing Alias(Weak, AliasTy { args: [ReBound(DebruijnIndex(0), BoundRegion { var: 0, kind: BrNamed(DefId(0:13 ~ 24C571BC08516AAF219327E12F0FEDBF5591EB2DFE1FD843CF7E2D7C1441FB55[8fdb]::main::'a), 'a) }), ReError], defid: DefId(0:9 ~ 24C571BC08516AAF219327E12F0FEDBF5591EB2DFE1FD843CF7E2D7C1441FB55[8fdb]::Foo) }) without wrapping in a '', 'thread 'rustc' panicked at 'Normalizing Alias(Weak, AliasTy { args: [ReBound(DebruijnIndex(0), BoundRegion { var: 0, kind: BrNamed(DefId(0:13 ~ 24C571BC08516AAF219327E12F0FEDBF5591EB2DFE1FD843CF7E2D7C1441FB55[8fdb]::main::'a), 'a) }), ReError], defid: DefId(0:9 ~ 24C571BC08516AAF219327E12F0FEDBF5591EB2DFE1FD843CF7E2D7C1441FB55[8fdb]::Foo) }) without wrapping in a '' 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: [checkmoditem_types] checking item types in top-level module [analysis] running analysis passes on this crate --
Regression in ping
Change:
<ins> error[E0478]: lifetime bound not satisfied --> $DIR/issue-91883.rs:32:24 | LL | /     type Cursor<'tx>: Cursor<'tx> LL | |     where LL | |         'db: 'tx, LL | |         Self: 'tx; | |__________________- definition of `Cursor` from trait ... LL |       type Cursor<'tx> = CursorImpl<'tx>; |                          ^^^^^^^^^^^^^^^- help: try copying these clauses from the trait: `where 'db: 'tx, Self: 'tx` | note: lifetime parameter instantiated with the lifetime `'db` as defined here --> $DIR/issue-91883.rs:31:6 | LL | impl<'db> Transaction<'db> for TransactionImpl<'db> { |      ^^^ note: but lifetime parameter must outlive the lifetime `'tx` as defined here --> $DIR/issue-91883.rs:32:17 | LL |     type Cursor<'tx> = CursorImpl<'tx>; |                 ^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0478`. </ins>

Discussion:
Given the following code: The current output is: Error is fixed by adding a where clause to associated type in impl, which is not immediately clear:
GATs issue triage: not blocking. Poor diagnostic, but not a miscompile.
label +D-papercut +D-terse
Current output is I think that's pretty helpful. Going to mark as needs-test
Change:
<ins> // Regression test for <https://github.com/rust-lang/rust/issues/113840> // // This test makes sure that multiple marker (method-less) traits can reuse the // same pointer for upcasting. // // build-fail #![crate_type = "lib"] #![feature(rustc_attrs)] // Markers trait M0 {} trait M1 {} trait M2 {} // Just a trait with a method trait T { fn method(&self) {} } #[rustc_dump_vtable] trait A: M0 + M1 + M2 + T {} //~ error: vtable entries for `<S as A>`: #[rustc_dump_vtable] trait B: M0 + M1 + T + M2 {} //~ error: vtable entries for `<S as B>`: #[rustc_dump_vtable] trait C: M0 + T + M1 + M2 {} //~ error: vtable entries for `<S as C>`: #[rustc_dump_vtable] trait D: T + M0 + M1 + M2 {} //~ error: vtable entries for `<S as D>`: struct S; impl M0 for S {} impl M1 for S {} impl M2 for S {} impl T for S {} impl A for S {} impl B for S {} impl C for S {} impl D for S {} pub fn require_vtables() { fn require_vtables(_: &dyn A, _: &dyn B, _: &dyn C, _: &dyn D) {} require_vtables(&S, &S, &S, &S) } </ins>

Discussion:
While working on I think I found a bug. Given this program: rustc outputs the following vtable layout: Which is surprising, because is unnecessary — does not have any methods, so vtable can be inlined... I think we should be smarter here: (for the record, I'm pretty sure this happens in practice, I've found this with ) Originally posted by in
cc
sorry been slow a little recently... This is a nice improvement.
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> // revisions: ast mir //[mir]compile-flags: -Z emit-end-regions -Z borrowck-mir </ins> enum Sexpression { Num(()), Cons(&'static mut Sexpression)

Discussion:
MIR borrowck ICEs when an error involving a region whose EndRegion is missing occurs (this occurs when a region can never end within the function). Instead it should emit a correct diagnostic. This can occur for both free regions (e.g. issue-): And for infinite loops: Causing this ICE:
The ICE here is caused by the assert in this function, : This function finds the (location in the input source code) that a region ends. If you look at the error that the AST borrowck (i.e., older style borrowck) emits, we are basically computing the point where to write that "immutable borrow ends here" message: Right now, there is a kind of complicated assertion. It is saying that one of two things should be: We are in non-lexical mode. In that case, there are no end-regions at all, so we just return . This causes us not to write "immutable borrow ends here". We are in lexical mode, in which case we should have found an statement. These are special statements we insert into the MIR (only in lexical mode) that tell us where the various lexical lifetimes end. The problem is that in cases where the region never properly ends, we won't find an statement. I think what we want to do is rewrite the function a bit. If we are in NLL mode (), then we should always return . Otherwise, check the as we are doing and return if we find something in there, as we are doing now. Otherwise, we want to return the span for the end of the function. This is the new part. As it happens, we can get this by returning : is the MIR for the function we are checking is the span in the source code where the function is defined returning its end point should, I think, give us the behavior we want. So, when we are done, if is , this function should always return for some span, but sometimes it will be the end of the function.
Hi, I want to work on this bug.
Change:
let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, RunStrategy::InProcess, tx, Concurrent::No); let result = rx.recv().unwrap().result; <del> assert!(result == TrFailedMsg("test did not panic as expected".to_string())); </del> <ins> assert_eq!(result, TrFailedMsg("test did not panic as expected".to_string())); </ins> } fn report_time_test_template(report_time: bool) -> Option<TestExecTime> {

Discussion:
When running this test (): the output is which makes it hard to spot the difference in whitespace characters. Would it be possible to change this to e.g.: This would improve the usability when running into these kinds of test failures and also make it more consistent with which outputs both the left and the right value too.
Agree with having them vertically aligned. I think we do want line endings to create a new line though for multi-line readability. Maybe we should say something like this: (The first difference at char line we might also want to add to assert_eq also?)
The message sounds good, but I am not sure how well it applies to the comparison, as it is not an equality, but a substring comparison. Maybe we could adjust the wording of the error message to e.g.: to make that easier to spot. I think the escaping is essential, take for instance which has no newlines, but contains : On many shells, this will produce this output: which makes it very hard for a user to figure out what's going on (let's assume the happens in a more obscure location). Maybe a more important reason is that escaping would be consistent with the behavior of , which for : outputs: The escaping avoids surprises which could occur depending on the user`s environment.
Ok I'm sold. Do you want to fork rust-lang/rust and submit this as a PR? (If you don't want to I can do the legwork).
Thanks for the offer, I'll try to write a PR and will add you as a reviewer once I have a first version ready.