jiebi/CodeConvo huggingface dataset:
Change:
TyKind::Never => Never, TyKind::Ptr(ref m) => RawPointer(m.mutbl, box m.ty.clean(cx)), TyKind::Rptr(ref l, ref m) => { <del> let lifetime = if l.is_elided() { None } else { Some(l.clean(cx)) }; </del> <ins> // There are two times a `Fresh` lifetime can be created: // 1. For `&'_ x`, written by the user. This corresponds to `lower_lifetime` in `rustc_ast_lowering`. // 2. For `&x` as a parameter to an `async fn`. This corresponds to `elided_ref_lifetime in `rustc_ast_lowering`. //    See #59286 for more information. // Ideally we would only hide the `'_` for case 2., but I don't know a way to distinguish it. // Turning `fn f(&'_ self)` into `fn f(&self)` isn't the worst thing in the world, though; // there's no case where it could cause the function to fail to compile. let elided = l.is_elided() || matches!(l.name, LifetimeName::Param(ParamName::Fresh(_))); let lifetime = if elided { None } else { Some(l.clean(cx)) }; </ins> BorrowedRef { lifetime, mutability: m.mutbl, type_: box m.ty.clean(cx) } } TyKind::Slice(ref ty) => Slice(box ty.clean(cx)),

Discussion:
When run on an with elided lifetimes, generates documentation containing the anonymous elided lifetimes in the function's signature. Running on the blocking variant of the same function produces a correct signature. You can reproduce this issue by generating docs for the following code: The asynchronous function's docs show the elided lifetimes, the blocking function's docs don't: :
I agree that this makes some function signatures unnecessarily verbose. For example: ... becomes ... However, given the nuances of async functions (specifically: the referenced values must survive every state of the FSM), one could argue that showing these lifetimes in the docs might be useful(?). It's obviously not the worst problem on earth, but could someone at least shed some light on whether this behaviour is intended or not? Is this a feature or a bug? Maybe
I think it's the expected behaviour. However we can discuss about removing the elided lifetimes. In this case it's not really useful...
It's especially visually disruptive with a parameter, making simple methods look significantly more complex than they actually are. It also feels surprising to special-case async functions like this, if it makes sense to show these lifetimes symmetry with traditional functions would be nice.
We have several instances of in the Tokio codebase because the version with explicit lifetimes is simpler than the one with all the elided ones displayed. There are many cases where it would be more useful to just not show lifetimes on the method.
So I don't forget, I got halfway through debugging this and it has something to do with 'in band lifetimes': Naively changing this to use the same mechanism as .
Funnily enough, this does work with 1.34 if you add enough s: ! So in some sense this is a regression, although you needed nightly to use at the time.
Change:
("associated_type_defaults", "1.2.0", Some(29661), Active), // Allows macros to appear in the type position. <del> ("type_macros", "1.3.0", Some(27336), Active), </del> <ins> ("type_macros", "1.3.0", Some(27245), Active), </ins> // allow `repr(simd)`, and importing the various simd intrinsics ("repr_simd", "1.4.0", Some(27731), Active),

Discussion:
Tracking issue for rust-lang/rfcs
The feature gate for this points at , should it point here instead?
How is this going? Is anything on fire yet?
Is there any review/stability status on this feature by any chance?
Any update on this?
cc This seems like a constrained extension to macros, that we could consider stabilising.
There's an issue re interaction with deriving, see , but I think it's minor.
Going to FCP for this feature seems good to me. If people are using it successfully (or have found bugs!) please say so :-)
+1 to stabilising. There are still a few issues with type macros, but just bugs, and nothing major that I'm aware of.
Did the lang team decide to FCP or wait?
We went to FCP. Apologies for the dropped administrative work recently -- all of the Mozilla folks just traveled to London for a week and the preparations for that resulted in some balls being dropped.
This feature is in its final comment period for stabilization (in 1.11).
rustc 1.11 still reports type macros as unstable. Is there any chance of having this feature stabilized in 1.12?
Yes, it's ready for immediate stabilization. Anyone should feel free to open a stabilization PR and ping me on it.
Indeed I am slow in writing it up, but the team decided formally to stabilize this feature (as commented). Horray!
I am tagging the issue with E-mentor because I would be happy to mentor someone through the process of implementing a stabilization PR.
I don't have experience with rustc internals, but I'd be happy to try to implement the stabilization PR. :-)
ok, basically all you have to do is to modify in and basically remove the from this code: you also need to change this declaration from and move it to be "accepted" (there is a section of "accepted" features below in the file):
Also remove from any tests that mention it.
Ok, I've removed the check on the feature gate in , updated the tests and moved the declaration in . Just two questions: 1) should I bump the version number in the declaration to ? (or maybe , it's not clear to me if this commit will be backported to the current beta) 2) should I reference this issue in the commit message? I've put " for now, I don't know if this convention is ok for this project. Thanks!
Change:
} } <ins> fn check_impl_item(&mut self, cx: &LateContext<'_>, ii: &hir::ImplItem<'_>) { if let hir::ImplItemKind::Const(..) = ii.kind && !assoc_item_in_trait_impl(cx, ii) { NonUpperCaseGlobals::check_upper_case(cx, "associated constant", &ii.ident); } } </ins> fn check_pat(&mut self, cx: &LateContext<'_>, p: &hir::Pat<'_>) { // Lint for constants that look like binding identifiers (#7526) if let PatKind::Path(hir::QPath::Resolved(None, ref path)) = p.kind {

Discussion:
I believe the old behavior from nightly-2023-04-19 is correct. The repro has nothing to do with trait impls so I believe was not supposed to have affected it.
Bisects to .
How on earth did that happen? It was like a five-line change. :laughing: EDIT: got a fix, will post soon.
Probably something to do with the hygeine of the span on the versus the . if you can't fix this then ping me and I'll look at it, but we probably should fix it sooner than later.
Actually, you're probably right.
Oh, no, that's not it. You're missing a call to in the visitor.
Change:
fn no_break_in_async_block() { async { <del> break 0u8; //~ ERROR `break` inside of a closure // FIXME: This diagnostic is pretty bad. </del> <ins> break 0u8; //~ ERROR `break` inside of an async block </ins> }; } fn no_break_in_async_block_even_with_outer_loop() { loop { async { <del> break 0u8; //~ ERROR `break` inside of a closure </del> <ins> break 0u8; //~ ERROR `break` inside of an async block </ins> }; } }

Discussion:
With: you get: Note how it references "a closure" which seems confusing for a user who doesn't presume the implementation. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I'm assuming its ok to leave this as the same error code of E0267 - in essence it's the same error, just more specific text.
Yeah I think it's fine.
Change:
/// compilation on error, merely emits a non-fatal error and returns None. pub fn expr_to_string(cx: &mut ExtCtxt, expr: P<ast::Expr>, err_msg: &str) -> Option<(InternedString, ast::StrStyle)> { <ins> // Update `expr.span`'s expn_id now in case expr is an `include!` macro invocation. let expr = expr.map(|mut expr| { expr.span.expn_id = cx.backtrace; expr }); </ins> // we want to be able to handle e.g. concat("foo", "bar") let expr = cx.expander().fold_expr(expr); match expr.node {

Discussion:
For example, invocation in should search in but instead searches in .
cc
It looks like this is a problem with .
Change:
[[package]] name = "num_cpus" <del> version = "1.8.0" </del> <ins> version = "1.10.1" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "c51a3322e4bca9d212ad9a158a02abc6934d005490c054a2778df73a70aa0a30" </del> <ins> checksum = "bcef43580c035376c0705c42792c294b66974abbfd2789b511784023f71f3273" </ins> dependencies = [ "libc", ]

Discussion:
Do we have plan to get rid of this restriction recently? A newer version of cc-rs is needed for VxWorks
can't currently be updated due to a build problem with riscv. More info at I think the issue is that rustbuild uses cc to discover cc toolchains, and gained riscv support, and so now it thinks it should use a gcc toolchain that doesn't exist. The detection is in and Alex mentioned just setting a env var in the riscv container might be enough. It's been on my todo list for a while, but I haven't had a chance to look at it. I can maybe try to look at it this weekend.
Thanks for working on this issue. Enjoy your weekend, it is not that urgent.
Change:
"you likely meant to continue parsing the let-chain starting here", ); } else { <ins> // Look for usages of '=>' where '>=' might be intended if maybe_fatarrow.kind == token::FatArrow { err.span_suggestion( maybe_fatarrow.span, "you might have meant to write a "greater than or equal to" comparison", ">=", Applicability::MaybeIncorrect, ); } </ins> err.span_note( cond_span, "the `if` expression is missing a block after this condition",

Discussion:
When encountering code like , we currently emit But it should be closer to <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hi! I'd like to try working on this issue if nobody else is currently. claim
Change:
<del> Subproject commit eac6ff795c40778683e42b0c6ab6f6adaceb391d </del> <ins> Subproject commit 8841dcef357e051c34a46030db7c7b1a83f9b1d8 </ins>

Discussion:
Introduced by . This is because we now use to build but it defaults to soft float for all arm which is wrong for gnueabihf/eabihf. This is fixed in upstream llvm to choose the right float abi based on the target. This will no longer be an issue once we update llvm.
Change:
<ins> error[E0207]: the lifetime parameter `'a` is not constrained by the impl trait, self type, or predicates --> $DIR/unconstrained-impl-param.rs:11:6 | LL | impl<'a> Trait for Opaque<&'a str> { |      ^^ unconstrained lifetime parameter error: aborting due to previous error For more information about this error, try `rustc --explain E0207`. </ins>

Discussion:
The following UB compiles: The impl is invalid because the lifetime parameter appears unconstrained in the impl header. It should be rejected for the same reason that projection types doesn't constraint impl generics: label C-bug T-types I-unsound requires-nightly F-typealiasimpl_trait
Change:
<ins> warning: `[error]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning-crlf.rs:8:6 | LL | /// [error] |      ^^^^^ cannot be resolved, ignoring | = note: #[warn(intra_doc_link_resolution_failure)] on by default = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[error1]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning-crlf.rs:12:11 | LL | /// docs [error1] |           ^^^^^^ cannot be resolved, ignoring | = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[error2]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning-crlf.rs:14:11 | LL | /// docs [error2] |           ^^^^^^ cannot be resolved, ignoring | = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[error]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning-crlf.rs:21:20 | LL |  * It also has an [error]. |                    ^^^^^ cannot be resolved, ignoring | = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` </ins>

Discussion:
Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs:
Change:
self.expr_and_pat_count = outer_ec; self.cx = outer_cx; self.terminating_scopes = outer_ts; <ins> self.pessimistic_yield = outer_pessimistic_yield; </ins> } fn visit_arm(&mut self, a: &'tcx Arm<'tcx>) {

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. --: Same issue still exists in : and also in : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
T-compiler triage: P-high. Leaving nomination label in place, since I don't want to disrupt WG-async-await workflow.
This does already ICE on 1.39.0
I could further simplify the code as:
However, this code does not cause ICE:
If you can reproduce this without depending on tokio that would be great.
How abot this?
Minimized:
in T-compiler meeting. Keeping as P-high but removing nomination.
OK so I've been investigating this a bit. I am not quite able to write-up mentoring instructions yet because I don't really understand what's going on, but I can leave a few notes. First off, the ICE occurs in the code that is attempting to approximate what values may be live across an . It occurs specifically when you have a structure. The nested async blocks etc are not really needed. For example, this also fails in the same way; The ICE occurs in this match arm: It appears to be related to some logic that is attempting to figure out a "worst case" execution order for instructions: I confess I don't quite follow this logic anymore, but the problem has to do with entering a distinct async block. This code for example does not trigger the failure:
Ah, I think maybe I see the problem here actually -- I suspect the problem is that we need to clear (and then restore) the flag when we recurse into a closure body.
Change:
Slice => "slice", Tuple => "tuple", RawPointer => "pointer", <ins> Reference => "reference", </ins> } }

Discussion:
E.g. there's no for or .
cc
What sorts of impls would be expected on this page? Listing impls for every (, , , , ) might be excessive, although of course it's better to err on the side of documenting too much than not enough :-)
It might be, yeah. In principle, there should at least be some kind of page I can put some text on, even if it says "Most of the methods aren't shown on this page because it's too primitive" or something.
At least inherent methods should be listed now.
Triage: no change
Since i just did function pointers (), i'll add this while the details are fresh in mind. What details should go here? ? Using for reborrowing and Deref? Copy/paste details from either edition of the book? Leave it as a skeleton and fill it out later? As for what impls to include, my initial thought was to only include impls where it's a reference to a generic. Otherwise it'll show up on the referent's page, like it is now.
Change:
#![feature(const_default_impls)] #![feature(const_trait_impl)] #![feature(const_str_from_utf8)] <del> #![feature(nonnull_slice_from_raw_parts)] </del> #![feature(panic_update_hook)] #![feature(pointer_is_aligned)] #![feature(slice_flatten)]

Discussion:
This is a tracking issue for the method proposed in PR The feature gates for the issue are , and for using as a . Docs: [x] Implementation: [x] FCP: [ ] Stabilization 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.
I'm willing to file the stabilization report for this if the library team is on board for stabilization.
I'd certainly appreciate one!
: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:
ast::ExprRepeat(ref element, ref count_expr) => { check_expr_has_type(fcx, &**count_expr, ty::mk_uint()); let count = ty::eval_repeat_count(fcx, &**count_expr); <del> let t: ty::t = fcx.infcx().next_ty_var(); check_expr_has_type(fcx, &**element, t); </del> <ins> let (check, t) = check_fn_for_vec_elements_expected(fcx, expected); check(fcx, &**element, t); </ins> let element_ty = fcx.expr_ty(&**element); if ty::type_is_error(element_ty) { fcx.write_error(id);

Discussion:
fails to compile: cc
What does the l-wrong label mean here?
It means that the current behavior of the compiler is incorrect.
Change:
function updateCrate(ev) { if (ev.target.value === "all crates") { // If we don't remove it from the URL, it'll be picked up again by the search. <del> const params = searchState.getQueryStringParams(); </del> const query = searchState.input.value.trim(); <del> if (!history.state && !params.search) { history.pushState(null, "", buildUrl(query, null)); } else { history.replaceState(null, "", buildUrl(query, null)); } </del> <ins> updateSearchHistory(buildUrl(query, null)); </ins> } // In case you "cut" the entry from the search input, then change the crate filter // before paste back the previous search, you get the old search results without

Discussion:
Reproduction: Go to Click the gear next to the search field, enable "Directly go to item in search if there is only one result" Refresh page to ensure it's enabled (was required the first time I tried to reproduce, but seemed to work straight away the second time) Search for You should be taken straight to Press "Back" in your browser I expected this to happen: Go back to Instead, this happened: Goes back to then instantly redirects forward again
Taking a look.
Fixed in
Change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { [0; ..10]; //~^ ERROR mismatched types //~| expected type `usize` //~| found type `std::ops::RangeTo<{integer}>` } </ins>

Discussion:
The following code produces a compiler error (as expected) on stable, but the compiler crashes on nightly. On stable: On nightly:
Also in beta=1.17.
Backtrace:
Change:
<ins> error[E0061]: this method takes 2 arguments but 1 argument was supplied --> $DIR/point-at-inference-4.rs:12:7 | LL |     s.infer(0i32); |       ^^^^^------ an argument is missing | note: associated function defined here --> $DIR/point-at-inference-4.rs:4:8 | LL |     fn infer(&self, a: A, b: B) {} |        ^^^^^        ----  ---- help: provide the argument | LL |     s.infer(0i32, /* b */); |            ~~~~~~~~~~~~~~~ error[E0308]: mismatched types --> $DIR/point-at-inference-4.rs:16:24 | LL |     let t: S<u32, _> = s; |            ---------   ^ expected `S<u32, _>`, found `S<i32, _>` |            | |            expected due to this | = note: expected struct `S<u32, _>` found struct `S<i32, _>` error: aborting due to 2 previous errors Some errors have detailed explanations: E0061, E0308. For more information about an error, try `rustc --explain E0061`. </ins>

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. --Ran into an ICE while refactoring. Only happens on nightly. Don't know what else I should write here. <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I cannot reproduce this using on . I ran it on Could you try bisecting this yourself locally (I am not able to right now)
I hit this same bug and got a patch, can post a PR soon if useful!
Sounds great! assign
Change:
<ins> - // MIR for `pointee` before ElaborateBoxDerefs + // MIR for `pointee` after ElaborateBoxDerefs fn pointee(_1: Box<i32>) -> () { -     debug foo => (*_1); +     debug foo => (*(((_1.0: std::ptr::Unique<i32>).0: std::ptr::NonNull<i32>).0: *const i32)); let mut _0: (); bb0: { return; } } </ins>

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</detailsthis was at the end of the error <pi have put a comment in the code where the problematic line is, the problem could be caused by async trait object method in ResourceLoader::startloading<bri am using asynctrait crate<brhere is the library code that the problematic code uses<brthe ResourceLoader trait is at the end </prustc-ice-2024-08-02T150352-!
Change:
Neg = -1, Arith = 1 + 1, //~ ERROR arbitrary expressions aren't allowed in patterns //~| ERROR arbitrary expressions aren't allowed in patterns <del> //~| ERROR only `char` and numeric types are allowed in range patterns </del> }); fn main() {}

Discussion:
currently throws E0029: while it should infer the constant to be . modify labels: +T-compiler +A-inference claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I don't think this is incorrect. doesn't refer to a specific constant, it's just an abstract associated constant. works fine.
Hmm, does work, though. But does not. It does seem inconsistent that works and doesn't.
is just , so type inference should kick in here. In fact you can write and inference works just fine. The issue only happens when used in range patterns. I am prototyping a fix right now and it seems that the issue is just that E0029 check happens a little bit early (before unification is performed).