jiebi/CodeConvo huggingface dataset:
Code change:
let link_meta = self.link_meta; let is_proc_macro = tcx.sess.crate_types.borrow().contains(&CrateTypeProcMacro); let root = self.lazy(&CrateRoot { <del> rustc_version: rustc_version(), </del> name: link_meta.crate_name, triple: tcx.sess.opts.target_triple.clone(), hash: link_meta.crate_hash,

Related discussion:
text: cc
I incremented the header version number though... It should be impossible for older rustc to get that far.
on it looks the same on . Perhaps we just need a PR to bump that?
Oh it looks like my changes have reached stable. I wonder if perhaps the is in a precarious spot and/or has been moved or the serialization otherwise changed. This requires further investigation.
Why is this even calling leb128? Are we using variable-length integers in the metadata header?
I assumed leb128 was the crate being built, not one used by the compiler.
Sure enough. Now every change to requires us to update the LLVM version number, because checking the rustc version number requires parsing . I think we should go back to JSON version guard.
Ahh that's what it was. We can put it at the start then, before/after the absolute address. I'd forgotten that the whole struct would have to be decoded.
What was the PR that modified the versioning scheme? I gather that something has changed about it. Can somebody explain more clearly what is going wrong here?
I mistakenly put the version string inside a larger , somehow thinking that it being at the start helped, but if the whole (that is, ) can't be decoded (e.g. because its definition changed) then you don't get to see the version string, whereas before it was separate. The fix would be to separate it again, put it back at the start and leave it there. Or just encode/decode it before instead of as part of it. Either will work as long as it can't be affected by changes to the metadata schema. The PR that introduced the new schema was , although breakage didn't happen until changed later, for procedural macros and/or the name resolution changes ( would know).
removed the field from for macro modularization.
I believe I have a fix ready. Does this affect beta too now, or just nightly?
AFAIK it's just nightly, not beta or stable
Code change:
<ins> // check-pass #![feature(type_alias_impl_trait)] fn opaque<'a: 'a>() -> impl Sized {} fn assert_static<T: 'static>(_: T) {} fn test_closure() { let closure = |_| { assert_static(opaque()); }; closure(&opaque()); } type Opaque<'a> = impl Sized; fn define<'a>() -> Opaque<'a> {} fn test_tait(_: &Opaque<'_>) { None::<&'static Opaque<'_>>; } fn main() {} </ins>

Related discussion:
text: Another regresssion of with a different failure path: It should be fixed by ignoring non-captured lifetimes in: cc label regression-from-stable-to-stable C-bug T-compiler T-types A-impl-trait
Note that fixing this issue is necessary for , but might not be sufficient. I'll investigate more...
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
<ins> // check-pass #![feature(type_alias_impl_trait)] fn opaque<'a: 'a>() -> impl Sized {} fn assert_static<T: 'static>(_: T) {} fn test_closure() { let closure = |_| { assert_static(opaque()); }; closure(&opaque()); } type Opaque<'a> = impl Sized; fn define<'a>() -> Opaque<'a> {} fn test_tait(_: &Opaque<'_>) { None::<&'static Opaque<'_>>; } fn main() {} </ins>

Related discussion:
text: Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
unstable("linker", |o| { o.optopt("", "linker", "linker used for building executable test code", "PATH") }), <ins> unstable("sort-modules-by-appearance", |o| { o.optflag("", "sort-modules-by-appearance", "sort modules by where they appear in the  program, rather than alphabetically") }), </ins> ] }

Related discussion:
text: Instead it should use the order that appear in the crate file. Even better, it should allow adding section headers (with a description) between them. Hypothetically: And get something like this: This would make both the source code and the documentation more accessible as the modules would be presented in a comprehensible order, with some description of each related group of modules. Edit: Rename issue to reflect that this isn't an either-or. Alphabetical order is useful, but so is programmer-specified order (to make the code accessible for newcomers) and Rustdoc should support both - see the thread below.
Shouldn't related modules be nested in submodules rather than logically ordered in the source? Finding things in long non-ordered lists is a real pain.
Yeah, I'm going to vote "alphabetical".
Hmmm. I pretty sure I put a comment here, and now its gone. Strange. Anyway. Here it goes again. Alphabetical order == random order. That's great when you know what you are looking for and just want to find it. When coming to a new non-trivial code base, being presented the content in random order is just about the worst possible way to access it. Nested modules allow us to group related modules together, and that's a good thing. If you have a long list of modules, certainly, group them. But this doesn't solve the problem. You now have a TOC where each level is randomized, which is still inaccessible. Searching for a function or module by name is an important use case, sure. But being able to access a new code base is as important, if not more so. Looking up a name in a short non-alphabetized list (at each level) isn't too hard, and one can always compensate for the lack of an alphabetical index by using ^F. Trying to understand a system presented in random order is next to impossible, and one can not compensate for the lack of a comprehensible order in a large system. If there was a way to specify the order of the entries in each level, which we agree should only contain "a few" entries, then the TOC would become accessible. If one could even add a bit of annotation for each level, so much the better.
Code change:
unstable("linker", |o| { o.optopt("", "linker", "linker used for building executable test code", "PATH") }), <ins> unstable("sort-modules-by-appearance", |o| { o.optflag("", "sort-modules-by-appearance", "sort modules by where they appear in the  program, rather than alphabetically") }), </ins> ] }

Related discussion:
text: The annotated TOC would serve as a very accessible way for a newcomer to understand the code base. And, this doesn't rule out also generating an alphabetically sorted reference index, beside the TOC. All good books do both - a TOC in reasonable order and an index for looking up data by name. We shouldn't have to choose, we should be able to get both. So, I misnamed the issue. It should be "Rustdoc shouldn't list modules only alphabetically".
Agreed. Can someone rename the title?
Rename done.
Visiting for triage. Minor, but still an issue.
Triage, still listed alphabetically. Here's a sample source file: !
Code change:
/// For most cases with placeholders, this function will return `None`. /// /// See [`fmt::Arguments::as_str`] for details. <del> #[unstable(feature = "panic_info_message", issue = "66745")] </del> <ins> #[stable(feature = "panic_info_message", since = "CURRENT_RUSTC_VERSION")] </ins> #[rustc_const_unstable(feature = "const_arguments_as_str", issue = "103900")] #[must_use] #[inline]

Related discussion:
text: was closed when stabilized the corresponding language feature, but we didn’t realize that it was also the tracking issue for this standard library feature: History: [x] Original tracking issue: [x] Discussion of payload vs message [x] Making .message() infallible: [x] Split core/std PanicInfo into two types: This made core::panic::PanicInfo::message() infallible. [x] Use opaque return type: [x] FCP [x] Stablization PR: Unresolved questions: [x] Should it be infallible? Yes, by making std::panic::PanicHookInfo a different type. [x] What should the return type be? or an opaque ? The first is simpler, but the latter allows a bit more flexibility for future changes.
Instead of making a PR go through the queue to fix the tracking issue, should we stabilize this method? fcp merge The doc-comment is slightly wrong or out of date. Its second line shoudl be removed. always creates a where is , regardless of the number of arguments given. In the single-argument case, that argument is required to have type . At first returning seemed unusual to me and I considered that we could make the method return instead, on the basis that calling its impl is almost the only useful thing to do with a . But has been stable and documented as the return type of since 1.0.0, so maybe it’s fine.
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [ ] [x] [x] [ ] [ ] [ ] Concerns: single-arg core::panic () 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.
The module also links to that closed tracking issue. Let’s consider the pFCP above to also include stabilizing it. ( is stable.)
concern single-arg core::panic Should we change libcore’s macro so that its single-argument form creates a with a instead of one with a ?
Code change:
/// For most cases with placeholders, this function will return `None`. /// /// See [`fmt::Arguments::as_str`] for details. <del> #[unstable(feature = "panic_info_message", issue = "66745")] </del> <ins> #[stable(feature = "panic_info_message", since = "CURRENT_RUSTC_VERSION")] </ins> #[rustc_const_unstable(feature = "const_arguments_as_str", issue = "103900")] #[must_use] #[inline]

Related discussion:
text: CC Pushing this idea further, it’s tempting to maybe remove entirely and instead have a whose dynamic type can be . But that doesn’t work because is a method of and is not .
I thought the point of the message field was that core can't make a payload since it can't allocate?
The struct is: Both the and fields involve borrowing. As far as is concerned, they could both be borrowing form a stack frame. (And as far as I understand they are, in practice today.) It’s in the case of unwinding that there’s an owned that can return, which requires allocating.
Based on the timing of it looks like you may have thoughts on this :)
Ah, goes into how and why the panic handler in libstd (which is called by if libstd is linked) ignores the it receives. We could probably change this but it gets tricky: while most implementations of for environments would be fine with receiving a borrowed payload, libstd wants to potentially take ownership and box it for unwinding.
I have zero recollection for why this is the way it is, and I'm not really particularly interested in doing all the archaeology to dig up why it is the way it is. I'm not a huge fan of just stabilizing things because they happen to be there, but I don't really see why we wouldn't want to stabilize this. If there were a reason to not stabilize this though an investigation would presumably turn that up, but I'm not up to do that investigation myself.
That’s totally fair. I’m confident that this was more likely forgotten than deliberately left unstable. If deliberate we would have kept the tracking issue open or made a new one for the remaining bits. This is what lead me to propose stabilization. Having dug a little more, and thanks to Ralf’s blog post, I think we may want at some point to revisit what data we expect to contain or not in various situation. In particular it could be interesting to extend to support payloads other than and make it closer to . Given those possibly-desirable changes, it may not be the time to add more constraints: fcp cancel
proposal cancelled.
Lol, I had no idea. ;) So, indeed, I was wondering if we could do something about the duality of the and fields in . I assume we cannot change the fact that the same type is used both of panic handlers and panic hooks.
Code change:
/// For most cases with placeholders, this function will return `None`. /// /// See [`fmt::Arguments::as_str`] for details. <del> #[unstable(feature = "panic_info_message", issue = "66745")] </del> <ins> #[stable(feature = "panic_info_message", since = "CURRENT_RUSTC_VERSION")] </ins> #[rustc_const_unstable(feature = "const_arguments_as_str", issue = "103900")] #[must_use] #[inline]

Related discussion:
text: Concretely, I was thinking of adjusting somewhat like this: That would at least remove the need for the hack in . (The hack would likely move to instead, but that is a smaller hack IMO: the hack is now not encoded in the state of any more, just in its dynamic API.) I think this would retain all current functionality while clarifying the invariant of wrt. the payload (and explicitly calling the message a "payload"; right now it seems to be something that sits next to the payload which is inaccruate). But there are enough subtleties here that we'll only really know once someone implements this. With this change, the panic hook would always get a . We should likely provide a method somewhere in libstd to factor out this code: I was imagining something like an extension trait on with a type like . However, the panic hook is not the only place where that conversion is useful; another situation is code that caught a panic and wants to extract the message. I expect most instances of that to just handle payloads, not knowing that payloads are also common (that is certainly what happened when I wrote such code). So ideally we'd have a method that takes and returns , but I do not have a good idea where to put that. This is the hard part, as we cannot use . I wonder if we can use a take-based approach, similar to ? Conceptually, would put the panic into an , and somehow pass an to the panic handler, and the implementation of said handler could then the payload if it needs full ownership (like for unwinding). Except the panic handler cannot be generic, so it would have to be , which is not a thing. But with enough unsafe code we could re-implement something that behaves like that. I don't see any way to do this entirely safely; the panic handler that wants to take out the payload and put it somewhere needs to dynamically determine the size of the payload and arrange for there to be enough space. In liballoc, we could provide a safe wrapper for this that puts things into a , but in libcore, I don't think there is a safe API that we could provide to grab ownership.
Code change:
/// For most cases with placeholders, this function will return `None`. /// /// See [`fmt::Arguments::as_str`] for details. <del> #[unstable(feature = "panic_info_message", issue = "66745")] </del> <ins> #[stable(feature = "panic_info_message", since = "CURRENT_RUSTC_VERSION")] </ins> #[rustc_const_unstable(feature = "const_arguments_as_str", issue = "103900")] #[must_use] #[inline]

Related discussion:
text: But maybe it is enough for the public API to expose ways to borrow the payload (should work for all non-unwinding handlers); if only libstd needs to take the payload (for unwinding) we could keep the unsafe part of the API internal. Also, we certainly do not want a panic hook to the payload out of its . At this point it seems to be quite a problem that panic hook and panic handler both use the same type. In fact, a panic handler likely wants a to be able to things without interior mutability. Is there any way we could make the attribute support both signatures, and then (based on the types of the methods) only -based implementations will actually be able to or the payload?
I agree, but it’s can easily be an inherent method of nor of because those are in libcore which doesn’t have access to . It feels slightly unfortunate that we’d need an extension trait just for this. I considered this yesterday and come to pretty much the same conclusions. To take ownership of a payload of unknown size through a non-generic API we pretty much heap allocation, which for libcore means something like receiving an , unsafely using , and returning that is to be passed to . It’s not pretty, but if only libcore and libstd deal with this internally maybe that’s ok? Is there a use case for a other than libstd’s to take ownership of the payload?
I was thinking of a slightly different API actually: Here, does to put the payload into caller-allocated storage; that storage must have (at least) size and align as given by . What I did not consider is how to get out the vtable, so maybe that higher-order approach is better.
We discussed this in the libs-api meeting today. We concluded that before stabilizing this, we need to make sure it works (doesn't return ) for std::panic!() as well. That is already the case with Rust 2021's std::panic!() (since it's identical to core::panic!() in this edition), but not for Rust 2015/2018's std::panic!(). Once that is fixed, we feel okay with returning a placeholder message for non-string panics (panics from or Rust 2015/2018's ), at which point the function can return an unconditionally, rather than an .
Code change:
/// For most cases with placeholders, this function will return `None`. /// /// See [`fmt::Arguments::as_str`] for details. <del> #[unstable(feature = "panic_info_message", issue = "66745")] </del> <ins> #[stable(feature = "panic_info_message", since = "CURRENT_RUSTC_VERSION")] </ins> #[rustc_const_unstable(feature = "const_arguments_as_str", issue = "103900")] #[must_use] #[inline]

Related discussion:
text: (And also, should be returned by value, not by reference.)
Any progress on stabilization?
It would great to have this little feature.
Still nothing? What's missing?
can this be stabilized after was resolved in the pull request ?
Yes, soon, hopefully! I've updated the overview at the top of this tracking issue. The main question left before stabilization is the return type of the method. Should this return (as the unstable method does today), or should it return an opaque type that wraps that fmt::Arguments, so we can still change in the future? (In case we want to support different types of no_std panic, such as panicking with an Error or something.)
Can it return or so?
I would vote for an opaque type that would also implement .
Did that in this PR:
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.
Code change:
<del> //@ known-bug: #124342 trait Trait2 : Trait { reuse <() as Trait>::async { (async || {}).await; }; } </del>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' 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: [resolverforlowering_raw] getting the resolver for lowering --
this probably crashes since but I haven't verified that yet
smaller
even smaller
Code change:
.filter(|item| matches!(item.kind, ty::AssocKind::Fn) && !item.fn_has_self_parameter) .filter_map(|item| { // Only assoc fns that return `Self`, `Option<Self>` or `Result<Self, _>`. <del> let ret_ty = self.tcx.fn_sig(item.def_id).skip_binder().output(); </del> <ins> let ret_ty = self .tcx .fn_sig(item.def_id) .instantiate(self.tcx, self.fresh_args_for_item(DUMMY_SP, item.def_id)) .output(); </ins> let ret_ty = self.tcx.instantiate_bound_regions_with_erased(ret_ty); let ty::Adt(def, args) = ret_ty.kind() else { return None;

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: param types with same index differ in name'', 'thread 'rustc' panicked at 'assertion failed: param types with same index differ in name'' File: --auto-reduced (treereduce-rust): original: Version information ` Command:
thanks for the stack trace for this class of ICEs, it's just the right thing that I need. Minimal:
Code change:
// For additional insurance via fuzzing and crater, we verify that the constraint's min // choice indeed escapes the function. In the future, we could e.g. turn this check into // a debug assert and early return as an optimization. <ins> let scc = sccs.scc(successor); </ins> for constraint in self.regioncx.applied_member_constraints(scc) { if universal_regions.is_universal_region(constraint.min_choice) { return;

Related discussion:
text: File: snippet: 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
cc removing the println macro from around the match avoids the ice :thinking:
Fun :)
A more minimal version would be:
Code change:
T: Iterator<Item = &'a Symbol>, { let max_dist = dist.map_or_else(|| cmp::max(lookup.len(), 3) / 3, |d| d); <ins> let name_vec: Vec<&Symbol> = iter_names.collect(); </ins> <del> let (case_insensitive_match, levenstein_match) = iter_names </del> <ins> let (case_insensitive_match, levenshtein_match) = name_vec .iter() </ins> .filter_map(|&name| { let dist = lev_distance(lookup, &name.as_str()); if dist <= max_dist { Some((name, dist)) } else { None } }) // Here we are collecting the next structure: <del> // (case_insensitive_match, (levenstein_match, levenstein_distance)) </del> <ins> // (case_insensitive_match, (levenshtein_match, levenshtein_distance)) </ins> .fold((None, None), |result, (candidate, dist)| { ( if candidate.as_str().to_uppercase() == lookup.to_uppercase() {

Related discussion:
text: On identifiers that have more than one word, it is relatively common to write them in the wrong order ( → ). These are normally not found by Levenshtein distance checks, but we could do a basic "split on ``, sort and join before comparison" so that we could suggest the right identifier. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'd like to try to work on this. As is short enough to be caught by the Levenstein distance, I wrote for testing: claim
I'm thinking about the priority of the different possible matches. I tend to think that a match found by levenstein distance should have a greater priority, but what do you think?
it's tricky. I feel that your instinct might be right but we'd only know when looking at real world usage. The nice thing is that the lev distance check by its very nature it is limited, so doing the swapped words check as a fallback should work out ok in practice.
Releasing my assignment, as I am not sure to be able to commit. In case someone want to take on this, here is the function that should be modified. release-assignment
(I think this is appropriate, please tell me if it isn't) modify labels to +E-Easy
I can take a stab at this, seems reasonable with previous comments. claim