jiebi/CodeConvo huggingface dataset:
Change:
fn baz(f: extern "stdcall" fn(usize, ...)) { //~^ ERROR: C-variadic function must have a compatible calling convention, <del> // like C, cdecl, aapcs, win64, sysv64 or efiapi </del> <ins> // like C, cdecl, system, aapcs, win64, sysv64 or efiapi </ins> f(22, 44); } <ins> fn system(f: extern "system" fn(usize, ...)) { f(22, 44); } </ins> fn aapcs(f: extern "aapcs" fn(usize, ...)) { f(22, 44); }

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:
impl<T: Clone, A: Allocator> ExtendFromWithinSpec for Vec<T, A> { default unsafe fn spec_extend_from_within(&mut self, src: Range<usize>) { <del> let initialized = { let (this, spare) = self.split_at_spare_mut(); // SAFETY: // - caller guaratees that src is a valid index let to_clone = unsafe { this.get_unchecked(src) }; to_clone.iter().cloned().zip(spare.iter_mut()).map(|(e, s)| s.write(e)).count() }; </del> <ins> // SAFETY: // - len is increased only after initializing elements let (this, spare, len) = unsafe { self.split_at_spare_mut_with_len() }; </ins> // SAFETY: <del> // - elements were just initialized unsafe { let new_len = self.len() + initialized; self.set_len(new_len); } </del> <ins> // - caller guaratees that src is a valid index let to_clone = unsafe { this.get_unchecked(src) }; to_clone .iter() .cloned() .zip(spare.iter_mut()) .map(|(src, dst)| dst.write(src)) // Note: // - Element was just initialized with `MaybeUninit::write`, so it's ok to increace len // - len is increased after each element to prevent leaks (see issue #82533) .for_each(|_| *len += 1); </ins> } }

Discussion:
Looking here, the internal length of the vector is only adjusted at the end of the loop This has the caveat that if cloning panics, the Vec will start to unwind and only drop the first elements which doesn't include the most recently appended ones. Something more in line with how the stdlib does things might look like this: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is not unsafe, leaking items is safe:
Sure; never said it was unsafe. This is more about making sure programs who gracefully handle panics don't wind up eventually exhausting resources.
Assigning as part of the .
I would like to fix this claim
The fix seems pretty straight-forward. The Clone specialization just needs a RAII type that handles adjusting the Vec's new len in its Drop implementation, as I've linked in my MiniVec. Copy can't fail so there's no need to adjust that specialization. The only thing that could theoretically panic in that case would be reallocating and in that case, there's no need to worry about the len.
Change:
// gdbg-command:print 'basic_types_globals::C' // gdbr-command:print C // gdbg-check:$3 = 97 <del> // gdbr-check:$3 = 97 'a' </del> <ins> // gdbr-check:$3 = 97 </ins> // gdbg-command:print/d 'basic_types_globals::I8' // gdbr-command:print I8 // gdb-check:$4 = 68

Discussion:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?
Change:
<ins> error: format argument must be a string literal --> $DIR/issue-30143.rs:14:14 | LL |     println!(0); |              ^ help: you might be missing a string literal to format with | LL |     println!("{}", 0); |              ^^^^^ error: format argument must be a string literal --> $DIR/issue-30143.rs:16:15 | LL |     eprintln!('a'); |               ^^^ help: you might be missing a string literal to format with | LL |     eprintln!("{}", 'a'); |               ^^^^^ error: format argument must be a string literal --> $DIR/issue-30143.rs:19:17 | LL |     writeln!(s, true).unwrap(); |                 ^^^^ help: you might be missing a string literal to format with | LL |     writeln!(s, "{}", true).unwrap(); |                 ^^^^^ error: aborting due to 3 previous errors </ins>

Discussion:
The following all compile and run for example: I would expect them to produce "error: format argument must be a string literal." like does. This is because they use things like but accepts other literals not just . I assume this isn't intentional.
One way to fix this is to replace 's definition with I would prefer to force and friends to take strings but at least this keeps it consistent. EDIT: I honestly don't like how automatically stringifies, it seems kinda ugly and I feel like there should be a separate macro that does compile-time stringification. This would almost certainly be super backwards-incompatible though.
awesome! Why do the places that need 's stringifying functionality not use so doesn't duplicate functionality? That would solve this issue. EDIT: Turns out is different to , the latter only accepts literals whereas the former will verbatim stringify token trees, such as .
Seems like it'd be a breaking change to "fix" this.
For it is explicit and by design, so that part is no problem.
good point, actually has it's own unintuitive behaviour similar but different to .
Why do we consider that the code like works to be a bug? I understand that forbidding it will make more consistent and explicit but we're trading in some convenience here. The other option could be to make behave in same way.
it's not documented so technically something needs to fixed, even if it's just the documentation. If we make behave the same then surely we'd have to change and as well to keep things consistent and I don't think that's a good idea as this isn't even useful. I think this should either be fixed as a breaking change, I doubt it will break much if any real world code, or just depreciated.
thanks for the clarifications, thats makes sense now. I'm not sure and should behave exactly as and as the two groups of macros serve different purposes. Maybe one more special case doesn't worth it however.
Libs team consensus: while it may be desirable to clean this up, this is not breakage we're willing to take on during the Rust 1.x series. I've a new tag, closed-as-desirable-breakage, to help us track issues like this that we might want to revisit if we ever produce a 2.0 release.
related issue: accepts non-bools
Sadly, has been implemented with this bug, so is also affected: .
This would be improved by
Change:
let (span, separator) = if let [.., last] = bounds { (last.span().shrink_to_hi(), " +") } else { <del> (ident.span.shrink_to_hi(), ":") </del> <ins> (generics.span.shrink_to_hi(), ":") </ins> }; err.span_suggestion_verbose( span,

Discussion:
No response No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Another variant of this error I came up with using stable Edit Just tested on stable and . Both produced the same output.
claim
This is only tangentially related but just to give more context to anyone stumbling upon this issue: The diagnostic highlighting the entire path instead of only the type argument is tracked in .
Change:
use hair::cx::to_ref::ToRef; use rustc::front::map; use rustc::middle::def::Def; <ins> use rustc::middle::const_eval; </ins> use rustc::middle::region::CodeExtent; use rustc::middle::pat_util; use rustc::middle::ty::{self, VariantDef, Ty};

Discussion:
See and relevant FIXME in
As a side-note, would solve this problem quite neatly, if we were to adopt and implement it. :)
Change:
// FIXME: translation requires list formatting (for `expect`) let mut err = self.struct_span_err(self.token.span, msg_exp); <ins> // Look for usages of '=>' where '>=' was probably intended if self.token == token::FatArrow && expected .iter() .any(|tok| matches!(tok, TokenType::Operator | TokenType::Token(TokenKind::Le))) && !expected.iter().any(|tok| { matches!( tok, TokenType::Token(TokenKind::FatArrow) | TokenType::Token(TokenKind::Comma) ) }) { err.span_suggestion( self.token.span, "you might have meant to write a "greater than or equal to" comparison", ">=", Applicability::MaybeIncorrect, ); } </ins> if let TokenKind::Ident(symbol, _) = &self.prev_token.kind { if ["def", "fun", "func", "function"].contains(&symbol.as_str()) { err.span_suggestion_short(

Discussion:
When encountering code like , we currently emit But it should be closer to <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hi! I'd like to try working on this issue if nobody else is currently. claim
Change:
<ins> // edition:2018 // [nll] check-pass // revisions: migrate nll // Explicitly testing nll with revision, so ignore compare-mode=nll // ignore-compare-mode-nll #![cfg_attr(nll, feature(nll))] #![feature(generic_associated_types)] use std::future::Future; trait Client { type Connecting<'a>: Future + Send where Self: 'a; fn connect(&'_ self) -> Self::Connecting<'_>; } fn call_connect<C>(c: &'_ C) -> impl '_ + Future + Send //[migrate]~^ ERROR the parameter //[migrate]~| ERROR the parameter where C: Client + Send + Sync, { async move { c.connect().await } } 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. --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:
- name: x86_64-gnu-distcheck <<: *job-linux-xl <del> - name: x86_64-gnu-full-bootstrap <<: *job-linux-xl </del> - name: x86_64-gnu-llvm-8 env: RUST_BACKTRACE: 1

Discussion:
It's clocking in at 20 minutes and seems to be doing nothing -- I suspect that this might be a result of changes to x.py defaults but have not confirmed. We should fix this.
(link to the PR: )
We discussed this during the and agreed to remove the builder. The builder doesn't provide much value for the stability of the project, as it rarely fails and we'd catch any failure it would prevent as soon as we promote nightly to beta.
To fix this issue, the builders needs to be removed from and .
Change:
] [[package]] <ins> name = "threadpool" version = "1.8.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "d050e60b33d41c19108b32cea32164033a9013fe3b46cbd4457559bfbf77afaa" dependencies = [ "num_cpus", ] [[package]] </ins> name = "tidy" version = "0.1.0" dependencies = [

Discussion:
As discovered by in rust-lang/cargo, a Cargo test is intermittently failing on Windows because a source file generated by Rustdoc is not being written before the process exits. The suspected issue is that Rustdoc spawns asynchronous writes here: However, Rustdoc never checks that the writes are completed. We should add a mechanism that prevents the process from exiting before these write tasks are completed. One possible solution: Add a field to . Increment at the start of , and decrement at the end of the spawned Rayon task. Add a method that spin-loops until is zero. (Alternatively: use a condition variable, and have notify the condvar when is decremented.) Either call explicitly in the end of the Rustdoc process, or add it as a implementation to . cc
Change:
x = "x"; //~ ERROR cannot find value `x` in this scope println!("x: {}", x); //~ ERROR cannot find value `x` in this scope <ins> let_some_variable = 6; //~ cannot find value `let_some_variable` in this scope println!("some_variable: {}", some_variable); //~ ERROR cannot find value `some_variable` in this scope letother_variable = 6; //~ cannot find value `letother_variable` in this scope println!("other_variable: {}", other_variable); //~ ERROR cannot find value `other_variable` in this scope </ins> if x == "x" { //~^ ERROR cannot find value `x` in this scope println!("x is 1");

Discussion:
I accidentally typoed an underscore instead of a space between and the name of the new variable I was trying to declare. If a binding isn't found, and it starts with (or frankly , if you forget/miss the space completely), it seems like it would be more likely to suggest ( plus a space) rather than the current suggestion of an additional . No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
interesting, I'd like to have a try. but might not solve it quicklly casuze I am new to rustc
sounds good! feel free to ask for help if you need it, but the implementation should be fairly simple. assign
Change:
<del> Subproject commit 1bbe0b3e1d756116cbf1fcf049555066ef929008 </del> <ins> Subproject commit 8538d56b2dd450063547a7690f7ffa2ac37c9c65 </ins>

Discussion:
(which is equivalent to GCC's mcmodel=medany). I believe that this means that it is now possible to cherry pick the relevant commits and expose support from Rust. See also: rust-embedded/wg/issues/218
great ! would be useful for me as well: Kendryte K210 expects code to run from fixed address , so medlow relocations get truncated
Greetings from Oxidize! It'd be great if someone could bump LLVM, so we can start adding support for Linux/RV64 targets. It was suggested might be the person to ping about this. Is there a specific LLVM version you would recommend? I assume we want at least , but I imagine there may be other upstream fixes that are needed. Thanks! CCing
Rust can already target bare metal Rv64 (with the riscv64imac-unknown-none-elf target). What is missing is the ability to place the code/symbols at locations outside the range [-2GB, 2GB]. That isn't too much of an issue for writing supervisor mode code which can just configure the MMU to map those addresses to point to RAM, but machine mode can't pick the memory layout of the board it runs on. You actually can get away with having code outside this range as long as there aren't any indirect jumps or static variables there. It is very restrictive and inconvenient, but you might be able to get away with it for a small amount of code.
I also really want these patches to be merged. I've already tried to merge upstream branch as well as to deduce a cherry-pick-able set of commits but failed in both cases. Because of that, I can't tell whether these patches will fix the issue or not. At the moment I'm stuck waiting for help. I'm ready to give it another try, but I need some guidance. Maybe or could help me?
There's instructions/rationale about updating LLVM hosted at https://rust- Instructions are slightly out of date but I'll send a PR to fix them.
(Current status) This patch arrived in LLVM: Now LLVM is able to generate pc-relative address load instructions for global variables and functions.
Change:
} " rust-test-region-string rust-test-motion-string <ins> rust-test-indent-motion-string " fn blank_line(arg:int) -> bool { } fn indenting_closing_brace() { if(true) { } } fn indenting_middle_of_line() { if(true) { push_me_out(); } else { pull_me_back_in(); } } " </ins> ;; Symbol -> (line column) rust-test-positions-alist '((start-of-fn1 (2 0)) (start-of-fn1-middle-of-line (2 15))

Discussion:
There are several common cases where the emacs mode gets the indentation incorrect. I'll list the examples as I believe they should be formatted. indent after open paren with no argument: with arguments: field names:
Oh, and the motivating example for filing the bug: comments don't work quite right. and also you should be able to hit M-q and have it reflow correctly.
I've found trailing line comments breaks the indentation of the next line: (Not sure if this is worth a separate bug.)
Another example is a pattern relative to an indented match: Also, I believe patterns in general are indented incorrectly, though admittedly I'm not sure what the standard is. My preference is to keep all patterns at the same level of indentation, as shown here:
If we're going to fix , we should try to also take the time to fix the other doc comment variations, namely , if possible.
part of
Change:
[[package]] name = "compiletest_rs" <del> version = "0.3.23" </del> <ins> version = "0.3.24" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "eb783fe7afb90ec3d3e49ccaf9196d29ab63c6ed61d4b0695839daa580ae3a3d" </del> <ins> checksum = "676a74b493d50ac33cacd83fd536597e6b52c0b46b9856f7b9c809d82fef4ac0" </ins> dependencies = [ "diff", "filetime",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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.
Yeah, I will try to figure out how to fix .
Sorry, saw this issue after the fact - If Miri is failing because of the renamed testopt, I have a PR for compiletest-rs open with a potential fix:
Sure, no problem.
We had avoided the "nightly" feature of compiletest-rs in Miri exactly because of this... But recently enabled it again due to other failures. Should we rather try to use the stable variant again?
Both variants are currently not working: should fix the nightly variant fixes the stable variant
Change:
<ins> // check-pass #![feature(associated_type_bounds)] #![feature(type_alias_impl_trait)] fn main() {} trait Bar { type Assoc; } trait Thing { type Out; fn func() -> Self::Out; } struct AssocIsCopy; impl Bar for AssocIsCopy { type Assoc = u8; } impl Thing for AssocIsCopy { type Out = impl Bar<Assoc: Copy>; fn func() -> Self::Out { AssocIsCopy } } </ins>

Discussion:
Trait bounds on associated types seem to be required, not implied, when the trait in question mentions an associated type on a type parameter. Concretely, this code (or ) produces an error: despite the bound being required by the definition of itself, and in fact this means that the trait can never be mentioned. This similar example () that doesn't use an associated type in the trait parameter compiles: while this version (), which uses a third trait to avoid the self-reference, does not: Is this just a missing normalization step?
Pretty sure I encountered the same bug when specifying an associated type explicitly in a signature.
/cc you wanted to ensure this test case fell into the trait system rewrite.
I've just run into this as well, it seems. Here's a very simple example:

See the testcase here: I'd normally run this by a few people before filing an issue, but #rust is quiet on a Saturday night. ;-) thoughts?
Trait resolution basically doesn't know how to figure out that two types are equal in the case of "dual traits". This is one of the inevitable issues is going to hit in his Servo script bindings refactor I do wish we had a more formalized notion of type families that could be used to better instruct the compiler in these cases. was talking about this in , and I've personally found the need for a family-trait type situation more than once, both when modeling dualities and when modeling generic abstractions over sets of types like you're trying to do.
This appears to work today; E-needstest.
I don't think it works necessarily -- if you remove the bound that highlighted, you still get an error.
The example that expected to pass (and I think he is right that it should) is :
Current output: