jiebi/CodeConvo huggingface dataset:
Change:
--> $DIR/numeric-cast.rs:92:16 | LL |     foo::<i64>(x_u32); <del> |                ^^^^^ expected `i64`, found `u32` | help: you can convert an `u32` to `i64` and panic if the converted value wouldn't fit | LL |     foo::<i64>(x_u32.try_into().unwrap()); |                ^^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> |                ^^^^^ |                | |                expected `i64`, found `u32` |                help: you can convert an `u32` to `i64`: `x_u32.into()` </ins> error[E0308]: mismatched types --> $DIR/numeric-cast.rs:94:16 | LL |     foo::<i64>(x_u16); <del> |                ^^^^^ expected `i64`, found `u16` | help: you can convert an `u16` to `i64` and panic if the converted value wouldn't fit | LL |     foo::<i64>(x_u16.try_into().unwrap()); |                ^^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> |                ^^^^^ |                | |                expected `i64`, found `u16` |                help: you can convert an `u16` to `i64`: `x_u16.into()` </ins> error[E0308]: mismatched types --> $DIR/numeric-cast.rs:96:16 | LL |     foo::<i64>(x_u8); <del> |                ^^^^ expected `i64`, found `u8` | help: you can convert an `u8` to `i64` and panic if the converted value wouldn't fit | LL |     foo::<i64>(x_u8.try_into().unwrap()); |                ^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> |                ^^^^ |                | |                expected `i64`, found `u8` |                help: you can convert an `u8` to `i64`: `x_u8.into()` </ins> error[E0308]: mismatched types --> $DIR/numeric-cast.rs:98:16

Discussion:
() Errors: I would’ve expected something like: Edit: What actually should happen is the same as currently already with , i.e. it would look like modify labels: A-diagnostics, T-compiler, D-papercut, C-enhancement, E-easy <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Okay, lots of cases that already work got me confused into thinking this was fixed in nightly for a moment. What currently already works is the hint about converting where < where < What currently suggest even though works where < where ≤16 where ≤16
I reported a similar issue not long ago. Maybe it would be more robust and also more general to rewrite this suggestion code to actually look for the impl in question instead of having just a hard-coded list?
claim
I've created a PR augmenting the existing code to change the suggestions for the cases listed. However, I would like to explore the approach suggested(perhaps as part of a separate PR?). Any advice on how I could get the code to look for the impl so it can make the appropriate suggestion? Is the crate the right place to be looking at for this?
Yeah. I believe you'll need to create an and and then call , but there might be other/better ways to do this. You might want to ask for advice on Zulip.
Change:
<ins> error: non-item in item list --> $DIR/issue-105226.rs:7:56 | LL | impl S { |        - item list starts here LL |     fn hello<P>(&self, val: &P) where P: fmt::Display; { |                                                      - ^ non-item starts here |                                                      | |                                                      help: consider removing this semicolon ... LL | } | - item list ends here error: associated function in `impl` without body --> $DIR/issue-105226.rs:7:5 | LL |     fn hello<P>(&self, val: &P) where P: fmt::Display; { |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^- |                                                      | |                                                      help: provide a definition for the function: `{ <body> }` error: associated function in `impl` without body --> $DIR/issue-105226.rs:15:5 | LL |     fn hello_empty<P>(&self, val: &P) where P: fmt::Display; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^- |                                                            | |                                                            help: provide a definition for the function: `{ <body> }` error: aborting due to 3 previous errors </ins>

Discussion:
When copying bounds from a trait assoc item, you can accidentally copy the semicolon. If you forget to remove it, multiple errors are emitted, while the second is: This should be explicitly handled to avoid knock down errors. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
} } <ins> impl ImplPolarity { /// The polarity marker in front of the impl trait ref if applicable. pub fn as_str(self) -> &'static str { match self { Self::Positive => "", Self::Negative => "!", Self::Reservation => "", } } } </ins> /// Polarity for a trait predicate. May either be negative or positive. /// Distinguished from [`ImplPolarity`] since we never compute goals with /// "reservation" level.

Discussion:
The following code: produces: which reads as: any , which isn't realy true. It realy implements . Perhaps the error message should add a in front of the impl to make it more obvious, like this:
Hi , I'd like to take up this issue if it has not been assigned yet. However this would be my first contribution so I just want to confirm it's a good first task. Thanks!
Yeah, for sure! It should be as simple as updating () to account for the polarity. You can query/obtain the impl polarity with . Feel free to reach out here or on Zulip if you have any questions.
Change:
fn from_target_feature( tcx: TyCtxt, <ins> id: DefId, </ins> attr: &ast::Attribute, whitelist: &FxHashMap<String, Option<String>>, target_features: &mut Vec<Symbol>,

Discussion:
Given this code: it compiles as: How odd!
Not technically a regression but this needs to be fixed before 1.27 hits stable, so tagging as a nightly regression

Given: and you'll see: But that's not right! Only the original crate should need this directive, and it indeed has such a directive.
Change:
<ins> // ignore-test macro_rules! aaa { ($c:ident) => {{ let a = $c; }} } </ins>

Discussion:
When trying to compile the tests for my I get this error: <details<summary</summary</detailsMy understanding is that the compiler was trying to tell me about a borrow checker error; but I have no idea where to start minimizing this error(sorry).
I have managed to get it down to two files: It doesn't work with a in the , it has to be a different file. is then needed to trigger the ICE.
modify labels: I-ICE A-macros C-Bug T-compiler
cc
Seems to be related to 2018 edition? If I use the nightly-2018-10-01 and execute it doesn't ICE, but with it does ICE. well...
Most likely related to the fact that NLL is active in Rust 2018 then.
Bisecting: Somewhere in
Confirmed. gave me the ICE on 2015 as well (forgot that in the good ol' days nll was not a thing) Also confirmed, that edition 2015 does ICE with on and not on (like edition 2018 did above).
Also ICE with
Change:
} #[test] <ins> fn test_into_iter_drop_allocator() { struct ReferenceCountedAllocator<'a>(DropCounter<'a>); unsafe impl Allocator for ReferenceCountedAllocator<'_> { fn allocate(&self, layout: Layout) -> Result<NonNull<[u8]>, core::alloc::AllocError> { System.allocate(layout) } unsafe fn deallocate(&self, ptr: NonNull<u8>, layout: Layout) { System.deallocate(ptr, layout) } } let mut drop_count = 0; let allocator = ReferenceCountedAllocator(DropCounter { count: &mut drop_count }); let _ = Vec::<u32, _>::new_in(allocator); assert_eq!(drop_count, 1); let allocator = ReferenceCountedAllocator(DropCounter { count: &mut drop_count }); let _ = Vec::<u32, _>::new_in(allocator).into_iter(); assert_eq!(drop_count, 2); } #[test] </ins> fn test_from_iter_specialization() { let src: Vec<usize> = vec![0usize; 1]; let srcptr = src.as_ptr();

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I'm trying out the allocator api with the goal of being able to track memory usage for parts of a program: I expected this to work (and print 0 at the end), but instead it fails by freeing an invalid pointer: Running with miri gives a bit more context:
This seems to be a problem with the implementation of because if I do: There is no crash and no Miri error, this to me indicate that there is a problem in the implementation of . Another interesting things is the message I have locally , I don't know what it means but it's certainly interesting. label +T-libs +I-unsound
The drop guard used in the implementation of IntoIter makes a raw copy of an allocator when reconstructing RawVec. The allocator is then dropped twice, once by RawVec drop and second time by IntoIter drop. cc .
Minimal reproduction of problem: Prints:
Change:
struct Void { _priv: (), <ins> /// Erases all oibits, because `Void` erases the type of the object that /// will be used to produce formatted output. Since we do not know what /// oibits the real types have (and they can have any or none), we need to /// take the most conservative approach and forbid all oibits. /// /// It was added after #45197 showed that one could share a `!Sync` /// object across threads by passing it into `format_args!`. _oibit_remover: PhantomData<*mut Fn()>, </ins> } /// This struct represents the generic "argument" which is taken by the Xprintf

Discussion:
is only parameterized on lifetime. The types of the captured arguments are erased in the contained . Nothing restricts the aggregate from being or , so by OIBIT it's both. Thus this compiles: I'm not sure if there are any realistic ways to accidentally abuse this, but here's a deliberate example. The spawned thread will read the through the arguments, even while the main thread modifies it.
Change:
<ins> #![feature(const_fn)] // @has 'issue_76501/fn.bloop.html' '//pre' 'pub const fn bloop() -> i32' /// A useless function that always returns 1. pub const fn bloop() -> i32 { 1 } /// A struct. pub struct Struct {} impl Struct { // @has 'issue_76501/struct.Struct.html' '//*[@class="method"]' 'pub const fn blurp() -> i32' /// A useless function that always returns 1. pub const fn blurp() -> i32 { 1 } } </ins>

Discussion:
This is a follow-up on I opened earlier, with the requested minimal reproduction in the form of a simple .
Looks like this is either or cc - do you know what those are doing/why they exist?
It's because of the feature. As long as it's not stable, they don't want the keyword to be displayed, even if the function description is describing a const fn. This is a bit strange.
Yeah, that makes no sense to me at all. I have a crate that is very much nightly-only containing a rather large number of s, and at the moment literally none of them are displayed as such in my documentation because of this, despite the fact that they've never not been and will never not be in the future. I of course cannot disable the flag either as then the crate won't compile, as much of what I'm doing does not fit into the stabilized set of functionality. At the very least, surely there must be some way to make it possible to specifically tell rustdoc to "please always document s as exactly what they are no matter what" without changing this default behaviour if that's not desired?
I think the metric should be 'does this have , not 'is this a function'.
I wonder if this isn't an artifact of the switch when adding support... But in any case, it should be a check over , you're absolutely right.
I wonder if this ever worked ... do you mind trying this with an old version of rustdoc? Preferably before was implemented: cc
I'll try that on my crate later today.
After testing both the example I gave here and my own crate with various nightlies from before was implemented, I can confirm that this problem definitely pre-dates it. There's no difference in how rustdoc behaved.
(apologies to lcnr for the ping)
If this helps at all, whichever version of rustdoc was using on August 1st did document my crate properly, it seems. Only the very latest version, uploaded on September 5th, was documented with the keyword missing. So it's a fairly recent bug, overall.
Ok, so I think I was reading the dates on the PRs a bit wrong when I tested yesterday as far as the timeframe for when was merged.

I just did a whole bunch more one-by-one testing of nightlies from August, and in fact the problem doesn't quite predate which was merged on August 7th. Specifically, the very last nightly to have a rustdoc that documents correctly is . Switching directly from that to from the next day makes the problem appear.
consider using instead which will do it automatically
Well, I already know it's a commit from between the 10th and 11th of August now, at least. Also, doesn't really seem to be designed for scenarios where identifying the problem specifically requires running on a crate and then visually inspecting the generated HTML files...
Change:
/// ``` #[inline] #[must_use] <del> #[unstable(feature = "cmp_min_max_by", issue = "64460")] </del> <ins> #[stable(feature = "cmp_min_max_by", since = "1.53.0")] </ins> pub fn min_by<T, F: FnOnce(&T, &T) -> Ordering>(v1: T, v2: T, compare: F) -> T { match compare(&v1, &v2) { Ordering::Less | Ordering::Equal => v1,

Discussion:
Tracking issue for the feature, which adds the / / / functions to . PR:
Is there anything blocking this from stabilizing?
Doesn't look like it! If somebody would like to open a stabilization PR then we can start a FCP
Stabilization PR up at
Change:
// there on out. let subcommand = args.iter().find(|&s| { (s == "build") <ins> || (s == "b") </ins> || (s == "check") <ins> || (s == "c") </ins> || (s == "clippy") || (s == "fix") || (s == "fmt") || (s == "test") <ins> || (s == "t") </ins> || (s == "bench") || (s == "doc") || (s == "clean") || (s == "dist") || (s == "install") || (s == "run") <ins> || (s == "r") </ins> }); let subcommand = match subcommand { Some(s) => s,

Discussion:
currently supports , and a few others even though not so discoverable (). It would be good to let supports the aliases supported by , such as , and such. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
continue; } <del> debug!("try_promote_type_test: ur={:?}", ur); </del> let non_local_ub = self.universal_region_relations.non_local_upper_bounds(ur); debug!("try_promote_type_test: non_local_ub={:?}", non_local_ub);

Discussion:
This code compiles after although it shouldn't: () This is similar to in that we're not taking into account placeholder regions when "promoting" type-tests from the closure to its caller: label T-types regression-from-stable-to-beta C-bug A-NLL I-unsound <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I guess it would be an easy fix claim
The unsoundness exploitation in can easily be adapted for this issue, so it is in fact a soundness issue:
issue touched in today's T-compiler meeting, . Will also be discussed tomorrow during the T-types meeting.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
<ins> // Regression test for #81712. #![feature(generic_associated_types)] #![allow(incomplete_features)] trait A { type BType: B<AType = Self>; } trait B { type AType: A<BType = Self>; } trait C { type DType<T>: D<T, CType = Self>; //~^ ERROR: missing generics for associated type `C::DType` [E0107] } trait D<T> { type CType: C<DType = Self>; } fn main() {} </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. --This ICE is related to : <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsIdeally, would compile, but generic associated types in trait paths are currently not implemented. Maybe rustc could give a nice error message when the is missing.
Duplicate to and related heavily to others. But this has a nice minimal repro, so worth leaving open. Probably fixed by .
I've tested this locally and I can confirm that fixes this (with this change: ).
Change:
libc::open(path.as_ptr(), flags, opts.mode) })); let fd = FileDesc::new(fd); <ins> // Even though we open with the O_CLOEXEC flag, still set CLOEXEC here, // in case the open flag is not supported (it's just ignored by the OS // in that case). </ins> fd.set_cloexec(); Ok(File(fd)) }

Discussion:
After lands we will be setting on all file descriptors on unix in the standard library. Currently we do so in a nonatomic fashion, however, so it's possible to continue to leak file descriptors into children if a thread is concurrently forking. Many platforms have methods of creating file descriptors atomically, but many of the APIs are quite new and they need to be properly detected at runtime. For example, the current instances of that need to be migrated are listed below. A reminder of our minimum platform requirements are linux 2.6.18 and OSX 10.7. [x] - this should specify the flag. This flag was in linux 2.6.23 and appears to exist on OSX 10.7. [x] - this should be specify the flag in the argument (second). This flag was only in linux 2.6.27 and does not exist on OSX. [x] - this should be replaced with a call to . This system call was only in linux 2.6.28 and does not exist on OSX. [x] - this should be replaced with (linux 2.6.27, not on OSX) or (linux 2.6.24, appears to exist on OSX 10.7). [x] - this could be replaced with on linux 2.6.27 and perhaps on OSX (not confirmed). The hard part about this bug is figuring out if it's possible to avoid compile-time detection of these functions (and instead rely on runtime detection).
cc
I know this is closed, but I just have to comment on how well thought out and organised the original description was - how clearly the problem is captured and then it's solution tracked. Well done everyone.
Change:
self.used_imports.insert(import.id); } } <del> /// Take primary and additional node IDs from an import and select one that corresponds to the /// given namespace. The logic must match the corresponding logic from `fn lower_use_tree` that /// assigns resolutons to IDs. pub(crate) fn import_id_for_ns(&self, import: &Import<'_>, ns: Namespace) -> NodeId { if let ImportKind::Single { additional_ids: (id1, id2), .. } = import.kind { if let Some(resolutions) = self.import_res_map.get(&import.id) { assert!(resolutions[ns].is_some(), "incorrectly finalized import"); return match ns { TypeNS => import.id, ValueNS => match resolutions.type_ns { Some(_) => id1, None => import.id, }, MacroNS => match (resolutions.type_ns, resolutions.value_ns) { (Some(_), Some(_)) => id2, (Some(_), None) | (None, Some(_)) => id1, (None, None) => import.id, }, }; } } import.id } </del> } /// An error that may be transformed into a diagnostic later. Used to combine multiple unresolved

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see no output from the compiler. Instead, this happened: searched nightlies: from nightly-2022-09-22 to nightly-2022-09-27 regressed nightly: nightly-2022-09-25 searched commit range: regressed commit: This is a roll-up, seems the most likely culprit. cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: aarch64-apple-darwin Reproduce with: </details modify labels: +regression-from-stable-to-nightly -regression-untriaged
WG-prioritization assigning priority, probably a P-high since the lint malfunction is blocking valid code (iiuc) label -I-prioritize P-high T-compiler
any ideas how to address this or should I start digging in to it
In HIR desugars into two items (import in type namespace and import in value namespace). One of them is externally reachable and another is not (before both of them were incorrectly marked as externally reachable). Code in should somehow account for this desugaring and not report the as unnecessary if at least one of the imports is reachable.
I have been unable to fix this or apply a revert. can you look at implementing this before the beta cutoff?
Reverted in
Change:
<ins> // Copyright 2016 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. type Alias = (); use Alias::*; //~ ERROR Not a module use std::io::Result::*; //~ ERROR Not a module trait T {} use T::*; //~ ERROR items in traits are not importable fn main() {} </ins>

Discussion:
Code that compiles fine with rustc is causing an internal compiler error: unexpected panic with rustdoc. I tried this code (): The second line is essentially a typo, which can happen if used to be an Enum for instance. Again, the following works fine (although I'm not sure why, can you even add anything to the namespace?): However, if I run: I get the error: This actually happened on a version of a package already pushed to (hdf5-sys 0.3.0), so anything that depends on the erroneous version and runs will see this error. Run on . Backtrace:
This is easy to fix in rustdoc, but should this even compile?
Whoa kinda crazy... cc (resolve weridness, longstanding though!)
Change:
} #[inline] <del> fn conv_from_spec_abi(tcx: TyCtxt<'_>, abi: SpecAbi) -> Conv { </del> <ins> fn conv_from_spec_abi(tcx: TyCtxt<'_>, abi: SpecAbi, c_variadic: bool) -> Conv { </ins> use rustc_target::spec::abi::Abi::*; <del> match tcx.sess.target.adjust_abi(abi) { </del> <ins> match tcx.sess.target.adjust_abi(abi, c_variadic) { </ins> RustIntrinsic | PlatformIntrinsic | Rust | RustCall => Conv::Rust, // This is intentionally not using `Conv::Cold`, as that has to preserve

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.