jiebi/CodeConvo huggingface dataset:
Code change:
//! conflicts between multiple such attributes attached to the same //! item. <del> use rustc_ast::tokenstream::DelimSpan; use rustc_ast::{ast, AttrStyle, Attribute, Lit, LitKind, MacArgs, MetaItemKind, NestedMetaItem}; </del> <ins> use rustc_ast::{ast, AttrStyle, Attribute, Lit, LitKind, MetaItemKind, NestedMetaItem}; </ins> use rustc_data_structures::fx::FxHashMap; use rustc_errors::{pluralize, struct_span_err, Applicability, MultiSpan}; use rustc_expand::base::resolve_path;

Related discussion:
text: The warning by claims that on an impl item is ignored by rustdoc, but it isn't necessarily. The warning says: which is not true in the following repro: This warning is a false positive. Rustdoc does pay attention to this attribute. For the code above, the rendered documentation of and looks like: <table<tr<td<img src="https://user-" height="185"</td<td<img src="https://user-" height="300"</td</tr</tableAfter removing the supposedly unused attribute and rendering again, the "nasty uninteresting type" that we wanted not shown is going to get rendered on both pages: <table<tr<td<img src="https://user-" height="185"</td<td<img src="https://user-" height="300"</td</tr</table( : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
My bad, I did not notice that at all . I can adjust the lint once it's decided how we are going to proceed with my changes in general (see / blocked on ). claim
In summary, on methods in trait impl blocks does not lead to any visual changes in the documentation whereas on associated types and constants, it hides the implementation (or “the thing to the right of the ”). This weirdly deviates from my (former) personal mental model of how is supposed to work and be used. As far as I know, in all other cases, it leads to items, impl blocks, fields (“names” or “declarations”) not being shown. Here, however, the “name” keeps being shown, only the “value” is hidden. Hiding an inherent assoc item for example, hides the item completely. “Hiding” a trait impl item is, in my opinion, currently handled inconsistently by rustdoc and shouldn't lead to any visual changes (or rather “shouldn't be allowed”). Out of curiosity, @ dtolnay, how / why do you use this feature? Do you use it to reduce visual clutter? Edit: Ah, well, I overlooked the top right picture. So in some cases the item is indeed entirely hidden, not just the value.
Should I remove the lint entirely or should I adjust ?
Code change:
//! conflicts between multiple such attributes attached to the same //! item. <del> use rustc_ast::tokenstream::DelimSpan; use rustc_ast::{ast, AttrStyle, Attribute, Lit, LitKind, MacArgs, MetaItemKind, NestedMetaItem}; </del> <ins> use rustc_ast::{ast, AttrStyle, Attribute, Lit, LitKind, MetaItemKind, NestedMetaItem}; </ins> use rustc_data_structures::fx::FxHashMap; use rustc_errors::{pluralize, struct_span_err, Applicability, MultiSpan}; use rustc_expand::base::resolve_path;

Related discussion:
text: Just wanted to add that this is also affecting , but in a different way: <img width="500" src="https://user-"The isn't there at all without the : <img width="500" src="https://user-"Based on the above, this isn't correct: it actually hides the entire thing, at least for associated constants.
In your case, it's inherent associated items being accidentally flagged which is which was meaning the most recent nightly should not have your issue anymore. Sorry for the inconvenience. The longer I look this lint, the less I like it.
Code change:
5_000_000.times do count += 1 end <ins> count </ins> end end <del> threads.each { |t| t.join } </del> <ins> threads.each do |t| puts "Thread finished with count=#{t.value}" end </ins> puts "done!" ```

Related discussion:
text: I'm running the example from the section in Rust Book. I noticed that when I embed the code into Python and execute it, the execution time does not depend on the counter size (initially set to 5 million in the book). Although the text suggests it should (we are comparing execution time in different languages after all). However, if I modify the code to return, say, the count in the spawned thread (and later do , the execution time starts depending on the number of iterations. This seems not to depend on the number of iterations: This seems to get slower with more iterations (as it should): Why is this so? Is this some sort of compiler optimisation that removes the loop execution altogether? Should the code in the book be updated?
I thought that was enough to kill the optimization, but I guess not. Yes, it should be updated. (I think you can get rid of the `` too...)
Code change:
<del> Subproject commit 69268fb75fdb452296caa9bc4aaeff1674279de2 </del> <ins> Subproject commit e479ab26406ed8a473987e5f4a1f3be3e978e5d2 </ins>

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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 prioritization.
I need to port parts of from miri to rustc and only keep the actual miri-parts in miri. I'll try to get it done by tomorrow night.
check-in from compiler triage: Go go!
Code change:
<ins> //@ force-host //@ no-prefer-dynamic #![crate_type = "proc-macro"] #![feature(proc_macro_quote)] extern crate proc_macro; use proc_macro::{quote, TokenStream}; #[proc_macro_derive(AnotherMacro, attributes(pointee))] pub fn derive(_input: TokenStream) -> TokenStream { quote! { const _: () = { const ANOTHER_MACRO_DERIVED: () = (); }; } .into() } #[proc_macro_attribute] pub fn pointee( _attr: proc_macro::TokenStream, _item: proc_macro::TokenStream, ) -> proc_macro::TokenStream { quote! { const _: () = { const POINTEE_MACRO_ATTR_DERIVED: () = (); }; } .into() } #[proc_macro_attribute] pub fn default( _attr: proc_macro::TokenStream, _item: proc_macro::TokenStream, ) -> proc_macro::TokenStream { quote! { const _: () = { const DEFAULT_MACRO_ATTR_DERIVED: () = (); }; } .into() } </ins>

Related discussion:
text: https://crater- https://crater- cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
label F-derivesmartpointer
Thread on zulip: https://rust-
claim
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
} Operand::Constant(ref constant) => { <del> if let Some(static_) = constant.check_static_ptr(cx.tcx) { Self::in_static(cx, static_) </del> <ins> if constant.check_static_ptr(cx.tcx).is_some() { // `mir_const_qualif` does return the qualifs in the final value of a `static`, // so we could use value-based qualification here, but we shouldn't do this // without a good reason. // // Note: this uses `constant.literal.ty` which is a reference or pointer to the // type of the actual `static` item. Self::in_any_value_of_ty(cx, constant.literal.ty) </ins> } else if let ty::ConstKind::Unevaluated(def_id, _) = constant.literal.val { // Don't peek inside trait associated constants. if cx.tcx.trait_of_item(def_id).is_some() {

Related discussion:
text: root: gb2260-0.1.1: v. root: imperative - 3 (1 gh, 2 ) detected crates which regressed due to this <detailscommitted-0.1.11: v. imperative-1.0.1: v. epage/committed: v. </detailscc (likely MIR borrowck related, though not the transition itself as that happened last cycle)
Probably a result of the soundness fixes in
This is a change in promotion. cc
Minimized:
Maybe ?
or . No, it's neither of these.
It's , likely .
Code change:
<ins> fn thing() { let f = |_, _| (); f(f); //~ ERROR: closure/coroutine type that references itself //~^ ERROR: this function takes 2 arguments but 1 argument was supplied } fn main() {} </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: errors.isempty()'', 'thread 'rustc' panicked at 'assertion failed: errors.isempty()'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
cc
Code change:
//! goes along from the output of the previous stage. use std::borrow::Cow; <ins> use std::collections::HashSet; </ins> use std::env; use std::fs; use std::io::prelude::*;

Related discussion:
text: do you have the component installed? That adds a bunch more crates to the sysroot.
I believe these are required in rustc-dev as part of the need for (). I'll admit, I still don't fully understand the need for that, as it is quite mind-bending.
They are included in both rustc component and rustc-dev component. The latter are definitely used for example to build clippy, but I don't see reason for inclusion in rustc.
Code change:
#![feature(const_heap)] #![feature(const_index_range_slice_index)] #![feature(const_likely)] <del> #![feature(const_make_ascii)] </del> #![feature(const_nonnull_new)] #![feature(const_num_midpoint)] #![feature(const_option_ext)]

Related discussion:
text: Feature gate: This is a tracking issue for marking the and methods in , , , and as "const." [x] Implementation for : [x] Implementation for : [x] Implementation for and : [x] Final comment period (FCP) [x] Stabilization PRNone yet.
fcp merge / have been stable in const since 1.52. / are unblocked now by the stabilization of
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [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.
Can the methods be included in this? Similarly const stable / since 1.52.
Yes, that sounds like a good idea. I'll try adding another PR later.
:bell: This is now entering its final comment period, as per the . :bell:
stabilises this.
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. This will be merged soon.
Code change:
<ins> // Copyright 2018 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(associated_consts)] impl A for i32 { type Foo = u32; } impl B for u32 { const BAR: i32 = 0; } trait A { type Foo: B; } trait B { const BAR: i32; } fn generic<T: A>() { // This panics if the universal function call syntax is used as well println!("{}", T::Foo::BAR); } fn main() {} </ins>

Related discussion:
text: Code works cc
Bug triage: on current nightly (), this no longer is an ICE, but yields the following error:
Code change:
/// # Examples /// /// ```no_run <del> /// #![feature(udp_peer_addr)] </del> /// use std::net::{Ipv4Addr, SocketAddr, SocketAddrV4, UdpSocket}; /// /// let socket = UdpSocket::bind("127.0.0.1:34254").expect("couldn't bind to address");

Related discussion:
text: Tracking issue for making on stable: ,
FYI, in Rust issue tracker, "tracking issue" is a jargon for stabilizing features already in nightly. As I understand, is not yet in nightly?
A tracking issue has to be opened before a feature can land in nightly, because the attribute needs an issue number to refer to. has also been approved already, so it'll land in one of the next nightlies.
How about moving this to stable?
What's left to do to stabilize this feature? Any ETA?
Can this be stablised for 1.37?
Another reminder -- can we kick off FCP for stabilization?
any updates?
fcp merge
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.
Code change:
] [[package]] <del> name = "rustc-serialize" version = "0.3.24" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "dcf128d1287d2ea9d80910b5f1120d0b8eede3fbf1abe91c40d39ea7d51e6fda" [[package]] </del> name = "rustc-std-workspace-alloc" version = "1.99.0" dependencies = [

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls 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.
Code change:
<del> // compile-flags: -Zmir-opt-level=4 </del> <ins> // build-pass // compile-flags: -Zmir-opt-level=3 --crate-type=lib </ins> <del> pub fn bar<T>(s: &'static mut ()) </del> <ins> #![feature(trivial_bounds)] #![allow(trivial_bounds)] trait Foo { fn test(self); } fn baz<T>() </ins> where <del> &'static mut (): Clone, //~ ERROR the trait bound </del> <ins> &'static str: Foo, </ins> { <del> <&'static mut () as Clone>::clone(&s); </del> <ins> "Foo".test() </ins> } <del> fn main() {} </del>

Related discussion:
text: <!-- 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. --./src/test/ui/impl- or ./src/test/ui/impl-trait/issues/issue- <!-- 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</detailscc I believe this might be caused by
I'll look into it regardless
I was unable to reproduce same error perhaps it already fixed on stable channel try updating your rust compiler onto stable channel
the nightly that contains suspicious commit has not been released yet, there is no point in trying to reproduce this with nightly (or even stable). You'll need something that contains
This is the same issue that I identified in , but the bug identified and fixed in actually caused it to not be triggered until now. The issue here is a "trivial bound" () causing us to not select but in the MIR inliner. The caching bug actually caused the latter branch to happen everywhere, so when that bug was fixed, we started to normalize to in some places, causing this ICE. I bet I could trigger an ICE with a slight modification to this code using the inliner even with reverted. This is probably only triggered by the inliner, but the MIR inliner isn't enabled without being explicitly provided, right?
Code change:
<del> // compile-flags: -Zmir-opt-level=4 </del> <ins> // build-pass // compile-flags: -Zmir-opt-level=3 --crate-type=lib </ins> <del> pub fn bar<T>(s: &'static mut ()) </del> <ins> #![feature(trivial_bounds)] #![allow(trivial_bounds)] trait Foo { fn test(self); } fn baz<T>() </ins> where <del> &'static mut (): Clone, //~ ERROR the trait bound </del> <ins> &'static str: Foo, </ins> { <del> <&'static mut () as Clone>::clone(&s); </del> <ins> "Foo".test() </ins> } <del> fn main() {} </del>

Related discussion:
text: Trying to emulate trivial bounds via generics & associated types panics on stable, beta and nightly. <!-- 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. --: Reproducible on beta and nightly <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bug is not present in 1.51 and appears in 1.52. More precisely, it appeared somewhere between and .
Seems like introduces the regression Probably is the culprit
It seems to affect only traits that are checked by . Changing to fixes the panic.
I wonder if this could be fixed by normalizing the caller-bounds when checking for trivial bounds in WF. Hmm.... might think about this issue later tonight.
I'm putting up a PR soon to fix a whole bunch of impossible-bounds related things. So I'll claim this for the time being. claim
Code change:
//! Runs rustfmt on the repository. use crate::builder::Builder; <del> use crate::util::{output, t}; </del> <ins> use crate::util::{output, program_out_of_date, t}; </ins> use ignore::WalkBuilder; use std::collections::VecDeque; use std::path::{Path, PathBuf};

Related discussion:
text: Since rustfmt is deterministic and idempotent, running it twice on the same file should always have the same output (if it's not both of those things, it's a bug). So we can avoid running it unless the file has changed, which should make without arguments much faster. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This will need to be careful to still rerun rustfmt when we bump its version (which happens about every 6 weeks). Maybe we can generate a file and format everything if it doesn't yet exist or has the wrong version.
Hello, I want to work on that. How would the detection of modified files work ?
you can use to see modified files. Make sure to fall back to formatting all files if that command fails for some reason, we support building from source tarballs without git installed.
This means that already-commited files that were not formatted when committed would not be formatted, right ?
Ah, good point. You can use to find where the two diverged and compare all files since then. And should still look at all files unconditionally.
Thanks, I will start working on this ! claim
That assumes that the rust-lang remote is labeled as origin. I call that upstream and my fork origin. Using the local master may also not work if one does on branch.
Yes, has a more general solution.
PR is up at
Code change:
Res::Def(DefKind::Ctor(_, CtorKind::Const), def_id) => { let user_provided_types = cx.tables.user_provided_types(); <del> let user_provided_type = user_provided_types.get(expr.hir_id).copied(); debug!("convert_path_expr: user_provided_type={:?}", user_provided_type); </del> <ins> let user_ty = user_provided_types.get(expr.hir_id).copied(); </ins> let ty = cx.tables().node_type(expr.hir_id); match ty.kind { // A unit struct/variant which is used as a value.

Related discussion:
text: The following ICE's on stable, beta and nightly: (notice the was NOT closed) <details<summaryBacktrace:</summary</details
Oh, this works with other types as well, except the messages are different ICE's with:
ICE's with:
Its worth nothing explicitly that: these ICE's are happening after we do issue a diagnostic for the parsing error If you address the parsing error (presumably in the same manner that the parser is auto-correcting to make further progress), the ICE goes away
triage: P-medium. Removing nomination.
Triage: The first example still ICEs in MIR building The second and third examples don't ICE anymore and need tests (without closing this issue!).
cc
Code change:
} } <del> let group = p.read_separator(':', i, |p| p.read_number(16, Some(4))); </del> <ins> let group = p.read_separator(':', i, |p| p.read_number(16, Some(4), true)); </ins> match group { Some(g) => *slot = g,

Related discussion:
text: According to the , "The four octets are in decimal notation, divided by . (this is called 'dot-decimal notation'). Notably, octal numbers and hexadecimal numbers are not allowed per IETF RFC 6943"; however the parsing of the violates the "strict" form mentioned in —this form is what prohibits octal and hexadecimal numbers—meanwhile the conforms to it. IETF RFC 6943 Section 3.1.1. states: If the af argument of inetpton() is AFINET, the src string shall be in the standard IPv4 dotted-decimal form: where "ddd" is a one to three digit decimal number between 0 and The inetpton() function does not accept other formats (such as the octal numbers, hexadecimal numbers, and fewer than four numbers that inetaddr() accepts). As shown above, inetpton() uses what we will refer to as the "strict" form of an IPv4 address literal. Some platforms also use the strict form with getaddrinfo() when the AINUMERICHOST flag is passed to it. I tried this code: I expected to see this happen: both s not causing a panic since the first has an octet represented by more than three base-10 numbers despite the requirement per RFC 6943 stating each octet be a "one to three digit decimal number". The second is valid per RFC 6943 since it is a string of exactly 4 octets separated by where each octet is a "one to three digit decimal number". Instead, this happened: Both lines cause a panic. : : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
I believe that the second input () is not valid, since the spec explicitly says that octal numbers are disallowed, and is an octal number in the loose form. The example in the RFC for an octal number is , which parses to if you use octal, but if you use decimal. If you instead have it parse it always as , that means that bad things can happen, such as different tools interpreting as different things.