jiebi/CodeConvo huggingface dataset:
Change:
/// Basic usage: /// /// ``` <del> /// #![feature(iter_copied)] /// </del> /// let a = [1, 2, 3]; /// /// let v_cloned: Vec<_> = a.iter().copied().collect();

Discussion:
This is a tracking issue for Iterator::copied. Added in . Feature gate: . Related feature: in .
do you feel your comment in is still an objection to the state of this feature, given the response in
So ultimately, was closed meaning that we are comfortable with the specialization. If that specialization is always in place then is a redundant type (and the impls that come with it are also redundant). However, keeping the cost and the type also has less of a risk attached to it so there's a trade-off here. I don't know what the right choice is, but those are the facts as I see them.
Fixed :).
For reference, pattern is quite common according to (%5Cs%5C%7C%5Cs(%3F%3A%26%5Cs%5Cw%2B%5Cs%5C%7C%5Cs%5C%7B%3F%5Cs%5Cw%2B%7C%5Cw%2B%5Cs%5C%7C%5Cs%5C%7B%3F%5Cs%5C%5Cs%5Cw%2B)%5Cs%5C%7D%3F%5Cs*%5C)&insensitive=off&space=off&precise=off&sources=on This includes both Iterators and Options, because a regex match cannot separate those.
Is there anything blocking stabilization here? We'd like to suggest this in Clippy, see (The crux is that is clearer than , but gives off the wrong impression)
That's not my call... =D Picking random libs member... is there anything blocking stabilization here?
Doesn't seem like it. 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.
Change:
use libc; use std::ascii::AsciiExt; use std::ffi::CString; <del> use std::cell::{RefCell, Cell}; </del> <ins> use std::cell::RefCell; </ins> use std::collections::HashMap; use std::fmt; use std::slice;

Discussion:
For example, the code snippet for with suspicious muffin-related content. This seems to be the snippet for the  function (which is also the first function on the page with example code). All other code snippets on the page lead to the same muffin code. This is on Chrome 39.0.2171.95 (64-bit) on Mac OS X 10.10.1. !
It looks like this is caused by rustdoc rendering all of the examples with the same id. If you look at the playpen js code in rustdoc: you see that it depends on all the same ids being different. However, if you look at the source of the StrExt example you linked, you see they all have "rust-example-rendered-0" as the id. I think the error comes from somewhere in here, but it's not obvious to me how to fix it. I'll look into the issue, but this is my first little bit of work on rust so it may take a second/I'd appreciate insight as to what the problem might be.
nominating for I-muffins
Change:
} } <ins> $(#[$meta])* </ins> pub use $symbol::call as $symbol; )*) }

Discussion:
Running yields: This works in July 27 rustc nightly. It's broken in the Oct 6 rustc nightly, but possibly earlier.
It looks like is responsible; presumably the compat_fn! macro doesn't handle the attribute correctly.
I suspect
Verified that the 9/30 nightly works.
Assigning and removing as in the prioritization working group.
Change:
t!(fs::create_dir_all(&sysroot_bin_dir)); builder.cp_link_r(&stage0_bin_dir, &sysroot_bin_dir); <del> // Copy all *.so files from stage0/lib to stage0-sysroot/lib </del> <ins> // Copy all files from stage0/lib to stage0-sysroot/lib </ins> let stage0_lib_dir = builder.out.join(host).join("stage0/lib"); if let Ok(files) = fs::read_dir(stage0_lib_dir) { for file in files { let file = t!(file); let path = file.path(); <del> if path.is_file() && is_dylib(&file.file_name().into_string().unwrap()) { </del> <ins> if path.is_file() { </ins> builder .copy_link(&path, &sysroot.join("lib").join(path.file_name().unwrap())); }

Discussion:
tries to and then expects to find a rustc in that can compile stuff. This appears to have worked, but does not work anymore. only contains the linker script, it does not contain the actual library. I'm not sure how bootstrapping works with that, but uh, it does somehow!
Ah, contains the actual libLLVM.
I don't know whether this is intended or accidental, but something is up. I'm going to change backtrace to use instead, which should hopefully still work.
I worked around it in It's probably the proper fix anyways. Still weird to have this, so I'll leave the issue open for you to figure out whether this is good and whether it matters.
Nevermind, using that doesn't appear to work correctly, I suspect that this does need . I don't really know the difference tbh so I'm happy to know what would be correct.
This is a recent regression from the bootstrap compiler bump PR .
Has anyone figured out what needs to be copied where and how? The conversation seems a bit spread out over different issues/PRs so I'm wondering what the current status is?
Not yet, I will check it around tomorrow.
Thanks! No rush, I was just uncertain where things stood.
Change:
DEPLOY: 1 - CI_JOB_NAME: dist-i686-mingw MSYS_BITS: 32 <del> RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-full-tools </del> <ins> RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-full-tools --enable-profiler </ins> SCRIPT: python x.py dist MINGW_URL: https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror MINGW_ARCHIVE: i686-6.3.0-release-posix-dwarf-rt_v5-rev2.7z

Discussion:
I am trying to see if -Z pgo-gen is available on Windows-Gnu: I am using: I am using a very small Rust test program: If I compile with: rustc -Z pgo-gen It gives me: error: debugging option requires a string (Z pgo-gen=<value) If I compile with (using a random string?): rustc -Z pgo-gen=abc It gives me: error[E0463]: can't find crate for
Hi, I was also struggling with that! :) The is supposed to be the profile file which details are written into after executing the pgo-gen instrumented binary and details are read from when building the binary for the second time with pgo-use. So  might work :)
I've tried to do as you say, but perhaps I am doing something wrong. I've created a binary project with cargo (just the hello world), then I've set the variable: Then I've compiled: It gives me:
Hm, I'm not sure what is going on there now (I also can't reproduce since not a windows user), sorry :/
Using: Calling rustc directly gives:
GNU toolchain is built without profiler:
I wonder if we could just enable the profiler on .
I think I can find time this week to test it. I'm almost sure PGO was broken on some older GCC version but I cannot recall the details.
Status update: I've got it working few days ago but pushing this upstream is blocked on upgrading to 0.1.15. It was meant to be done by but was backed off.
Change:
pub fn recv_from(&self, buf: &mut [u8]) -> io::Result<(usize, SocketAddr)> { let mut storage: c::sockaddr_storage = unsafe { mem::zeroed() }; let mut addrlen = mem::size_of_val(&storage) as c::socklen_t; <ins> let len = cmp::min(buf.len(), <wrlen_t>::max_value() as usize) as wrlen_t; </ins> let n = try!(cvt(unsafe { c::recvfrom(*self.inner.as_inner(), buf.as_mut_ptr() as *mut c_void, <del> buf.len() as wrlen_t, 0, </del> <ins> len, 0, </ins> &mut storage as *mut _ as *mut _, &mut addrlen) })); Ok((n as usize, try!(sockaddr_to_addr(&storage, addrlen as usize)))) } pub fn send_to(&self, buf: &[u8], dst: &SocketAddr) -> io::Result<usize> { <ins> let len = cmp::min(buf.len(), <wrlen_t>::max_value() as usize) as wrlen_t; </ins> let (dstp, dstlen) = dst.into_inner(); let ret = try!(cvt(unsafe { c::sendto(*self.inner.as_inner(), <del> buf.as_ptr() as *const c_void, buf.len() as wrlen_t, </del> <ins> buf.as_ptr() as *const c_void, len, </ins> 0, dstp, dstlen) })); Ok(ret as usize)

Discussion:
In a few places in there are casts from to or for Windows APIs which causes breakage on 64-bit. Some examples I have found so far: () () (rust-lang-nursery/rand, ) There may be more.
Well I didn't find any more so I'll close this.
Change:
RawDoc, } <del> // The goal of this function is to apply the `DocFragment` transformations that are required when // transforming into the final markdown. So the transformations in here are: // // * Applying the computed indent to each lines in each doc fragment (a `DocFragment` can contain //   multiple lines in case of `#[doc = ""]`). // * Adding backlines between `DocFragment`s and adding an extra one if required (stored in the //   `need_backline` field). </del> <ins> /// The goal of this function is to apply the `DocFragment` transformation that is required when /// transforming into the final Markdown, which is applying the computed indent to each line in /// each doc fragment (a `DocFragment` can contain multiple lines in case of `#[doc = ""]`). /// /// Note: remove the trailing newline where appropriate </ins> fn add_doc_fragment(out: &mut String, frag: &DocFragment) { let s = frag.doc.as_str(); <del> let mut iter = s.lines().peekable(); </del> <ins> let mut iter = s.lines(); if s == "" { out.push('n'); return; } </ins> while let Some(line) = iter.next() { if line.chars().any(|c| !c.is_whitespace()) { assert!(line.len() >= frag.indent);

Discussion:
I expected this change to work: But it causes to panic: <details<summaryBacktrace</summary</detailsI don't have time to look into it right now, but I wouldn't expect it to be too hard to fix and it would reduce the memory usage of rustdoc by quite a lot. I'd suggest starting by adding a bunch of assertions that the old and new behavior of is the same and investigating the assertion failures. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Since would unconditionally add a final newline, shouldn't the note say that (instead of "this can") and the 'pop's be unconditional? Across the entire codebase, there's just one other invocation of 'adddocfragment' (currently line 1087 ); it seems that that doesn't need a newline popped. Instead, I think the last function you modified () should only have a newline popped for the last , as would only be false for the last , as far as I can tell. I made a commit to that effect in the PR above, though I have to resolve the merge conflict somehow.
feel free to try that out and see if it works :) like I said, I don't have time to work on it right now.
Change:
<ins> error[E0599]: no method named `foo` found for struct `A` in the current scope --> $DIR/suggest-assoc-fn-call-for-impl-trait.rs:21:8 | LL | struct A { | -------- method `foo` not found for this struct ... LL |     _a.foo(); |     ---^^^-- |     |  | |     |  this is an associated function, not a method |     help: use associated function syntax instead: `A::foo(_a)` | = note: found the following associated functions; to be used as methods, functions must have a `self` parameter note: the candidate is defined in the trait `M` --> $DIR/suggest-assoc-fn-call-for-impl-trait.rs:8:5 | LL |     fn foo(_a: Self); |     ^^^^^^^^^^^^^^^^^ error[E0599]: no method named `baz` found for struct `A` in the current scope --> $DIR/suggest-assoc-fn-call-for-impl-trait.rs:23:8 | LL | struct A { | -------- method `baz` not found for this struct ... LL |     _a.baz(0); |     ---^^^--- |     |  | |     |  this is an associated function, not a method |     help: use associated function syntax instead: `A::baz(0)` | = note: found the following associated functions; to be used as methods, functions must have a `self` parameter note: the candidate is defined in the trait `M` --> $DIR/suggest-assoc-fn-call-for-impl-trait.rs:10:5 | LL |     fn baz(_a: i32); |     ^^^^^^^^^^^^^^^^ error[E0599]: no method named `bar` found for struct `A` in the current scope --> $DIR/suggest-assoc-fn-call-for-impl-trait.rs:27:8 | LL | struct A { | -------- method `bar` not found for this struct ... LL |     _b.bar(); |     ---^^^-- |     |  | |     |  this is an associated function, not a method |     help: use associated function syntax instead: `A::bar(_b)` | = note: found the following associated functions; to be used as methods, functions must have a `self` parameter note: the candidate is defined in the trait `M` --> $DIR/suggest-assoc-fn-call-for-impl-trait.rs:9:5 | LL |     fn bar(_a: Self); |     ^^^^^^^^^^^^^^^^^ error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0599`. </ins>

Discussion:
We had solved case in , could do the same for No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
| = help: the following implementations were found: <i32 as std::convert::From<bool>> <del> <i32 as std::convert::From<core::num::NonZeroI32>> </del> <i32 as std::convert::From<i16>> <i32 as std::convert::From<i8>> <ins> <i32 as std::convert::From<std::num::NonZeroI32>> </ins> and 2 others = note: required by `std::convert::From::from`

Discussion:
The signed variants are not re-exported in here: We should duplicate that line and re-export them. cc -- this will likely slip into 1.34, but we will backport the fix into 1.35
Change:
/// } /// ``` #[inline] <del> #[unstable(feature = "iter_once_with", issue = "57581")] </del> <ins> #[stable(feature = "iter_once_with", since = "1.43.0")] </ins> pub fn once_with<A, F: FnOnce() -> A>(gen: F) -> OnceWith<F> { OnceWith { gen: Some(gen) } }

Discussion:
This is the tracking issue for . Currently in nightly, PR = .
Is this function now ready for stabilization?
I don’t see why not. Tracked here: 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] [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.
I noticed that this iterator has been stabilized a impl which I assume wasn't intentional so I've submitted to remove it.
Change:
let module = self.r.get_module(module_id.to_def_id()).unwrap(); let resolutions = self.r.resolutions(module); <del> for (key, name_resolution) in resolutions.borrow().iter() { </del> <ins> for (_, name_resolution) in resolutions.borrow().iter() { </ins> if let Some(mut binding) = name_resolution.borrow().binding() && !binding.is_ambiguity() { // Set the given binding access level to `AccessLevel::Public` and // sets the rest of the `use` chain to `AccessLevel::Exported` until // we hit the actual exported item. <del> // FIXME: tag and is_public() condition must be deleted, // but assertion fail occurs in import_id_for_ns </del> <ins> // FIXME: tag and is_public() condition should be removed, but assertions occur. </ins> let tag = if binding.is_import() { AccessLevel::Exported } else { AccessLevel::Public }; if binding.vis.is_public() { let mut prev_parent_id = module_id;

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:
--crate-type=rlib  --edition=2018  c.rs 2>&1 | tee $(TMPDIR)/output.txt || exit 0 <del> $(CGREP) E0519 < $(TMPDIR)/output.txt </del> <ins> $(CGREP) E0463 < $(TMPDIR)/output.txt </ins> $(CGREP) -v "internal compiler error" < $(TMPDIR)/output.txt

Discussion:
I decided to try address sanitizer on WSL Ubuntu today, but ran into 2 errors. These errors are only present when using the sanitizer, so my crate compiles normally. To give context there are 2 crates: and . On there is a procedural macro called , which is named the same as my crate which I am re-exporting it to. I don't really know if this a bug or a problem on my end, but I thought I'd mention it just in case. : I included the full error output in a file below
If you use sanitizers you need to pass the flag, but I guess you missed it. See also :
Oh I did miss it and that fixed it. The documentation made it sound optional though, so I didn't realize that was the issue. Thanks for the quick reply!
Re-opening because the error is very confusing. See also
On the error is: which isn't great, but at least suggests some issue related to asan. On the error is: Which is very confusing. was merged between those two versions and changes in which cases E0519 is emitted. ping who wrote that PR.
Change:
"cstr", "libc", "libloading", <del> "measureme 10.0.0", </del> <ins> "measureme", </ins> "rustc-demangle", "rustc_ast", "rustc_attr",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Probably a missing join (these tests are a bit random, now that we have preemption).
Change:
}) } <ins> /// Parse a string, return a view item pub fn string_to_view_item (source_str : String) -> ast::ViewItem { with_error_checking_parse(source_str, |p| { p.parse_view_item(Vec::new()) }) } </ins> /// Parse a string, return a pat. Uses "irrefutable"... which doesn't /// (currently) affect parsing. pub fn string_to_pat(source_str: String) -> P<ast::Pat> {

Discussion:
method will unconditionally fail if it encounters a view item ( or ). This is desired behavior if parsing the body of a function. However, there are no public methods that allow parsing either of these items individually. This makes it impossible to parse the full range of possible input to a REPL. If it's acceptable, I could make a pull request for public methods (which already exists, privately) and .
Change:
LL | fn foo(x: impl Fn(<S as T<'_>>::A) -> <S as T<'_>>::A) {} |                                       ^^^^^^^^^^^^^^^ | <del> = note: lifetimes appearing in an associated type are not considered constrained </del> <ins> = note: lifetimes appearing in an associated or opaque type are not considered constrained = note: consider introducing a named lifetime parameter </ins> error: aborting due to previous error

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. --. Prior to , these types were rejected with this error: Currently, they're accepted. Based on the assumption that generic parameters on opaque type are not constrained (see Niko's comment ), I believe the previous behavior is correct. CC: label F-typealiasimpl_trait A-impl-trait T-compiler A-lifetimes
Out of curiosity, here's an exploit derived from . It type-checks but fails at monomorphization.
The above exploit is and should be easier to do with , where indirection through would not be necessary, so label I-unsound requires-nightly T-types
if the same code were written without lifetime params and used arguments instead, we'd see the same problem before , right?
Sorry, I've clearly missed the notification :sweat_smile:. I think you already know the answer given that you've just pushed a fix :).
Change:
) -> impl Iterator<Item = (DefId, DefId)> + '_ { self.get_crate_data(cnum).get_inherent_impls() } <ins> /// Decodes all lang items in the crate (for rustdoc). pub fn lang_items_untracked(&self, cnum: CrateNum) -> impl Iterator<Item = DefId> + '_ { self.get_crate_data(cnum).get_lang_items().map(|(def_id, _)| def_id) } </ins> } impl CrateStore for CStore {

Discussion:
(Using + ) (Minimized from ) : <details<summary<strongBacktrace</strong</summary<p</p</detailscc
One thing I forgot to do is check that my minimization is exhaustive. After deleting all the from the original crate it still ICEs, so there must be another way that it is triggering this too.
Could this issue be related/duplicate of (and therefore fixed by )? Also, perhaps replace the team label with ?
I assume you meant ? That was included in which I tested with (we have a collection of failing crates in that I am rebuilding as each fix for the fallout from lands).
Fixed in
Change:
<ins> error[E0616]: field `len` of struct `Foo` is private --> $DIR/private-field-ty-err.rs:3:10 | LL |     if x.len { |          ^^^ private field | help: a method `len` also exists, call it with parentheses | LL |     if x.len() { |             ++ error: aborting due to previous error For more information about this error, try `rustc --explain E0616`. </ins>

Discussion:
The code below yields two errors: field is private error in if expression because type is instead of This means a user can observe the type of a private field of a dependency in their error messages. It doesn't mean they can actually use that information, but it seems weird at least. Is this actually an issue? If you don't consider it one, feel free to close this. - - (originally seen )
I won't close the ticket as this deserves a conversation to be had, but I personally don't consider it to be a big problem. Parsing x.len as when we suggest that would be nice, but in this case it would lead to confusing errors if we don't annotate the compiler state with something along the lines of
Hi Do any of you have opinions on this matter? I lean towards closing as "wontfix" because I feel the current behavior is acceptable.
I agree, like you mentioned , there are some improvements we could make, but I think the current behaviour is fine.