jiebi/CodeConvo huggingface dataset:
Change:
} let size = arg.layout.size; <del> if size.bits() <= 64 { </del> <ins> if is_ret && size.bits() > 128 { // Non-homogeneous aggregates larger than two doublewords are returned indirectly. arg.make_indirect(); } else if size.bits() <= 64 { </ins> // Aggregates smaller than a doubleword should appear in // the least-significant bits of the parameter doubleword. arg.cast_to(Reg { kind: RegKind::Integer, size })

Discussion:
I tried this code: I expected to see this happen: test suite passing Instead, this happened: The return failure is: The pass failure is: : This occurs in every version since the test was . I see this with 1.79.0 and 1.80.0 as well as my 1.81.0 beta build (). I haven't dug in to all of the nitty-gritty yet, but I have a feeling may be potentially incorrect?
Indeed, if I remove those two lines, it passes the tests correctly: But I'm not sure why they are there and if this could possibly cause breakage elsewhere. I'd be happy to open a PR with this change for comment if that is the best way forward, or we can continue to discuss here.
Indeed, there is fallout - this test used to pass:
Reading over the ELF ABI specification and how LLVM and GCC implement this, arguments and return values should be treated the same. So, trying to duplicate the logic from in yielded me: and gave me: which is actually the first time I've ever seen Rust complete its test suite fully on a big endian PPC64/musl environment! Since the logic doesn't vary between endian in , I'm not sure why it should in . Unfortunately, I don't have any spare hardware to try and run little-endian, so I can't test if this change actually does the right thing on LE. I suppose since the original code had a BE case which was suspiciously similar to the first half of , I could do the code as another branch there. But that feels ugly, and I'd like to know if this simpler way would work on both endians before trying to shoehorn deeper nested branches.
Change:
self_ty.hir_id, self_ty.span, |lint| { <del> lint.build(msg) .multipart_suggestion_verbose( "use `dyn`", sugg, Applicability::MachineApplicable, ) .emit(); </del> <ins> let mut diag = lint.build(msg); diag.multipart_suggestion_verbose( "use `dyn`", sugg, Applicability::MachineApplicable, ); self.maybe_lint_blanket_trait_impl::<()>(&self_ty, &mut diag); diag.emit(); </ins> }, ); }

Discussion:
One of the big problems with the 2015-style trait object syntax (no ) was that users often write things like when what they really meant was . Back then, the error message would more often than not be some inscrutable message about , which would send them on a wild goose chase of adding bounds everywhere they could think of, leading to even more inscrutable messages. Now, the error message is clearer: it tells users they need to add for a trait object type. However, I find in many cases (most cases?) this is not what users actually want - what they actually want is the blanket impl. It would be helpful to have a note suggesting the correct syntax for a blanket impl, or better yet just presenting both correct syntaxes (impl for trait object and blanket impl) on equal footing and making it clear the difference between them. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I work to reproduce this issue and start to understand what type of check we need to do, and in particular the work that we need to do is the following one: If the traits are local traits we can perform the suggestion of the blanket impls, for example in the following code But we need to skip the following suggestion in case we are using not local traits, like the following code here
Change:
} }; <del> let repr = adt::represent_type(bcx.ccx(), ty); trans_adt(bcx, &*repr, discr, numbered_fields.as_slice(), optbase, dest) </del> <ins> trans_adt(bcx, ty, discr, numbered_fields.as_slice(), optbase, dest) </ins> }) }

Discussion:
The current translation for struct update in the case of ignore looks incorrect. It should only move those fields that are not specified manually. This can mean the difference between moving the base as a whole and not. Probably the easiest thing to do is to create an alloca, use the same code as the normal path, and just drop the alloca afterwards.
See FIXME.
visiting for triage. nominating for production ready.
Accepted for production-ready
visting for triage, still relevant. FYI, the module in question is
Change:
<ins> #![deny(broken_intra_doc_links)] // @has primitive_disambiguators/index.html // @has - '//a/@href' 'https://doc.rust-lang.org/nightly/std/primitive.str.html#method.trim' //! [str::trim()] </ins>

Discussion:
I tried this code: I expected to see this happen: Rustdoc links to Instead, this happened: Rustdoc gets confused that means a function and thinks that the link is a primitive. <!-- 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. --: Relevant code: I think the fix is just to add as a match guard. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is blocking and made unnecessarily difficult.
claim
which arm do you mean to add the match guard to?
the one for telling if the resolved item is a primitive:
It looks like is in fact for
Oh hmm - the issue is that for primitives, rustdoc generates the anchor manually: I would try storing the of the associated item in instead, so you know later whether the anchor is a manual link () or whether it was generated by rustdoc.
Adding in here and adding the match guard seems to fix things, but also feels like a hack.
I mean, all of is a hack because other parts of rustdoc break when you store the associated item instead: If you can figure out a way to get rid of it, I'd love to do that, but it will require some pretty major refactors I think.
Change:
<ins> // Copyright 2013-2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // aux-build:issue_3907.rs extern crate issue_3907; type Foo = issue_3907::Foo; //~ ERROR: reference to trait struct S { name: int } fn main() {} </ins>

Discussion:
This code is wrong because ToStr does not define . But what's odd is that the compiler error does not happen in the block but in the : Error message: The expected error message would point to the block that needs to be split into two (one with ToStr and one without a trait).
Reproduced as of
Repro'd with -- but not critical for 0.6, de-milestoning
Appears to be fixed, as per this updated test case: fails with . Closing.
We've regressed: there's a test case (), but it's been xfailed since it was . With I see:
Aaaand, we've un-regressed! Removing all tags except for neesdtest.
Whoops, had the wrong code example, regression still here.
Change:
/// assert_eq!(a.rem_euclid(-b), 3); /// assert_eq!((-a).rem_euclid(-b), 1); /// ``` <ins> /// /// This will panic: /// ```should_panic #[doc = concat!("let _ = ", stringify!($SelfT), "::MIN.rem_euclid(-1);")] /// ``` </ins> #[doc(alias = "modulo", alias = "mod")] #[stable(feature = "euclidean_division", since = "1.38.0")] #[rustc_const_stable(feature = "const_euclidean_int_methods", since = "1.52.0")]

Discussion:
The documentation of and for any signed integer type, e.g.: In the "Panics" section it says "This function will panic if is 0 or if is -1 and is .", but I believe this is the wrong way around: the panic happens on , not on , as (correctly) explained in and all other related functions. Also, is there any situation where someone would want over ? Mathematically, should really just be 0, that it panics is more of an implementation artifact (the corresponding division overflows). Maybe it would be a good idea to add something like "If this is a problem, use instead." to the documentation of ? Though in most applications will probably be positive anyway. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
the error is also present on and .
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-47486.rs:2:10 | LL |     () < std::mem::size_of::<_>(); |          ^^^^^^^^^^^^^^^^^^^^^^^^ expected (), found usize | = note: expected type `()` found type `usize` error[E0282]: type annotations needed --> $DIR/issue-47486.rs:3:11 | LL |     [0u8; std::mem::size_of::<_>()]; |           ^^^^^^^^^^^^^^^^^^^^^^ cannot infer type error: aborting due to 2 previous errors Some errors have detailed explanations: E0282, E0308. For more information about an error, try `rustc --explain E0282`. </ins>

Discussion:
Minimal example:
can you reproduce?
I can try, this is from Mar 2nd so not related to my recent changes right?
yes it fails for me with both stable rust 1.25 and the latest nightly rustc 1.27.0-nightly ( 2018-04-11). It's not failing in a part of typeck that I'm familiar with but I'll have a look sometime and see if it makes any sense to me.
Yes this is unrelated to that PR (I think there isn't a nightly including it yet). But since this is related to I thought you might want to take a look.
I started expanding the minimal example so that it didn't depend on nalgebra, it has expanded into quite a lot of code This example is enough to break the compiler but doesn't compile if the ICE is fixed (e.g. if the is commented out). For it to compile it still needs some external dependencies. It appears to be the associated type that is hitting the ICE.
Yeah 's example is huge. Maybe he doesn't know that minimal examples should have no dependencies. if you don't provide minimal examples in bug reports (that is: no dependencies; they should compile in the play ground) they'll take much longer than necessary to fix.
I understand. I'm a relative beginner to rust, so it would take quite a lot of time for me to figure out how to make a more minimal example. I am able to work around this issue in my own code, so it's not that important to me, but I figured it might be easy for someone more experienced to spot what was going wrong. If you don't think it's worth the effort to investigate further, I have no problem with you closing this until a more simple manifestation is discovered.
I've reduced it to the following ():
It's no longer reproduced an ICE on the latest nightly, it seems from 1.38.0. marked as E-needstest
Change:
use rustc_hir as hir; use rustc_hir::def::CtorKind; use rustc_hir::def_id::DefId; <ins> use rustc_middle::dep_graph::DepContext; </ins> use rustc_middle::middle::stability; use rustc_middle::ty::TyCtxt; use rustc_span::hygiene::MacroKind;

Discussion:
See is unstable, however there is no unstable tag showing that, it would be nice if it would, just so it can be seen at a glance without going to their respective pages. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that rustdoc already does something similar for : ! It could use a similar format for re-exports.
Really could just copy the existing tags (see -asm) and put em after the path.
claim
Change:
<ins> // Copyright 2017 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. #![feature(platform_intrinsics, repr_simd)] extern "platform-intrinsic" { fn simd_shuffle2<T, U>(x: T, y: T, idx: [u32; 2]) -> U; } #[repr(simd)] #[derive(Clone, Copy)] #[allow(non_camel_case_types)] struct u64x2(u64, u64); fn main() { let a = u64x2(1, 2); let r: u64x2 = unsafe { simd_shuffle2(a, a, [0-0, 0-0]) }; assert_eq!(r.0, 1); assert_eq!(r.1, 1); } </ins>

Discussion:
This code produces a compiler error with but compiles successfully with : The error is:
cc
This has to do with how the result of a checked op is a tuple and the 2's complement wrapping value is accessed through : the fix would be to track an initialization with a checked op in a field of , then treat as constant if is promotable and has that flag. I believe that the promoter will work as-is, it's just the constant qualifier that needs to understand this.
Looking at it again, the const qualifier works fine with fields, but the promoter's initial set of potentially promotable temporaries doesn't include the tuple because one of the uses is by-field.
Change:
/// ``` #[inline] #[stable(feature = "rust1", since = "1.0.0")] <del> #[rustc_const_unstable(feature = "const_str_from_utf8_unchecked", issue = "75196")] </del> <ins> #[rustc_const_stable(feature = "const_str_from_utf8_unchecked", since = "1.55.0")] </ins> #[rustc_allow_const_fn_unstable(const_fn_transmute)] pub const unsafe fn from_utf8_unchecked(v: &[u8]) -> &str { // SAFETY: the caller must guarantee that the bytes `v` are valid UTF-8.

Discussion:
This is a tracking issue for , made const in . The feature gate for the issue is . [x] Merge the implementation PR [x] Final Comment Period (FCP) [x] Stabilization PR ()
This is an unsafe operation and thus likely also blocked on Cc
Now that rust-lang/rfcs is merged: merge cc
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Stabilization PR is already up:
Change:
BASE_DOC_OPTS := --standalone --toc --number-sections HTML_OPTS = $(BASE_DOC_OPTS) --to=html5 --section-divs --css=rust.css  <del> --include-before-body=doc/version_info.html --include-in-header=doc/favicon.inc TEX_OPTS = $(BASE_DOC_OPTS) --include-before-body=doc/version.md --to=latex </del> <ins> --include-before-body=doc/version_info.html  --include-in-header=doc/favicon.inc --include-after-body=doc/footer.inc TEX_OPTS = $(BASE_DOC_OPTS) --include-before-body=doc/version.md  --from=markdown --include-before-body=doc/footer.tex --to=latex </ins> EPUB_OPTS = $(BASE_DOC_OPTS) --to=epub D := $(S)src/doc

Discussion:
Per we should have the docs licensed correctly. Nominating.
I can have a look at this.
Change:
thread 'main' panicked at 'oh no', $DIR/failed-doctest-output.rs:3:1 note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace. <del> ', src/librustdoc/test.rs:332:17 </del> <ins> ', src/librustdoc/test.rs:341:17 </ins> failures:

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:
if { return } { } <ins> // regression test for https://github.com/rust-lang/rust/issues/106899 return println!("!"); //~^ WARN unnecessary braces </ins> }

Discussion:
The false negative bisects to , so pretty obviously . FYI From skimming , that's an issue about const generics. It doesn't seem like the PR was supposed to have affected unused_braces situations outside of const generics position.
Change:
let cid = key.value; let def_id = cid.instance.def.def_id(); <del> if def_id.is_local() && tcx.typeck_tables_of(def_id).tainted_by_errors { </del> <ins> if def_id.is_local() && tcx.has_typeck_tables(def_id) && tcx.typeck_tables_of(def_id).tainted_by_errors { </ins> return Err(ErrorHandled::Reported); }

Discussion:
This code causes an ICE starting from Rust 1.41.0 (stable, beta, and nightly): Error: No extra flags were . It also happens in release mode. Rust Playground is at version 1.40.0 and doesn't have the error on stable:
Another version:
cc
Bisected: ,
This should be checking before calling :
triage: P-high. Removing nomination. Assigning to self.
Change:
<ins> // run-rustfix fn foo(x: &str) -> bool { x.starts_with(&("hi".to_string() + " you")) //~^ ERROR expected a `FnMut<(char,)>` closure, found `String` } fn foo2(x: &str) -> bool { x.starts_with(&"hi".to_string()) //~^ ERROR expected a `FnMut<(char,)>` closure, found `String` } fn main() { foo("hi you"); foo2("hi"); } </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. --Given the following 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
The code here: Seems we can only get more context from , with only we can not know whether the current code snippet is an ident or a more complicated expression. The current is . An completed solution should make sure we get something like in ? A hack I'm thinking is checking whether contains spaces, if so we suggest it like:
I guess we have more similar issues for other suggestions come from .
This is an similar case, but we handle it well: Output is: The codepath is different, we take care parenthesis here, with :
Change:
} }; <del> ConstValue::Scalar(scalar) </del> <ins> Some(ConstValue::Scalar(scalar)) </ins> }

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting a malformed float error, so low priority. Note that slight modifications of the input fix the panic. For example using instead of results in no panic. Also there is no panic if compling only the string . Affected versions: I tried nightly 2021-11-30 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Might be related? Formatting of "1e-15" behavior seems to have changed on nightly for f64 and f32.
It may have a common cause, but you should open a separate issue because the pull request that fixes this doesn't fix your problem.
Change:
"rustc-serialize 0.3.24 (registry+https://github.com/rust-lang/crates.io-index)", "serde 1.0.6 (registry+https://github.com/rust-lang/crates.io-index)", "serde_json 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)", <del> "tar 0.4.12 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "tar 0.4.13 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "tempdir 0.3.5 (registry+https://github.com/rust-lang/crates.io-index)", "term 0.4.5 (registry+https://github.com/rust-lang/crates.io-index)", "url 1.4.0 (registry+https://github.com/rust-lang/crates.io-index)",

Discussion:
I got in a project of mine for recent nightlies which I think are releated to the rustification of rust-installer but I'm not 100% certain: does this sound familiar to you?
Oh looks like and are all related to this as well.
Ah, yes, backslashes in the manifest are an easily understood problem. Executable is harder. At least I left a note about that . :) Since Windows doesn't really have such flags, I suspect it must have worked on some MSYS tricks with ACLs before. Maybe we should make a special case for this when writing the tarball, like writing known-executable file names with manually-tweaked metadata?
Yeah I think we'll probably just want to special case everything going into the tarballs and manually set the metadata for the various bits and pieces. I'm... not entirely sure how this worked with MSYS, but presumably there's some weird translation layer which we're not aware of and isn't surfaced through winapi things...
OK, so should fix up the manifests at least. Researching the file modes, I first wondered whether the crate should read the advanced ACLs for , as right now it just . But it looks like all created files have "execute" privileges anyway -- e.g. even includes . You can remove that with in MSYS/Cygwin/etc., but it appears atypical for a file not_ to be executable. The good news is that also doesn't care about execute when unpacking on Windows, just . The rest will follow the defaults of , still with executable ACLs. So I think the permissions created by rustup will be fine, but I guess if one manually unpacks with MSYS/Cygwin tar they may get non-executable etc. The quickest hack for you would be to just change this: Step 7 : RUN /tmp/rust-mingw-nightly-i686-pc-windows- --prefix= ... to invoke instead, which doesn't care about execute privileges. :)
Ah yeah I don't think there's a great way to flag a file on Windows as executable/not-executable, I'm basically just thinking that we have a whitelist of files/patterns that will get listed as executable in the tarball (as the tarball stores unix modes) and we'd just follow that.
Change:
cargo.arg("-Zskip-rustdoc-fingerprint"); // Only include compiler crates, no dependencies of those, such as `libc`. cargo.arg("--no-deps"); <ins> cargo.arg("--lib"); </ins> $( cargo.arg("-p").arg($krate); )+

Discussion:
Since , itself gets documented. Unfortunately, the package contains a binary crate called (, Shim which is passed to Cargo as “rustdoc” when running the bootstrap.) which clashes with the actual package () overwriting the latter since it gets documented last. See for yourself: (this ain't rustdoc). CC (). label C-bug T-bootstrap A-docs A-contributor-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
ah, thanks! I think the fix is to pass to cargo so it doesn't try to document the binaries, they don't have anything useful.
Alternatively - maybe better? - we could rename to , which seems more clear anyway.
claim