jiebi/CodeConvo huggingface dataset:
Change:
/// is `Obligation`, as one might expect. During trans, however, this /// is `()`, because trans only requires a shallow resolution of an /// impl, and nested obligations are satisfied later. <del> #[derive(Clone)] </del> <ins> #[derive(Clone, PartialEq, Eq)] </ins> pub struct VtableImplData<'tcx, N> { pub impl_def_id: ast::DefId, pub substs: subst::Substs<'tcx>,

Discussion:
That's a mouthful! To exemplify: This doesn't compile with , even though it does without it. Note that the only difference between the two configurations is that the function on is a free function instead of a default method. With , this fails with: Tested on
cc me
I've been running into very similar errors all day while updating my libs to the latest nightly. Here's an example of a method that works fine along with one that does not (simplest example I could come up with).
This example works now. I think this was a dup of
I just updated to master and I'm still running into the same error - perhaps my error is a separate issue?
Edwardw's PR does seem to fix my issue however, perhaps it addresses something extra?
The original issue is still present if the example on the first post is compiled with . I tested on , which contains Edit: just compiled . Still reproducible
Change:
} pub fn increment_outstanding_references_for(&self, name: Name, ns: Namespace, is_public: bool) { <del> let mut resolutions = self.resolutions.borrow_mut(); let resolution = resolutions.entry((name, ns)).or_insert_with(Default::default); resolution.outstanding_references += 1; if is_public { resolution.pub_outstanding_references += 1; } } fn decrement_outstanding_references_for(&self, name: Name, ns: Namespace, is_public: bool) { let decrement_references = |count: &mut _| { assert!(*count > 0); *count -= 1; }; self.update_resolution(name, ns, |resolution| { decrement_references(&mut resolution.outstanding_references); if is_public { decrement_references(&mut resolution.pub_outstanding_references); } }) </del> <ins> self.resolutions.borrow_mut().entry((name, ns)).or_insert_with(Default::default) .increment_outstanding_references(is_public); </ins> } // Use `update` to mutate the resolution for the name.

Discussion:
Unfortunately, I can't reproduce this at a smaller scale. This issue occurs with as of commit . Rust version is Currently the tests (run from the directory with ) pass. However, applying the following patch: causes the following compiler error: which is claiming that an import conflicts with itself. I have pushed up the branch with that change applied for easy reproduction. Again, I'm sorry that I cannot provide a report on a smaller scale, but this appears to be some edge case blowing up. I have no clue why adding a module with a few imports and nothing else would be causing this issue.
Bisecting to find the nightly which caused this
I can confirm that this issue does not occur on . Unfortunately, there was a bug that prevented us from compiling on that wasn't fixed until , so I cannot provide anything more specific than that.
cc
Thanks for the report! This bug was introduced in . I diagnosed the issue and will fix it ASAP.
Change:
} }; if let Some((expected, found)) = expected_found { <del> let expected_label = exp_found.map_or("type".into(), |ef| ef.expected.prefix_string()); let found_label = exp_found.map_or("type".into(), |ef| ef.found.prefix_string()); </del> <ins> let expected_label = match exp_found { Mismatch::Variable(ef) => ef.expected.prefix_string(), Mismatch::Fixed(s) => s.into(), }; let found_label = match exp_found { Mismatch::Variable(ef) => ef.found.prefix_string(), Mismatch::Fixed(s) => s.into(), }; let exp_found = match exp_found { Mismatch::Variable(exp_found) => Some(exp_found), Mismatch::Fixed(_) => None, }; </ins> match (&terr, expected == found) { (TypeError::Sorts(values), extra) => { let sort_string = |ty: Ty<'tcx>| match (extra, &ty.kind) {

Discussion:
Causes the following error: This is somewhat confusing, especially since is not a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This looks similar to what I reported in
Here we don't account for anything other than type mismatches which means that later we use the generic prefix We need to account for in the first snippet and ferry the prefix strings from there to the later (instead of what we do now).
I'd like to work on this claim
do not hesitate to reach out if you need help!
Do we need to get the correct prefix strings from the contents of or are they just ?
I believe they can be just "trait".
Change:
// aux-build:issue_3907.rs extern crate issue_3907; <del> type Foo = issue_3907::Foo; //~ ERROR: reference to trait </del> <ins> type Foo = issue_3907::Foo; </ins> struct S { name: int } impl Foo for S { //~ ERROR: `Foo` is not a trait <ins> //~^ NOTE: `type` aliases cannot be used for traits </ins> fn bar() { } }

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:
tcx.mk_args_trait(new_rcvr, args.into_iter().skip(1)) } <ins> #[instrument(skip(tcx), ret)] </ins> fn trait_object_ty<'tcx>(tcx: TyCtxt<'tcx>, poly_trait_ref: ty::PolyTraitRef<'tcx>) -> Ty<'tcx> { assert!(!poly_trait_ref.has_non_region_param()); let principal_pred = poly_trait_ref.map_bound(|trait_ref| {

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:
/// Literal kind. /// /// E.g., `"foo"`, `42`, `12.34`, or `bool`. <del> #[derive(Clone, RustcEncodable, RustcDecodable, Debug)] </del> <ins> // Clippy uses Hash and PartialEq #[derive(Clone, RustcEncodable, RustcDecodable, Debug, Hash, PartialEq)] </ins> pub enum LitKind { /// A string literal (`"foo"`). Str(Symbol, StrStyle),

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.
Change:
<ins> FROM ubuntu:16.04 RUN apt-get update && apt-get install -y --no-install-recommends  g++  make  file  curl  ca-certificates  python2.7  git  cmake  sudo  gdb  xz-utils ENV SCCACHE_DIGEST=7237e38e029342fa27b7ac25412cb9d52554008b12389727320bd533fd7f05b6a96d55485f305caf95e5c8f5f97c3313e10012ccad3e752aba2518f3522ba783 RUN curl -L https://api.pub.build.mozilla.org/tooltool/sha512/$SCCACHE_DIGEST |  tar xJf - -C /usr/local/bin --strip-components=1 RUN curl -OL https://github.com/Yelp/dumb-init/releases/download/v1.2.0/dumb-init_1.2.0_amd64.deb &&  dpkg -i dumb-init_*.deb &&  rm dumb-init_*.deb ENTRYPOINT ["/usr/bin/dumb-init", "--"] ENV RUST_CONFIGURE_ARGS --build=x86_64-unknown-linux-gnu ENV XPY_RUN test distcheck </ins>

Discussion:
The process of creating the tarballs doesn't include .gitignore files from src/vendor. This results in a missmatched hash failure when building with vendoring enabled. Hoping to switch to rustbuild with the next rust release! FYI: I'd be happy with the vendoring happening during the create tarball process, having enormous vendoring commits in the git history is ugly... !
Needs to be fixed for 1.15.
cc
Seems like the vendoring process should include a sanity check that the vendored sources hash correctly.
Fixed in
Things move fast around here. Awesome thanks!
Change:
//! The AST pointer. //! <del> //! Provides `P<T>`, a frozen owned smart pointer, as a replacement for `@T` in //! the AST. </del> <ins> //! Provides `P<T>`, a frozen owned smart pointer. </ins> //! //! # Motivations and benefits //! //! * **Identity**: sharing AST nodes is problematic for the various analysis //!   passes (e.g., one may be able to bypass the borrow checker with a shared <del> //!   `ExprKind::AddrOf` node taking a mutable borrow). The only reason `@T` in the //!   AST hasn't caused issues is because of inefficient folding passes which //!   would always deduplicate any such shared nodes. Even if the AST were to //!   switch to an arena, this would still hold, i.e., it couldn't use `&'a T`, //!   but rather a wrapper like `P<'a, T>`. </del> <ins> //!   `ExprKind::AddrOf` node taking a mutable borrow). </ins> //! //! * **Immutability**: `P<T>` disallows mutating its inner `T`, unlike `Box<T>` //!   (unless it contains an `Unsafe` interior, but that may be denied later).

Discussion:
The comments are quite old and probably need some small updates to reflect having been removed from the language. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think I should be able to handle this. Hopefully some time in the next few days. Am I right in thinking I just do this? claim I've found the documentation style RFC, and some info about what was, which should hopefully be enough info to improve this comment. If there's anything else specific I should consider plz let me know.
Yes, you can definitely just do this and any questions which come up can be addressed on the (eventual) PR most likely. I imagine it's mostly a matter of just deleting related documentation; if you want to try and replace it with something more up to date that would be even better.
Change:
<ins> error: unterminated double quote string --> $DIR/issue-44078.rs:12:8 | 12 |       "😊""; |  ________^ 13 | | } | |__^ error: aborting due to previous error </ins>

Discussion:
has saying that the column info is provided in characters, not in bytes. However, the error emitter doesn't care about that at all and uses these like byte offsets all over the place. This leads to bugs like and . As an example, look how span printing varies with varying characters used: Correct case: Now add an emoji character: Note how its off by one char now. This can stack up: If I didn't use any spaces at all, I'd run into . Now this can be fixed by going through the emitter code and looking for all places where the pos is used in a byte position fashion. A much more proper fix instead is to stop trusting that people read comments and encode this via the type system. There is already a mechanism for that inside the compiler, its ! Just convert the types of , members of the and structs to , or maybe to if that's preferred.
cc
Change:
projection: self.tcx.mk_place_elems_from_iter( [mir::ProjectionElem::Field(remapped_idx, remapped_ty)] .into_iter() <del> .chain(additional_projections) .chain(final_deref.iter().copied()), </del> <ins> .chain(bridging_projections) .chain(final_projections.iter().copied()), </ins> ), }; }

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Sorry you hit this ICE. This should be fixed by , which landed 15 minutes ago, though will probably not make it into nightly until two days from now (10 April 2024).
Actually, it's not yet fixed. I have a follow-up PR that will fix this :facepalm:
Change:
} pub fn get_attr(self, did: DefId, attr: Symbol) -> Option<&'tcx ast::Attribute> { <del> self.get_attrs(did, attr).next() </del> <ins> if cfg!(debug_assertions) && !rustc_feature::is_valid_for_get_attr(attr) { bug!("get_attr: unexpected called with DefId `{:?}`, attr `{:?}`", did, attr); } else { self.get_attrs(did, attr).next() } </ins> } /// Determines whether an item is annotated with an attribute.

Discussion:
currently happily ignores any additional attributes in case there are more than one. While this is fine for attributes which don't care about duplicates or emit a warning/error in case there are more than one, this isn't currently checked in the compiler, potentially causing bugs. similar to the check in we should check that the attr declaration in has an acceptable way of dealing with duplicates. in case there are any questions on how to implement this, feel free to open a thread on zulip and pinging me there. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // Copyright 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. // Test that the unboxed closure sugar can be used with an arbitrary // struct type and that it is equivalent to the same syntax using // angle brackets. This test covers only simple types and in // particular doesn't test bound regions. #![feature(unboxed_closures)] #![allow(dead_code)] trait Foo<T,U> { fn dummy(&self, t: T, u: U); } trait Eq<Sized? X> for Sized? { } impl<Sized? X> Eq<X> for X { } fn eq<Sized? A,Sized? B:Eq<A>>() { } fn main() { eq::< for<'a> Foo<(&'a int,), &'a int>, Foo(&int) -> &int                                   >(); eq::< for<'a> Foo<(&'a int,), (&'a int, &'a int)>, Foo(&int) -> (&int, &int)                           >(); let _: Foo(&int, &uint) -> &uint; //~ ERROR missing lifetime specifier } </ins>

Discussion:
HRTB doesn't correctly implement lifetime elision for notation. See the test .
Nominating.
notes that this can be fixed backwards compatibly, and agrees. P-high, not 1.0.
Well, sort of -- I mean lifetime elision broke code, but almost only bad code. The problem is that people can use to satisfy the signature and then clients get to assume any lifetime they want.
Change:
let output_capture = crate::io::set_output_capture(None); crate::io::set_output_capture(output_capture.clone()); <ins> // Pass `f` in `MaybeUninit` because actually that closure might *run longer than the lifetime of `F`*. // See <https://github.com/rust-lang/rust/issues/101983> for more details. // To prevent leaks we use a wrapper that drops its contents. #[repr(transparent)] struct MaybeDangling<T>(mem::MaybeUninit<T>); impl<T> MaybeDangling<T> { fn new(x: T) -> Self { MaybeDangling(mem::MaybeUninit::new(x)) } fn into_inner(self) -> T { // SAFETY: we are always initiailized. let ret = unsafe { self.0.assume_init_read() }; // Make sure we don't drop. mem::forget(self); ret } } impl<T> Drop for MaybeDangling<T> { fn drop(&mut self) { // SAFETY: we are always initiailized. unsafe { self.0.assume_init_drop() }; } } let f = MaybeDangling::new(f); </ins> let main = move || { if let Some(name) = their_thread.cname() { imp::Thread::set_name(name);

Discussion:
Scopes threads as currently implemented are potentially unsound due to passing a reference to a function where the memory the reference points to is potentially deallocated while the function still runs. Specifically, takes as implicit argument its closure environment, which contains . That environment might just be a reference to some memory that is allocated in the caller stack frame. However the function can keep running after got dropped (implicitly at the end of ). Then the scope might end and the memory might be deallocated all while is still running. If the environment is just a reference, it ends up being a newtype and we will (AFAIK) add the attribute, meaning deallocation while the function runs is actually LLVM UB. Miri found the error in , where the invalidates the reference that was passed to the forked-off threads. ( doesn't actually get deallocated, it just has a unique reference created to it, but deallocation is also a possibility). To fix this properly, I think we need a language extension: we want a way to store references in a type without having alias guarantees for that reference. In terms of Stacked Borrows this means Stacked Borrows will stop recursing at that type during retags. In terms of the LLVM IR we generate it means we must not add or attributes for references inside that type. We don't have such a type currently but I think it makes sense to make that type (or even if we add a new type for this, should use it). Also see .
I believe included a fix for this.
Doesn't look like it -- the user-provided closure seems to be handled exactly the same as currently?
Ah, I read too quickly and misunderstood, apologies. It solves a different potential unsoundness (one more similar to the Arc drop issue).
Yeah, it looks like an alternative fix for the part of
While the , I am proposing a preliminary fix in
Change:
pub use core::time::Duration; #[unstable(feature = "duration_checked_float", issue = "83400")] <del> pub use core::time::FromSecsError; </del> <ins> pub use core::time::FromFloatSecsError; </ins> /// A measurement of a monotonically nondecreasing clock. /// Opaque and useful only with [`Duration`].

Discussion:
Hello. I am diagnosing why I've got a wrong duration computed from Duration::fromsecsf32()... I tried this code: I expected to see an exact 30-second duration. Instead, I've got this: which is: 30 seconds and 1024 nanos. I dig deeper into rust code and I've prepared a sample code which is computing it based on the source code: As the result I've got: Instead of exact 30 seconds and 0 nanos.
?
Works on current stable and nightly: I mean, that this issue exist for that versions.
yep, I also confirmed on:
What is interesting the function: fromsecsf64 doesn't seem to have this problem... so a quick workaround would be use it and cast from f32 to f64
Extending(?) f32 to u128 gives this addition in 1024:
CC: CC: Adding authors ... guys please take a quick look if you have a time...
f32 will naturally have trouble representing all possible nanosecond values and so doing calculations in f64 may help here somewhat. However the most appropriate approach would be to decompose the float into the whole part and the fractional part and then operate on the two separately to produce the values necessary to create the . and may work sufficiently well for the purpose. EDIT: I think we would still need to be careful about how the nanosecond fraction is handled. We cannot simply multiply the number by and then convert to an integer, because is not capable of representing integers of such degree losslessly.
We cannot simply multiply the number by and then convert to an integer, because f32 is not capable of representing integers of such degree losslessly. Small correction: is represented exactly by , the problem is with . The closest float is , which results in the 1024 ns error. For example, would have produced an exact value. I would say such loss of precision is expected for and if you want exact values, you should use the integer based methods. So I don't think this issue should be marked as a bug. It could be worthwhile to improve the code by processing the fractional part separately, but note that it will not solve this issue fundamentally. We still have the issue of mapping at most 23 fractional bits into ~30 bits, e.g. calling would still result in an inexact result.

specifically may be representable exactly, but f32 cannot represent all integers exactly. Though maybe its not a huge deal if after we end up roundtripping back to the actual integer in all cases.
Argh, I forgot that the method is not available on , so the linked PR will not work out of box. UPD: I have implemented manual fraction/exponent splitting and their conversion to integers.
Change:
// See https://github.com/rust-lang/rust/issues/116538 cargo.rustflag("-Zunstable-options"); <del> // `-Zon-broken-pipe=kill` breaks cargo tests if !path.ends_with("cargo") { // If the output is piped to e.g. `head -n1` we want the process to be killed, // rather than having an error bubble up and cause a panic. cargo.rustflag("-Zon-broken-pipe=kill"); } </del> cargo }

Discussion:
After I noticed that whenever I modify tests (on Windows), stage 1 cargo gets unnecessary rebuilt which also triggers rebuilds for other tools like stage 0 rustdoc. I'm pretty sure something in my implementation is wrong w.r.t. to properly caching, but I didn't invest time in figuring out why yet, hence opening this bug to track it. The build sequence is something like stage 0 std -stage 1 rustc -stage 1 std -stage 1 tool cargo -stage 0 compiletest / run-make-support / rustdoc. Example repro steps: Run -make sure stage 1 cargo is already built. Modify a test. Observe that stage 1 cargo gets rebuilt even though I didn't modify it.
EDIT: oh, is it because in run-make-support or rustdoc we use or something that is a different staged cargo compared to the one we built with stage 1 rustc...
Actually unassigning because I don't know how to cleanly fix this just yet. EDIT: opened thread https://rust-
Running twice is enough to reproduce cargo rebuild issue. Probably some rustflags invalidating the build cache.
Reopening because we need to revert in favor of a different approach.
Change:
} #[test] <ins> #[cfg(unix)] // test doesn't work on Windows, see #31657 </ins> fn close_read_wakes_up() { each_ip(&mut |addr| { let a = t!(TcpListener::bind(&addr));

Discussion:
It just happend with my unrelated pull request on auto-win-msvc-32-opt. It is the only test that dit not complete between this build and the previous. It also contains the comment: "this test will never finish if the child doesn't wake up"
This seems to be relevant. A thread may not wake up on Windows if a socket is shut down.
Hm that just seems to indicate that the child will eventually wake up... I wonder if would fix the problem here?
Change:
--> $DIR/suggestions.rs:61:23 | LL |             Equinox { warp_factor: warp_factor } => {} <del> |                       ------------^^^^^^^^^^^^ |                       | |                       help: remove this </del> <ins> |                       ^^^^^^^^^^^^^^^^^^^^^^^^ help: use shorthand field pattern: `warp_factor` </ins> | = note: `#[warn(non_shorthand_field_patterns)]` on by default

Discussion:
Code: output: Note that in the attempted fix is incorrect syntax (it ate a colon). Edit: it probably actually isn't. Version info:
thanks for feedback :) it seems a rustfix bug, could you please file a issue there? cc
Will do. Is it intentional that suggests filing a bug in this repo (see the error message), or should that be changed?
This is the correct place to file the issue, it is a bug in . The issue is that the lint is providing a bad suggestion. Either the span needs to encompass the entire binding, or the suggested text needs to be the empty string.