jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: `use<...>` precise capturing syntax is currently not allowed in return-position `impl Trait` in traits --> $DIR/rpitit-captures-more-method-lifetimes.rs:6:53 | LL |     fn bar<'tr: 'tr>(&'tr mut self) -> impl Sized + use<Self>; |                                                     ^^^^^^^^^ | = note: currently, return-position `impl Trait` in traits and trait implementations capture all lifetimes in scope error: return type captures more lifetimes than trait definition --> $DIR/rpitit-captures-more-method-lifetimes.rs:11:40 | LL |     fn bar<'im: 'im>(&'im mut self) -> impl Sized + 'im {} |            ---                         ^^^^^^^^^^^^^^^^ |            | |            this lifetime was captured | note: hidden type must only reference lifetimes captured by this impl trait --> $DIR/rpitit-captures-more-method-lifetimes.rs:6:40 | LL |     fn bar<'tr: 'tr>(&'tr mut self) -> impl Sized + use<Self>; |                                        ^^^^^^^^^^^^^^^^^^^^^^ = note: hidden type inferred to be `impl Sized + 'im` warning: impl trait in impl method signature does not match trait method signature --> $DIR/rpitit-captures-more-method-lifetimes.rs:11:40 | LL |     fn bar<'tr: 'tr>(&'tr mut self) -> impl Sized + use<Self>; |                                        ---------------------- return type from trait method defined here ... LL |     fn bar<'im: 'im>(&'im mut self) -> impl Sized + 'im {} |                                        ^^^^^^^^^^^^^^^^ | = note: add `#[allow(refining_impl_trait)]` if it is intended for this to be part of the public API of this crate = note: we are soliciting feedback, see issue #121718 <https://github.com/rust-lang/rust/issues/121718> for more information = note: `#[warn(refining_impl_trait_reachable)]` on by default help: replace the return type so that it matches the trait | LL |     fn bar<'im: 'im>(&'im mut self) -> impl Sized {} |                                        ~~~~~~~~~~ error: aborting due to 2 previous errors; 1 warning emitted </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: expected lifetime parameter, but found another generic parameter', 'error: internal compiler error: expected lifetime parameter, but found another generic parameter' 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: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of --
cc
Change:
| LL |     unsafe { match static_cross_crate::OPT_ZERO { Some(ref u) => u, None => panic!() } } |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <ins> help: skipping check that does not even have a feature gate --> $DIR/const_refers_to_static_cross_crate.rs:32:20 | LL |     unsafe { match static_cross_crate::OPT_ZERO { Some(ref u) => u, None => panic!() } } |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </ins> help: skipping check for `const_panic` feature --> $DIR/const_refers_to_static_cross_crate.rs:32:77 |

Discussion:
The code below compiles as of 1.46, but I'm not sure it should, since it dereferences a raw pointer in a const block, which is only allowed in nightly with the flag:
modify labels to +A-raw-pointers +A-const-fn
cc
Ah, that looks like the const version of the old "uninhabited match" problem... The MIR for is So somehow the deref already vanished, and hence the const analysis cannot catch it. But doesn't unsafety checking also happen on the MIR? Why does that work?
It seems that whenever the dereference is not bound to a variable, it compiles, but whenever bound to a variable, it fails to compile:
I don't believe this is an unsoundness. Unsafe code is required to cause anything here. That's the final MIR, since without this will fail to compile, it must be there for unsafety checking, thus it must also be there for const checking. Not sure why we fail to catch this.
Agreed. This is a case of "oops a nightly-only feature is available on stable", which is bad, but it is not an unsoundness.
Assigning and removing as in the prioritization working group.
The initial MIR looks like this: So probably the issue is that const-checking ignores ?
oh... yea.. we ignored it on purpose... "because it doesn't actually do anything" :upsidedownface: I guess we should visit all places within statements that we otherwise ignore during const-checking?
Well, at least we need to visit . ;)
Do we really? The check is done in , which should be called even for the projection in the place in the fake read.
Oh wait, we don't call unconditionally! That seems like... a problem.^^
Proposed a fix:
Change:
run.builder.ensure(RunMakeSupport { compiler, target: run.build_triple() }); } <ins> /// Builds run-make-support and returns the path to the resulting rlib. </ins> fn run(self, builder: &Builder<'_>) -> PathBuf { builder.ensure(compile::Std::new(self.compiler, self.target));

Discussion:
The library is currently not registered/configured in bootstrap to be able to run its unit tests via . See for an example on how compiletest unit tests are ran. I plan to get to this eventually (busy ATM), but if someone wants to try implementing this feel free to claim it. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Thanks, I'm doing this. claim
Change:
_ => self.cache.stripped_mod, }; <ins> #[inline] fn is_from_private_dep(tcx: TyCtxt<'_>, cache: &Cache, def_id: DefId) -> bool { let krate = def_id.krate; cache.masked_crates.contains(&krate) || tcx.is_private_dep(krate) } </ins> // If the impl is from a masked crate or references something from a // masked crate then remove it completely. if let clean::ImplItem(ref i) = *item.kind && (self.cache.masked_crates.contains(&item.item_id.krate()) || i.trait_ .as_ref() <del> .map_or(false, |t| self.cache.masked_crates.contains(&t.def_id().krate)) </del> <ins> .map_or(false, |t| is_from_private_dep(self.tcx, self.cache, t.def_id())) </ins> || i.for_ .def_id(self.cache) <del> .map_or(false, |d| self.cache.masked_crates.contains(&d.krate))) </del> <ins> .map_or(false, |d| is_from_private_dep(self.tcx, self.cache, d))) </ins> { return None; }

Discussion:
I was checking if exposed  and found these seemingly non existent methods
It looks like the search results are present on (and after), but not on (or before)
Seems that's when std's hashbrown was upgraded to that the trait -
Change:
cmd_str.push(0); // add null terminator // stolen from the libuv code. <del> let mut flags = c::CREATE_UNICODE_ENVIRONMENT; </del> <ins> let mut flags = self.flags | c::CREATE_UNICODE_ENVIRONMENT; </ins> if self.detach { flags |= c::DETACHED_PROCESS | c::CREATE_NEW_PROCESS_GROUP; }

Discussion:
Now a tracking issue for on Windows. Open questions: Should we provide a method of adding* flags as opposed to setting them entirely? Would be a bit more composition-friendly. Also, don't forget to add to the prelude when stabilizing! There's a currently-unused codepath in the Windows implementation of that can set : It looks like historically there was a method to set this but it got removed. Unfortunately there's currently no way to set this, and no other way to set the flags, so for a project I'm working on I basically had to reimplement for Windows: I think we need some way to set this, even if it's Windows-specific. There are a bunch of other flags that can be specified, so maybe a way to set arbitrary flags would be useful? (v=vs.85).aspx I think this would fit nicely onto a Windows equivalent of the  trait, maybe something like:
Seems reasonable to me!
I'm always in favor of adding more Windows specific extension traits to expose useful functionality that other platforms don't seem to have.
I have a patch, it just took me a while to write a test for it. I'm trying to sort out the stability annotations for the new APIs--can I just use this issue as the tracking issue for the new feature?
Sure!
To the open question: I had first written the API as originally proposed: with a method to set the flags directly. Then I thought that might make it difficult if callers wanted to set different flags in different places, so I split it into and methods, but Alex asked me to change it back. I'm not sure it's that important, I don't think there are that many process creation flags that it would be useful to set from a library context, and callers can always aggregate flags into a u32 and just call with that value.
fcp merge With the one remaining open question I think it's safe to stabilize as this is still consistent with our approach to custom flags in other areas of platform-specific extensions as well.
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, 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: psst I wasn't able to add the label, please do so.
Change:
checksum = "d5477fe2230a79769d8dc68e0eabf5437907c0457a5614a9e8dddb67f65eb65d" dependencies = [ "equivalent", <del> "hashbrown 0.14.0", </del> <ins> "hashbrown 0.14.2", </ins> "rustc-rayon", "serde", ]

Discussion:
I tried this code: I expected to see this happen: map = {1: "a"} Instead, error happened: Sometimes it causes Segmentation fault: <!-- 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<summaryBacktrace</summary<p</p</details
Miri reports UB with the target in question: (sorry for reflexively blaming LLVM, it didn't deserve that)
The root cause is that the stdarch SIMD intrinsics are broken on big-endian targets. For now I've disabled the use of NEON in hashbrown on big-endian ARM: We should probably disable/de-stabilize the NEON intrinsics on big-endian targets. They are currently all producing incorrect results.
All of them, or specifically for ARM? (Not sure if we have stdarch support for any other big-endian target.) Is there an issue tracking that and explaining in a bit more detail how they are broken?
This only applies to arm & aarch64 targets. Here is the issue in stdarch:
Miri doesn't support the NEON SIMD intrinsics though. So if Miri reports UB then it seems there are other problems as well?
Some are implemented using the same intrinsics as portable-simd.
It's a combination of a few things: We are missing a check for the NEON implementation. All the NEON intrinsics we happen to use in hashbrown are implemented without LLVM builtins.
Ah so I guess what happens is that Miri correctly implements the portable SIMD intrinsics, but stdarch implements the NEON intrinsics on top of them and it's doing that incorrectly? Miri and codegen/LLVM are fine?
Yes, that's my understanding.
Change:
use os::windows::io::{FromRawHandle, RawHandle, AsRawHandle, IntoRawHandle}; use process; use sys; <del> use sys_common::{AsInner, FromInner, IntoInner}; </del> <ins> use sys_common::{AsInnerMut, AsInner, FromInner, IntoInner}; </ins> #[stable(feature = "process_extensions", since = "1.2.0")] impl FromRawHandle for process::Stdio {

Discussion:
Now a tracking issue for on Windows. Open questions: Should we provide a method of adding* flags as opposed to setting them entirely? Would be a bit more composition-friendly. Also, don't forget to add to the prelude when stabilizing! There's a currently-unused codepath in the Windows implementation of that can set : It looks like historically there was a method to set this but it got removed. Unfortunately there's currently no way to set this, and no other way to set the flags, so for a project I'm working on I basically had to reimplement for Windows: I think we need some way to set this, even if it's Windows-specific. There are a bunch of other flags that can be specified, so maybe a way to set arbitrary flags would be useful? (v=vs.85).aspx I think this would fit nicely onto a Windows equivalent of the  trait, maybe something like:
Seems reasonable to me!
I'm always in favor of adding more Windows specific extension traits to expose useful functionality that other platforms don't seem to have.
I have a patch, it just took me a while to write a test for it. I'm trying to sort out the stability annotations for the new APIs--can I just use this issue as the tracking issue for the new feature?
Sure!
To the open question: I had first written the API as originally proposed: with a method to set the flags directly. Then I thought that might make it difficult if callers wanted to set different flags in different places, so I split it into and methods, but Alex asked me to change it back. I'm not sure it's that important, I don't think there are that many process creation flags that it would be useful to set from a library context, and callers can always aggregate flags into a u32 and just call with that value.
fcp merge With the one remaining open question I think it's safe to stabilize as this is still consistent with our approach to custom flags in other areas of platform-specific extensions as well.
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, 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: psst I wasn't able to add the label, please do so.
Change:
/// hello x: u32, }, <ins> BazVariant( String, /// dox u32, ), OtherVariant( /// dox String, u32, ), QuuxVariant(String), </ins> }

Discussion:
I understand that if (at least one of) a tuple variant's fields is documented, we need a place to put that documentation. But if not this just adds superfluous noise. Especially if you have a lot of tuple enum variants with undocumented fields it becomes very noisy very quickly. As a real world example from one of my codebases: How it currently looks: ! And with the superfluous sections removed: ! I think we should get rid of any "Tuple Fields of Variant" section if that variants' fields are undocumented. It only adds noise and makes the documentation less readable in my opinion.
I wonder if instead we should just unconditionally get rid of the tuple fields in the header? Then it'd be consistent with struct fields. On the other hand, the header view is a bit easier to read in some ways since it matches source view. cc What do you think?
To clarify, you mean the heading of each variant, right? So e.g. SizeLimit(usize) would become SizeLimit, with a heading below that saying "Tuple Fields", and text below that saying ? I prefer an approach where we keep as the heading, and say "if none of the tuple fields has a doccomment (the common case), we don't show the "Tuple Fields" section (as suggested in the top comment). Perhaps we should even deprecate comments on individual tuple fields? It seems quite uncommon to use, and rather awkward.
I agree with proposition.
Yep, in general I think if the fields need documentation people will generally be using struct-variants instead, so optimizing for doc-less tuple-variants makes sense.
I disagree; we'd basically be removing expected behavior. I don't think we should force people to refactor their code just to add documentation. But optimizing for doc-less tuple variants (rather than enforcing it) seems potentially reasonable.
Thanks to I realized I misunderstood comment. So let me update my comment: I agree with this. I agree with this as well. I don't agree with this. Hopefully I didn't miss something else...
To clarify, you mean the heading of each variant, right? So e.g. SizeLimit(usize) would become SizeLimit, with a heading below that saying "Tuple Fields", and text below that saying 0: usize? I don't understand; you agree with both?

The two approaches are mutually exclusive IIUC.
I don't have a preference is what I tried to say haha.
Since there's a PR up, I wanted to tidy up this issue thread. There was some confusion and back and forth above, but reading through it it seems like everyone who has chimed in either agrees with the original post's approach or doesn't have a preference. Since the PR () implements that approach, we're good.
I still think it's not great that now tuple fields and struct fields will be handled differently, but this seems like a good enough solution for now.
Change:
use syntax::ext::base::{ExtCtxt, MacResult, MacExpr, DummyResult}; use syntax::parse::token; use syntax::print::pprust; <ins> use syntax::fold::Folder; </ins> use rustc::plugin::Registry;

Discussion:
I believe this should output the string : But I get this error: Rust version:
Note that standard recursive macros work fine, e.g., And outputs . Maybe the bug here is that expanding macros within other macros is using an older environment that doesn't include the name ?
It's even worse than that. only uses the compiler built-in macros:
I think this might be a dupe of
Does fixing mean that also gets fixed? I wouldn't assume so, but it might be possible depending on the implementation. (Sorry I missed that issue. I searched for 'recursive macro' instead of 'nested macro'!)
both and use , which doesn't work with non-builtin macros.
Right. I'm referring to the recursive aspect. Wasn't sure if that would make a difference. (I just don't know enough about how macros are expanded to know. Pure guesswork on my part.)
Change:
let encl_body = self.tcx.hir().body(encl_body_id); err.encl_body_span = Some(encl_body.value.span); <del> err.encl_fn_span = Some(encl_item.span); </del> <ins> err.encl_fn_span = Some(*encl_fn_span); </ins> } self.tcx.sess.emit_err(err);

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
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
This is a regression considering it doesn't happen in beta.
Change:
if (search_input.value !== "" && hasClass(search, "hidden")) { showSearchResults(search); if (browserSupportsHistoryApi()) { <del> history.replaceState(search_input.value, "", "?search=" + encodeURIComponent(search_input.value)); </del> <ins> var extra = "?search=" + encodeURIComponent(search_input.value); history.replaceState(search_input.value, "", getNakedUrl() + extra + window.location.hash); </ins> } document.title = searchTitle; }

Discussion:
mdbook v4.6+ has a feature that pressing ESC removes query components from URLs (for example ). The feature was implemented in rust-lang/mdBook. It would be nice if rustdoc offers the same kind of that feature. This is, for example, an URL that contains query components in rustdoc: When users share URLs to an API, they don't have to remove the query manually.
could you share some thoughts about this feature request? If possible, could you mentor contributors how to implement this ?
I think it's a good idea. Gonna take a look at how to do it.
Can we reopen this issue ? I think only removes the query component when we remove keywords in search bar. This issue is about adding a keyboard shortcut.
Oh I see, my bad. Reopening!
Change:
return values; } <del> // We couldn't find anything in common, highlight everything. //     let x: Bar<Qux> = y::<Foo<Zar>>(); ( DiagnosticStyledString::highlighted(t1.to_string()), DiagnosticStyledString::highlighted(t2.to_string()), ) </del> <ins> // We can't find anything in common, highlight relevant part of type path. //     let x: foo::bar::Baz<Qux> = y:<foo::bar::Bar<Zar>>(); //     foo::bar::Baz<Qux> //     foo::bar::Bar<Zar> //               -------- this part of the path is different let t1_str = t1.to_string(); let t2_str = t2.to_string(); let min_len = t1_str.len().min(t2_str.len()); const SEPARATOR: &str = "::"; let separator_len = SEPARATOR.len(); let split_idx: usize = t1_str.split(SEPARATOR) .zip(t2_str.split(SEPARATOR)) .take_while(|(mod1_str, mod2_str)| mod1_str == mod2_str) .map(|(mod_str, _)| mod_str.len() + separator_len) .sum(); debug!("cmp: separator_len={}, split_idx={}, min_len={}", separator_len, split_idx, min_len ); if split_idx >= min_len { // paths are identical, highlight everything ( DiagnosticStyledString::highlighted(t1_str), DiagnosticStyledString::highlighted(t2_str) ) } else { let (common, uniq1) = t1_str.split_at(split_idx); let (_, uniq2) = t2_str.split_at(split_idx); debug!("cmp: common={}, uniq1={}, uniq2={}", common, uniq1, uniq2); values.0.push_normal(common); values.0.push_highlighted(uniq1); values.1.push_normal(common); values.1.push_highlighted(uniq2); values } </ins> } }

Discussion:
On E0308 type mismatch errors we already perform a basic check to type arguments in order to only highlight differences between the expected and found type. I recently came across a case where the two types had identifiers of the same length with no type arguments, but that were not local so the path was quite long. It took me some time to realize that the two types were actually different and not caused by different crate versions. It'd be nice if for the following, only the parts of the path that differ were highlighted/bolded in the CLI output: CC
Hello, I'd like to implement this feature.
Hi Will you be needing a hand? To begin with, I would recommend searching for in order to find how it works today. Particularly, shows how the highlighting for specific type arguments is currently handled. It is extremely verbose, but the comments should help somewhat. Also, the is a good primer on how to develop in the compiler's codebase. If you need a hand, don't hesitate to reach out.
Thanks, I'd found that struct and file, but I'd overlooked that method due to how complicated it seemed at a glance.
Should I add a test for this? If so, how would I implement that? The standard UI testing method doesn't seem to track highlights.
sadly, we do not have any way to test correct application of colors in the test suite. Attach screenshots to the PR so that we can see the changes, but we have to rely on being extra careful when touching this part of the codebase.
Change:
self.ident(start) } rustc_lexer::TokenKind::InvalidIdent <ins> | rustc_lexer::TokenKind::InvalidPrefix </ins> // Do not recover an identifier with emoji if the codepoint is a confusable // with a recoverable substitution token, like `➖`. if !UNICODE_ARRAY

Discussion:
In the 2015 and 2018 editions, the following compiles (with warnings): ` [playground] The is taken as an identifier, although emoji aren't generally permitted in identifiers in any edition. I tested with 1.77.1. I think the underlying problem is that and in distinguish "identifiers" containing emoji (as rather than ), but don't have a way to make that distinction for . [playground]:
Regression from 1.57 to 1.58 (stable to stable). Very likely in , cc Regression from error to pass. Previous error: .
WG-prioritization assigning priority (). label -I-prioritize +P-low
thank you for the detailed report. will fix this.