jiebi/CodeConvo huggingface dataset:
Change:
} // see if we can satisfy using an inherent associated type <del> for impl_ in tcx.inherent_impls(adt_def.did()) { let assoc_ty = tcx.associated_items(impl_).find_by_name_and_kind( tcx, assoc_ident, ty::AssocKind::Type, *impl_, ); if let Some(assoc_ty) = assoc_ty { let ty = tcx.type_of(assoc_ty.def_id); return Ok((ty, DefKind::AssocTy, assoc_ty.def_id)); } </del> <ins> for &impl_ in tcx.inherent_impls(adt_def.did()) { let Some(assoc_ty_did) = self.lookup_assoc_ty(assoc_ident, hir_ref_id, span, impl_) else { continue; }; // FIXME(inherent_associated_types): This does not substitute parameters. let ty = tcx.type_of(assoc_ty_did); return Ok((ty, DefKind::AssocTy, assoc_ty_did)); </ins> } }

Discussion:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
// definition... // We don't allow argument names to be left off in edition 2018. <del> p.parse_arg_general(p.span.rust_2018()) </del> <ins> p.parse_arg_general(p.span.rust_2018(), true) </ins> })?; generics.where_clause = self.parse_where_clause()?;

Discussion:
This code works correctly on nightly and stable but not on 2018 edition, where it returns the error Changing it to solves it. Is this an intended change? I couldn't find anything about it in the edition guide.
Yes, this was done in
So apparently it was part of . In that case we should at least fix the error message, since it doesn't explain the source of the error at all.
Change:
let adt_def = self.tcx.adt_def(def_id); assert!(adt_def.is_union()); assert_eq!(idx, FIRST_VARIANT); <del> let dest = adt_def.non_enum_variant().fields[field].ty(self.tcx, args); if fields.len() != 1 { </del> <ins> let dest_ty = self.tcx.normalize_erasing_regions( self.param_env, adt_def.non_enum_variant().fields[field].ty(self.tcx, args), ); if fields.len() == 1 { let src_ty = fields.raw[0].ty(self.body, self.tcx); if !self.mir_assign_valid_types(src_ty, dest_ty) { self.fail(location, "union field has the wrong type"); } } else { </ins> self.fail(location, "unions should have one initialized field"); } <del> if !self.mir_assign_valid_types(fields.raw[0].ty(self.body, self.tcx), dest) { self.fail(location, "union field has the wrong type"); } </del> } AggregateKind::Adt(def_id, idx, args, _, None) => { let adt_def = self.tcx.adt_def(def_id);

Discussion:
<!-- [31mICE[0m: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
&lt;!-- [31mICE[0m: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' 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: [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
This ices since by but I dont see any of the error messages which is weird
ICE happens before any of those error messages would be fired. I'll fix it later.
Change:
/// /// assert_eq!(*c.borrow(), vec![1, 4, 3]); /// ``` <del> #[unstable(feature = "cell_filter_map", reason = "recently added", issue = "81061")] </del> <ins> #[stable(feature = "cell_filter_map", since = "1.63.0")] </ins> #[inline] pub fn filter_map<U: ?Sized, F>(mut orig: RefMut<'b, T>, f: F) -> Result<RefMut<'b, U>, Self> where

Discussion:
Feature gate: This is a tracking issue for and , which lets you optionally project data inside a or , wrapped in a or . If the projection returns then these methods return a so that you can still get the original or back out. [x] Implementation: [x] Final commenting period (FCP) [ ] Stabilization PRNaming and signature: We wanted to call this method and accept a closure like , but that's not sound with bound lifetimes. This method is only ok when the mapping closure uses HRTB. So we opted to call it instead, with the closure returning a .
I am in need of this API for my library in order to be able to have an efficient implementation that avoids unsafe Rust code. I wonder, why is the goal to have instead of since I can see a great value in having both APIs available. So if is already good to go we could stabilize that one and later add as soon as all open questions for it are resolved.
The name seems unusual for something that returns a - for example, returns an iterator with filtering built in. The equivalent method already exists in the Mutex implementations of , under the name . In both cases the closure it accepts returns and not the more general . So maybe the name should be reconsidered in that light.
I'm also interested in the stabilization of this API for the same reason as However, I also agree that should be named since it returns a . As an API user it makes more sense to me.
I wonder if we can have a generic filter & map for any inner enum instead of just Option. For example in this code As the code show, ref is compared twice to get the result. Is there any way to make it simpler?
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] 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. This will be merged soon.
Change:
autoCollapse(getPageId(), getCurrentValue("rustdoc-collapse") === "true"); if (window.location.hash && window.location.hash.length > 0) { <del> var hash = getPageId(); if (hash !== null) { var elem = document.getElementById(hash); if (elem && elem.offsetParent === null) { if (elem.parentNode && elem.parentNode.previousSibling) { var collapses = elem.parentNode .previousSibling .getElementsByClassName("collapse-toggle"); if (collapses.length > 0) { // The element is not visible, we need to make it appear! collapseDocs(collapses[0], "show"); } } } } </del> <ins> expandSection(window.location.hash.replace(/^#/, '')); </ins> } }());

Discussion:
Stable documentation (e.g. ): Click on to collapse everything Click on in Page will be scrolled to the . Nightly documentation (e.g. ): Click on to collapse everything Click on in Nothing will happen, because the is inside a collapsed outer section.
Another example: Click the word in the description on the page Nothing happens, making it appear that the link is broken. Since trait impls are collapsed by default, AFAIK there is no way to properly link to them. I'm guessing this would need to be implemented in and , and check if the block is hidden?
Change:
for &(ref lint_name, level) in &sess.opts.lint_opts { store.check_lint_name_cmdline(sess, &lint_name, level); <ins> let orig_level = level; </ins> // If the cap is less than this specified level, e.g., if we've got // `--cap-lints allow` but we've also got `-D foo` then we ignore

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. --Simply building the rusty-xinput crate in the dependency chain seems to have triggered it. See <!-- 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. --Rust version from the build <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pI'm sorry - I don't have access to a windows environment to reproduce this! </p</details
I think is the cause, cc Note that you should set to reproduce it. I don't feel this is Windows-specific but it just depends on the Windows-specific crate, marking . <details<summary<strongBacktrace</strong</summary</details
MCVE: run on:
Assigning and removing .
I got the same error on Linux while compiling lazy_static. https://cirrus- .
This will be fixed by
Change:
<ins> error: this file contains an unclosed delimiter --> $DIR/issue-91334.rs:10:23 | LL | fn f(){||yield(((){), |       -       -       ^ |       |       | |       |       unclosed delimiter |       unclosed delimiter error: this file contains an unclosed delimiter --> $DIR/issue-91334.rs:10:23 | LL | fn f(){||yield(((){), |       -       -       ^ |       |       | |       |       unclosed delimiter |       unclosed delimiter error: expected one of `)`, `,`, `.`, `?`, or an operator, found `{` --> $DIR/issue-91334.rs:10:19 | LL | fn f(){||yield(((){), |                   ^ |                   | |                   expected one of `)`, `,`, `.`, `?`, or an operator |                   help: missing `,` error: mismatched closing delimiter: `)` --> $DIR/issue-91334.rs:10:19 | LL | fn f(){||yield(((){), |                -  ^^ mismatched closing delimiter |                |  | |                |  unclosed delimiter |                closing delimiter possibly meant for this error[E0308]: mismatched types --> $DIR/issue-91334.rs:10:8 | LL | fn f(){||yield(((){), |       -^^^^^^^^^^^^^^^ expected `()`, found generator |       | |       help: try adding a return type: `-> [generator@$DIR/issue-91334.rs:10:8: 10:23]` | = note: expected unit type `()` found generator `[generator@$DIR/issue-91334.rs:10:8: 10:23]` error: aborting due to 5 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
This debugassert: Is triggered by the following input, found by : <details<summary<strongBacktrace</strong</summary<p</p</details
Reduced (in terms of unrelated errors):
label +requires-nightly +A-generators +F-generators
Change:
bool PositionIndependentExecutable, bool FunctionSections, bool DataSections, bool TrapUnreachable, <del> bool Singlethread) { </del> <ins> bool Singlethread, bool AsmComments) { </ins> auto OptLevel = fromRust(RustOptLevel); auto RM = fromRust(RustReloc);

Discussion:
clang -S produces nicely commented .s files. It would be nice if rustc did this too. e.g. simd shuffles are commented .loc directives have the corresponding line number comment .loc 1 4 25 isstmt 1 ## test.c:4:25 debug information is commented .byte 14 ## DWFORMstrp .byte 17 ## DWATlowpc .byte 1 ## DWFORMaddr .byte 18 ## DWAThighpc .byte 1 ## DWFORM_addr
There might be a or flag already for this. AFAIK what clang emits comes from LLVM.
This flag is already , should be usable (issue can be closed?):
Any reason not to make this the default?
Likely the fact that it may change the behavior (I don't actually know what that means but this seems like a valid assumption).
it looks like -Z asm-comments doesn't do this. MCOptions.AsmVerbose must be set to true for the assembler to emit them.
So it looks like -Zasm-comments isn't actually used anywhere based on what I can find in the source... or, rather, its uses are in methods that are themselves never called.
Yeah, to get comments I believe I needed to set a verbose flag in some llvm context. Clang does this by default and it would be nice if rustc did too.
IIUC without this neither the playground nor godbolt (compiler-explorer) can map assembly to lines of Rust source code.
Godbolt uses debug info AFAIK? Our debug info isn't always great but in general it's working, isn't it?
It seems like they just don't do it much. Godbolt uses directives in the assembly file, which rustc seems to generate correctly, sorry for the noise.
Change:
TerminatorKind::Unreachable => { } TerminatorKind::Return => { <del> self.gather_move(&Lvalue::Local(RETURN_POINTER)); </del> <ins> self.gather_move(&Lvalue::Local(RETURN_POINTER), false); </ins> } TerminatorKind::Assert { .. } |

Discussion:
MIR borrowck considers variables still initialized after their storage ends, so if an immutable variable is defined and used in a loop, this causes an error. e.g.: Which causes:
working on it
Change:
&mut |res, file, line| { match res { Ok((name, f)) => { <del> let mut err = |msg: &str| { tidy_error!(bad, "{}:{}: {}", file.display(), line, msg); }; if lang_features.contains_key(name) && name != "proc_macro" { err("duplicating a lang feature"); } if let Some(ref s) = lib_features.get(name) { if s.level != f.level { err("different stability level than before"); } if s.since != f.since { err("different `since` than before"); </del> <ins> let mut check_features = |f: &Feature, list: &Features, display: &str| { if let Some(ref s) = list.get(name) { if let Err(m) = (&f).check_match(s) { tidy_error!(bad, "{}:{}: mismatches to {} in: {:?}", file.display(), line, display, &m); } </ins> } <del> if s.tracking_issue != f.tracking_issue { err("different `tracking_issue` than before"); } } </del> <ins> }; check_features(&f, &lang_features, "corresponding lang feature"); check_features(&f, &lib_features, "previous"); </ins> lib_features.insert(name.to_owned(), f); }, Err(msg) => {

Discussion:
Currently, there in tidy that ensures that there is no library feature and language feature of the same name. Its presence in the documentation above. This check since , and has caused multiple additions that have both library and language components to be split up: / / / PR has challenged the status quo, by reusing the lang feature inside libraries provided to programs. It actually to the tidy check in order to get it passing. There has been about this in the thread of and the resolution was to allow to share the feature gate. So my question is: which purpose does this check serve? should the check be present, or should it be abolished? Should the feature gate be split up into a library component and a lang component?
IMO we should just kill the tidy check. For inclusive ranges we are stabilizing the lib and syntax separately, but if they had been under the same gate it would have been easy to split them up, like we are doing for const fn.
I too think we should lump things that are "the same underlying concept" under one feature gate.
Looks like the original code allowed for a 'joint features' whitelist, so it seems like it might have just been a sanity check that any intersection was intentional. Indeed, that script actually says that it's for doing some sanity checks. If for some reason that sanity check is still desirable, at minimum I'd be +1 to creating a whitelist rather than ad-hoc growing the if condition.
We can guard from that by doing a check for any joint features whether the tracking issue and stability status (stable or unstable) matches between lib and lang features.
Change:
let data: ExpnData = decoder .with_position(pos.to_usize(), |decoder| decode_tagged(decoder, TAG_EXPN_DATA))?; <del> rustc_span::hygiene::register_local_expn_id(data, hash) </del> <ins> let expn_id = rustc_span::hygiene::register_local_expn_id(data, hash); #[cfg(debug_assertions)] { use rustc_data_structures::stable_hasher::{HashStable, StableHasher}; let mut hcx = decoder.tcx.create_stable_hashing_context(); let mut hasher = StableHasher::new(); hcx.while_hashing_spans(true, |hcx| { expn_id.expn_data().hash_stable(hcx, &mut hasher) }); let local_hash: u64 = hasher.finish(); debug_assert_eq!(hash.local_hash(), local_hash); } expn_id </ins> } else { let index_guess = decoder.foreign_expn_data[&hash]; <del> decoder.tcx.cstore_untracked().expn_hash_to_expn_id(krate, index_guess, hash) </del> <ins> decoder.tcx.cstore_untracked().expn_hash_to_expn_id( decoder.tcx.sess, krate, index_guess, hash, ) </ins> }; <del> #[cfg(debug_assertions)] { use rustc_data_structures::stable_hasher::{HashStable, StableHasher}; let mut hcx = decoder.tcx.create_stable_hashing_context(); let mut hasher = StableHasher::new(); hcx.while_hashing_spans(true, |hcx| expn_id.expn_data().hash_stable(hcx, &mut hasher)); let local_hash: u64 = hasher.finish(); debug_assert_eq!(hash.local_hash(), local_hash); } </del> <ins> debug_assert_eq!(expn_id.krate, krate); </ins> Ok(expn_id) } }

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. --Assuming that you copied 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</details
I reproduced this ICE locally. On my end I did it by copying the git checkout of into , because I wasn't able to figure out the right invocation to get it setup with files in (Oh, whoops, I think I was accidentally passing instead of . Of course that wasn't going to work.) well, not 100%, my query stack was a little different: but it seemed like a similar bug, nonetheless.
modify labels: +I-prioritize
Assigning as discussed as part of the and removing .
Now happens for when retrying the repro. (with replaced with as it was changed in rustc) <details<summarybacktrace</summary</detailsIt also gives an unstable fingerprint ICE for when compiling : <details<summarybacktrace</summary</details
The compilation now fails when accessing session in : It looks that decodes which in turn decodes which in turn requires access to a session, but by the time of call, the session in no longer threaded through. cc
I can confirm it works now. Pushed to re-enable incremental compilation for compiling the sysroot.
Change:
while let NameBindingKind::Import { binding: nested_binding, import, .. } = binding.kind { <del> let id = self.r.local_def_id(self.r.import_id_for_ns(import, key.ns)); self.update( id, </del> <ins> let mut update = |node_id| self.update( self.r.local_def_id(node_id), </ins> binding.vis.expect_local(), prev_parent_id, level, ); <ins> // In theory all the import IDs have individual visibilities and effective // visibilities, but in practice these IDs go straigth to HIR where all // their few uses assume that their (effective) visibility applies to the // whole syntactic `use` item. So we update them all to the maximum value // among the potential individual effective visibilities. Maybe HIR for // imports shouldn't use three IDs at all. update(import.id); if let ImportKind::Single { additional_ids, .. } = import.kind { update(additional_ids.0); update(additional_ids.1); } </ins> level = AccessLevel::Exported; <del> prev_parent_id = id; </del> <ins> prev_parent_id = self.r.local_def_id(import.id); </ins> binding = nested_binding; } }

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> warning: the `passes` flag is deprecated | = note: see issue #44136 <https://github.com/rust-lang/rust/issues/44136> for more information </ins>

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 tried this command: I expected to see this happen: rustdoc shows a warning, the way it does for any other value you pass to : Instead, this happened: Rustdoc gives no warning and lists all passes. <!-- 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. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Mentoring instructions: Move this check earlier to before is processed:
claim