jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or predicates --> $DIR/refine-resolution-errors.rs:9:6 | LL | impl<T: ?Sized> Mirror for () { |      ^ unconstrained type parameter error[E0282]: type annotations needed --> $DIR/refine-resolution-errors.rs:15:5 | LL |     async fn first() -> <() as Mirror>::Assoc; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type error: aborting due to 2 previous errors Some errors have detailed explanations: E0207, E0282. For more information about an error, try `rustc --explain E0207`. </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. --(hand-reduced) <details<summary<strong(original)</strong</summary<p</p</details<!-- 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. --: Command: I put the option to remove "async fn" error, but I guess it is not an essential option to trigger ICE. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details- ICE location: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
searched nightlies: from nightly-2022-02-19 to nightly-2024-06-19 regressed nightly: nightly-2024-03-08 searched commit range: regressed commit: ()
Change:
[[package]] name = "byteorder" <del> version = "1.2.7" </del> <ins> version = "1.3.2" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "94f88df23a25417badc922ab0f5716cc1330e87f71ddd9203b3a3ccd9cedf75d" </del> <ins> checksum = "a7c3dd8985a7111efc5c80b44e23ecdd8c007de8ade3b96595387e812b957cf5" </ins> [[package]] name = "bytes"

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
triage: P-medium. Unnominating.
Change:
if let Some(els) = els { self.nbsp(); self.word_space("else"); <ins> // containing cbox, will be closed by print-block at `}` self.cbox(0); // head-box, will be closed by print-block after `{` self.ibox(0); </ins> self.print_block(els); }

Discussion:
Link to : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
searched nightlies: from nightly-2022-01-01 to nightly-2022-08-08 regressed nightly: nightly-2022-07-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: aarch64-apple-darwin Reproduce with: </details
It was probably regressed by , cc
label F-let-else
Change:
/// we identify the `FnOnce<Args, Output = ?Fut>` bound, and if the output type is /// an inference variable `?Fut`, we check if that is bounded by a `Future<Output = Ty>` /// projection. <ins> /// /// This function is actually best-effort with the return type; if we don't find a /// `Future` projection, we still will return arguments that we extracted from the `FnOnce` /// projection, and the output will be an unconstrained type variable instead. </ins> fn extract_sig_from_projection_and_future_bound( &self, cause_span: Option<Span>,

Discussion:
I'm writing this as a continuation of While the problem from first message in issue seems to be fixed, there are still cases when this fails. One of examples is when using instead of , when closure is expected to return : I expected to see this happen: All options used to work in past versions of rust Instead, this happened: Without explicit type hint it fails It most recently worked on: Not 100% sure, some explanations have been made in original issue
This is because the signature of  is: We only extract an async closure bound from cases where there is bound on the trait, which is not. There isn't even a supertrait bound that constrains the output type. I also do not expect this to ever be fixed, because that would require overly complicating the closure signature inference algorithm in ways that make me quite uncomfortable[^1][^2]. The correct solution is to rework the futures crate to have first-class async closure support, so for now I'd recommend just ascribing your type names. Sorry! [^1]: Firstly, this would break if another blanket implementation for were ever . [^2]: Secondly, the combinator shouldn't really be using bounds either -- it should be using bounds.
Alternatively, would fix this when paired with a slight adjustment to the closure signature inference that I'd be happy to make, but it seems like that PR is blocked.
Change:
) -> subst::GenericArg<'tcx> { let tcx = self.astconv.tcx(); match param.kind { <del> GenericParamDefKind::Lifetime => tcx.lifetimes.re_static.into(), </del> <ins> GenericParamDefKind::Lifetime => self .astconv .re_infer(Some(param), self.span) .unwrap_or_else(|| { debug!(?param, "unelided lifetime in signature"); // This indicates an illegal lifetime in a non-assoc-trait position tcx.sess.delay_span_bug(self.span, "unelided lifetime in signature"); // Supply some dummy value. We don't have an // `re_error`, annoyingly, so use `'static`. tcx.lifetimes.re_static }) .into(), </ins> GenericParamDefKind::Type { has_default, .. } => { if !infer_args && has_default { // No type parameter provided, but a default exists.

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 code: I expected to see this happen: the lifetime is correctly inferred when using Instead, this happened: I have to use one of the work arounds described in the linked code. Swap from GAT lifetime to the trait parameterized by a lifetime it works: <!-- 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 --
Interested in fixing this. I think all we need to do is treat like other paths with elided lifetimes (e.g. ). you're the go-to person for GATs, right? If so, does that sound correct? Secondly I might also put up a PR that suggests adding when parsing since that's also what's wrong with the second solution. claim
ah yes, good catch, the second solution does work with . In the way I had originally encountered this it didn't work without more nightly features () - a GAT, on a trait, on a , which parametrized a trait. Which left the type alias way the only way around.
I don't know if I've looked at this code before. But seems about right. I'm wondering if something like works and there's just code somewhere that doesn't take into account that the associated type itself can have substs.
This might be a little bit difficult though. When using a concrete struck like , we can infer that lifetime because we know how it's used in the struct itself. With associated types, we don't know, necessarily. In a way, I would expect that to be somewhat opaque, tbh. I'm not sure how I feel about this tbh. If you can fix it, I'd probably want to get some second thoughts before merging.
Change:
int_impl! { isize, i16, usize, 16, 15, -32768, 32767, 4, "-0x5ffd", "0x3a", "0x1234", "0x3412", "0x2c48", "[0x34, 0x12]", "[0x12, 0x34]", usize_isize_to_xe_bytes_doc!(), usize_isize_from_xe_bytes_doc!() } <del> widening_impl! { isize, i32, 16, signed } </del> } #[cfg(target_pointer_width = "32")]

Discussion:
I had this question on the currently unreleased ; on signed carry (probably applies to substraction too ?); I have this test failing with the current code: Playground: Is the test correct ? A carry did happen in an intermediate calculation, but should the overall calculation report a carry ?
I agree that this is a bug. There's a carry when the calculation is done as unsigned, but this is not the same in signed. Another example: That incorrectly returns .
There's some discussion about that in the tracking issue, starting with
Yeah, it looks like I rehashed the same arguments, that's what I get for reading comments and doc too fast. Still, I think that this is surprising enough that it would be nice to address it somehow.
I agree this is a bug. It looks like it's implementing the signed version using the unsigned one, returning the same carry flag (), but that's incorrect. Here's another demonstration that it needs an update: you be up to making a fix PR, You can use to get assigned to this issue.
I have no bandwidth for making a fix right now. Since this was supposed to be helpers for bigint operations, my first idea was to just remove the signed variants. I have no idea if this would be appropriate. Anyone is welcome to do a proper fix, it shouldn't be too complicated.
A thought: What should do? It feels to me like the carryout from that should perhaps be , since the carry from that is different from the one in , which would imply that it couldn't be anymore. We do have a type that's -1, 0, or 1: . I can't decide if that's clever or horrible. Or should we just delete the signed versions for now?
I think should return , because signed and unsigned operations should give the same results, so should be computed as which gives , then truncated to 8-bits which gives . Then because gives , which can't be represented as an 8-bits signed number, then there is overflow to me. Now for the -1, 0, 1 overflow, I don't think it's necessary because the point of the bit is to indicate if it happened or not. The direction of overflow is indicated by the resulting value. If I am correct, then this raises another question: should intermediate overflow be detected or not ?

for example: gives a result of -128, so the output is the same as the input so no overflow. But if we break down the operations, overflows to 127, and then overflows back to -128. In this case should an overflow occur or not ? Considering my previous example, I personally think it intermediate overflow shouldn't be detected because it would be misleading: it would indicate that the sign of the source operands and the result are different while they are the same. Tho I'd like other's opinion.
I think so. The unsigned versions have clear semantics, but it gets weird with signed values, and as a "bigint helper" I'd be surprised to see one that uses signed digits in the first place.
Change:
fn main() { println!("{}", std::mem:size_of::<BTreeMap<u32, u32>>()); <del> //~^ ERROR expected one of </del> <ins> //~^ ERROR casts cannot be followed by a function call //~| ERROR expected value, found module `std::mem` [E0423] //~| ERROR cannot find type `size_of` in this scope [E0412] </ins> }

Discussion:
Summary: Parsing leads to the error: It is currently impossible for a cast expression to have a trailing index expression without surrounding the cast expression by parenthesis. This however seems to be a parser limitation, not a grammar limitation. As currently the macro language guarantees that ty/path expressions can be followed by a "[", this seems like a bug in the parser to me, as it seems to be parsing it as which makes no grammatical sense, compared to parsing it as (value as Type)[index] which should be valid if I read the lexical structure specification correctly.
I think it's parsed correctly, but should get a tailored error message to suggest surrounding the cast with parens.
Considering that a trailing "[" is never valid in the type syntax (otherwise macros break) and the fact that and variants are perfectly legal (even which is another symbol that occurs in type syntax). But if a tailored error message will be made instead, then this should also include other postfix operators like which are currently rejected even though technically being legal by the lexical grammar specification. (another one is the proposed "?" operator)
This is still lacking a tailored error message, and as far as I know no movement has been made here.
Submitted a pull request to fix this!
Thanks!
Change:
/// Some documentation /// # A Heading pub fn a_method(&self) {} <ins> #[cfg(all( feature = "Win32", feature = "Win32_System", feature = "Win32_System_Diagnostics", feature = "Win32_System_Diagnostics_Debug" ))] pub fn lot_of_features() {} </ins> } #[doc(cfg(feature = "foo-method"))]

Discussion:
! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.
Change:
/// out an update in your own time. pub LONG_RUNNING_CONST_EVAL, Deny, <del> "detects long const eval operations" </del> <ins> "detects long const eval operations", report_in_external_macro </ins> } declare_lint! {

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. --Minimum example: I have a full project where I was able to consistently cause this error. It seems to be related to the timeout on constant evaluation. For my project which consistently has the error, check . For some reason, annotating with prevents this error. <!-- 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
cc
I just checked - I was able to cause this error to occur in 1.72 nightly but not in 1.70 stable.
Change:
<ins> #![crate_type = "lib"] pub trait U/*: ?Sized */ { fn modified(self) -> Self where Self: Sized { self } fn touch(&self)/* where Self: ?Sized */{} } pub trait S: Sized {} </ins>

Discussion:
For example  should have a bound, but we're a little too aggressive about pruning out the bounds. For comparison  does indeed have the bound. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This also applies to bounds on traits.
This prompted a question on IRC about whether requires , because the bound is not visible in the libstd documentation. It is visible in the libcore docs though.
Triage: This still happens
This actually ended up biting me today, is there a plan to handle this? I could help implement if I get pointers
did not fix this - it now shows , which is nice, but it doesn't show bounds on traits. For traits it does matter because the default is .
I would start by finding out why this is different between local crates and cross-crate re-exports. I expect is behaving differently from .
Ah, I also hit this today when looking at . Kudos to whoever can figure this one out :)
claim
Change:
<ins> error: unnecessary qualification --> $DIR/unused-qualifications-suggestion.rs:17:5 | LL |     foo::bar(); |     ^^^^^^^^ | note: the lint level is defined here --> $DIR/unused-qualifications-suggestion.rs:3:9 | LL | #![deny(unused_qualifications)] |         ^^^^^^^^^^^^^^^^^^^^^ help: replace it with the unqualified path | LL |     bar(); |     ~~~ error: unnecessary qualification --> $DIR/unused-qualifications-suggestion.rs:21:5 | LL |     baz::qux::quux(); |     ^^^^^^^^^^^^^^ | help: replace it with the unqualified path | LL |     quux(); |     ~~~~ error: aborting due to 2 previous errors </ins>

Discussion:
In the middle of a large refactoring that was mostly automated by rust-analyzer's structural-search-and-replace, I had a lot of qualified paths that shouldn't be qualified. I made do with a regular text-based search-and-replace since I couldn't find a better way, but I think that better way could have been , because introducing an import for the relevant type once per file is much easier than replacing all uses manually. As such, it would be nice if the unnecessary qualification lint had a machine-applicable suggestion attached to it. However, one interesting thing about this is that I also had warnings about the import for that same type being unused. I don't know whether it would be possible with the current compiler infrastructure to create mutually-exclusive suggestions. Either way the suggestion would be helpful, since a simple could disable the automatic removal of the imports.
I second that should be applicable. To fix the violations I almost found and removed the qualified prefix one by one.
Mentoring instructions: Add a new .
Change:
// of its type, and those types are resolved at // the same time. pending_obligation.stalled_on = <del> data.skip_binder() // ok b/c this check doesn't care about regions .input_types() .iter() .map(|t| selcx.infcx().resolve_type_vars_if_possible(t)) .filter(|t| t.has_infer_types()) .flat_map(|t| t.walk()) .filter(|t| match t.sty { ty::TyInfer(_) => true, _ => false }) .collect(); </del> <ins> trait_ref_type_vars(selcx, data.to_poly_trait_ref()); </ins> debug!("process_predicate: pending obligation {:?} now stalled on {:?}", selcx.infcx().resolve_type_vars_if_possible(obligation),

Discussion:
This takes ~2 seconds to type check (according to ): Doubling (respectively, halving) the number of invocations multiplies (resp. divides) the time by 4. It applies to arithmetic in s/s too which is, I imagine, where this will occur most often in practice (it's how I found it). Observations: for , , and , annotating either side (e.g. ) or both sides makes it take only 0.03s and behave linearly (AFAICT) for and : annotating the LHS () reduces the time to ~1.5s, annotating the RHS () reduces it to ~1.1s but both are still quadratic, annotating both takes it to 0.04s and linear it seems to only be dependent on the number of operations in a single function/item, separating the 4 big chunks above across 4 functions reduces the time to ~0.5s. there's no significant difference between using the macro or writing the operations inline (I only use to allow easier experimentation) cc
This must be what's making my old macro-abusing inflate implementation take almost 300 seconds in typeck. It almost sounds like type-checking a function is quadratic over the number of inference variables. Having ran callgrind on the sample and also half of it, I'm seeing the following trace: An unrefined conclusion is that either shouldn't call or should be constant-time.
Is this the same issue as ?
I'm not too familiar with fulfill and infer, but couldn't track the latest snapshot it processed and look at the new information there?
We have exactly for this reason. It doesn't work for some reason tho.
This is the same issue as This is a different issue from (I think I will fix that one separately).
Change:
} /// Cast to a pointer to a different type <del> #[unstable(feature = "ptr_cast", issue = "60602")] </del> <ins> #[stable(feature = "ptr_cast", since = "1.38.0")] </ins> #[inline] pub const fn cast<U>(self) -> *const U { self as _

Discussion:
adds: Like with , the input pointed type does not need to be but the output pointed type does, because we wouldn’t know what appropriate pointer metadata (slice length, trait object vtable, …) to insert. The actual requirement is that the pointer is thin, but is the closest approximation we have (until we add something like ).
Let’s? fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Getting this issue when executing: More detail:
Your Rust installation is out of date.
Change:
let symbol = if value { kw::True } else { kw::False }; (token::Bool, symbol, None) } <del> LitKind::Err => unreachable!(), </del> <ins> // This only shows up in places like `-Zunpretty=hir` output, so we // don't bother to produce something useful. LitKind::Err => (token::Err, Symbol::intern("<bad-literal>"), None), </ins> }; token::Lit::new(kind, symbol, suffix)

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
Reduced: `
Regression in
The assert was in I MENT (sorry, I should no do this on the phone... :roll_eyes: ) cc