jiebi/CodeConvo huggingface dataset:
Change:
|                ---  ^^^ not a trait |                | |                found this type parameter <del> | help: consider importing this trait instead | LL + use std::ops::Add; | </del> error: aborting due to 1 previous error

Discussion:
(A better title would be appreciated) I like this part: It could have a suggestion like , especially because are very close to each other on a US keyboard and could very well be a typo. Applying the suggestion will result in a compile error. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think the label might be fitting as well.
Error: Parsing assign command in failed: ...' claim' ' +D-invali'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Change:
<ins> // compile-flags: -Zsave-analysis #![feature(const_generics)] #![allow(incomplete_features)] struct Arr<const N: usize> where Assert::<{N < usize::max_value() / 2}>: IsTrue, //~ ERROR constant expression { } enum Assert<const CHECK: bool> {} trait IsTrue {} impl IsTrue for Assert<true> {} fn main() { let x: Arr<{usize::max_value()}> = Arr {}; //~^ ERROR mismatched types //~| ERROR mismatched types } </ins>

Discussion:
I got a little excited with merged, soooo I gave it a try, and I found this rather funny ICE. Notice how I call , without a type parameter, while the function expects a type parameter. <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
yeah, that ICE is interesting :thinking: and why is it only triggered with ? claim

() Errors: Probably related: Removing (at least) one of the s for makes the panic go away, and the compiler correctly reports the error: modify labels: I-ICE, T-compiler, A-const-eval, A-const-generics, C-bug, F-const_generics, requires-nightly
That's happening here: I don#t think there is a meaningful way to evaluate a polymorphic constant, so either some code earlier screwed up to even get so far, or we need to throw here. Cc
cc This ICE is totally expected. Using features that emit the lint are expected to ICE, otherwise they would not emit said lint. The const evaluator is not at fault here, there's just no way to evaluate this.
hmm, we shouldn't try to evaluate this constant here or at least have it be a instead of a . Not quite sure what's going on here, will have to look at it in more detail soon
So we probably fail here because we call with a which get's canonicalized to a . All of that seems correct to me :thinking: Is it possible that we should treat similar to and "just" return here?

<!-- 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. --Code from glacier: <!-- 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
NB: Only panics for me with the flag.
Change:
<ins> // Copyright 2013 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. // check that the derived impls for the comparison traits shortcircuit // where possible, by having a type that fails when compared as the // second element, so this passes iff the instances shortcircuit. pub struct FailCmp; impl Eq for FailCmp { fn eq(&self, _: &FailCmp) -> bool { fail!("eq") } } impl Ord for FailCmp { fn lt(&self, _: &FailCmp) -> bool { fail!("lt") } } impl TotalEq for FailCmp { fn equals(&self, _: &FailCmp) -> bool { fail!("equals") } } impl TotalOrd for FailCmp { fn cmp(&self, _: &FailCmp) -> Ordering { fail!("cmp") } } #[deriving(Eq,Ord,TotalEq,TotalOrd)] struct ShortCircuit { x: int, y: FailCmp } fn main() { let a = ShortCircuit { x: 1, y: FailCmp }; let b = ShortCircuit { x: 2, y: FailCmp }; assert!(a != b); assert!(a < b); assert!(!a.equals(&b)); assert_eq!(a.cmp(&b), ::std::cmp::Less); } </ins>

Discussion:
As seen in , when running the tests on Windows there are slightly different things in scope than when the tests are run normally. per
see also
Part of .
Closing, removed check-fast
Change:
hir::TraitItemKind::Type(ref bounds, ref default) => { self.print_associated_type( ti.ident, <ins> &ti.generics, </ins> Some(bounds), default.as_ref().map(|ty| &**ty), );

Discussion:
The following code: is pretty printed as This presumably also affects procedural macros.
Are there tests intended for pretty printing? I got the impression that folder only tests specific features and bugs, not the form
Change:
<ins> // Regression test for #85794 struct Baz { inner : dyn fn () //~^ ERROR expected `,`, or `}`, found keyword `fn` //~| ERROR functions are not allowed in struct definitions //~| ERROR cannot find type `dyn` in this scope } fn main() {} </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</details
This regressed in , which is a rollup. Luckily is the only real candidate though. The panic that gets called is this one: From a quick scan of a result gets dropped here : cc searched nightlies: from nightly-2021-05-07 to nightly-2021-05-29 regressed nightly: nightly-2021-05-09 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
Mhh, I don't even remember why I this call to in the first place, maybe to consume the fn body and get fewer/cleaner errors? Should have a comment... Anyway fixing this should be easy, we can (or ) the error, or remove the call to .
Change:
<ins> error[E0029]: only `char` and numeric types are allowed in range patterns --> $DIR/issue-88074-pat-range-type-inference-err.rs:11:9 | LL |         Zero::ZERO ..= Zero::ZERO => {}, |         ----------^^^^^---------- |         |              | |         |              this is of type `String` but it should be `char` or numeric |         this is of type `String` but it should be `char` or numeric error[E0282]: type annotations needed --> $DIR/issue-88074-pat-range-type-inference-err.rs:19:9 | LL |         Zero::ZERO ..= Zero::ZERO => {}, |         ^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type | = note: type must be known at this point error: aborting due to 2 previous errors Some errors have detailed explanations: E0029, E0282. For more information about an error, try `rustc --explain E0029`. </ins>

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).
Change:
} } <ins> fn doc_alias_str_error(&self, meta: &NestedMetaItem) { self.tcx .sess .struct_span_err( meta.span(), "doc alias attribute expects a string: #[doc(alias = "0")]", ) .emit(); } </ins> fn check_doc_alias(&self, attr: &Attribute, hir_id: HirId, target: Target) -> bool { if let Some(mi) = attr.meta() { if let Some(list) = mi.meta_item_list() { for meta in list { if meta.has_name(sym::alias) { <del> if !meta.is_value_str() || meta .value_str() .map(|s| s.to_string()) .unwrap_or_else(String::new) .is_empty() </del> <ins> if !meta.is_value_str() { self.doc_alias_str_error(meta); return false; } let doc_alias = meta.value_str().map(|s| s.to_string()).unwrap_or_else(String::new); if doc_alias.is_empty() { self.doc_alias_str_error(meta); return false; } if let Some(c) = doc_alias.chars().find(|&c| c == '"' || c == ''' || c.is_whitespace()) </ins> { self.tcx .sess .struct_span_err( meta.span(), <del> "doc alias attribute expects a string: #[doc(alias = "0")]", </del> <ins> &format!( "{:?} character isn't allowed in `#[doc(alias = "...")]`", c, ), </ins> ) .emit(); return false;

Discussion:
From this comment: Still remaining the .
Actually, the character has a meaning in the search (for "exact" search). But instead of just removing it, maybe we should instead emit an error when we encounter it. What do you think ?
That doesn't work for though, maybe it should? It would make sense to restrict allowed characters because even whitespace is allowed at the moment which seems questionable.
It sounds like we need to make sure this lands before we branch beta or so?
Let's forbid , whitespaces and tabs in the the doc alias then.
Can we avoid ad-hoc rules and say something like "must be a rust identifier"?
Even better! Great suggestion !
Just thought about it, but it cannot be the case : we allow things like "*" or "+" (for the traits for example), so it cannot be ident only. I'll stick to the listed characters above.
The documentation () has no mention of that -- can you elaborate?
Doc aliases can be something else than a rust identifier. For example, you can look for or in the std docs, and you'll see aliases results.
Ah, I see what you mean. Okay, then I agree that we need more than just Rust identifiers, and it might be reasonable to just allow as you suggest -- everything except whitespace and quotes. I'm a bit worried that'll hurt us in terms of how expansive it is but it's probably fine.
I don't expect attributes to be used widely, so we should be fine. ;)
Is there more justification for removing whitespace support other than calling the characters questionable? If I have a struct or a function that implements an algorithm, I would like to alias the item to the plaintext name of the algorithm, for example .
I just had in mind "idents", so no whitespace in them. However I don't see any reason to not allow specfically. I'll send a PR tomorrow.
rustdoc only being ident-centric is .
path-centric would be more accurate. ;)
Change:
}); }); }); <ins> // Check that the current type is indeed a type, if we have an anonymous impl if opt_trait_reference.is_none() { match self_type.node { // TyPath is the only thing that we handled in `build_reduced_graph_for_item`, // where we created a module with the name of the type in order to implement // an anonymous trait. In the case that the path does not resolve to an actual // type, the result will be that the type name resolves to a module but not // a type (shadowing any imported modules or types with this name), leading // to weird user-visible bugs. So we ward this off here. See #15060. TyPath(ref path, _, path_id) => { match self.def_map.borrow().find(&path_id) { // FIXME: should we catch other options and give more precise errors? Some(&DefMod(_)) => { self.resolve_error(path.span, "inherent implementations are not  allowed for types not defined in  the current module."); } _ => {} } } _ => { } } } </ins> } fn check_trait_item(&self, ident: Ident, span: Span) {

Discussion:
The code <pretrait T {} impl&lt;U: T&gt; Vec&lt;U&gt; {} fn main() { let r = Vec::fromslice(&[1u]); } </prefails with 4:36 error: unresolved name . fn main() { let r = Vec::from_slice(&[1u]); } </preRemoving the <codeimpl</codeline causes the code to compile fine. Thx Ms2ger for finding such a small example case.
I think this is related to anonymous modules appearing, resolves to a module due to the impl. If you change to this you get another interesting error:
Note that a workaround is to wrap in parens, as Then you get the correct error message about trying to on a type outside of its crate.
I've spent some time investigating this bug and I think that the cleanest thing to do is to (closed B-RFC right now, does anyone have a link to a relevant RFC?) and require to occur only in the same module as, and after, the definition of . This check would be done before creating the anonymous trait module with name . Otherwise in the case of where a definition of is not visible, is not resolved until typeck (at which point the compiler will complain if is defined outside the current crate, or not at all), but if there are resolve errors like the current bug, these will be exposed to the user first and halt compilation. The current behaviour upon encountering where has not been defined in the current module is to create a module (which shadows any other modules exposed by statements) and try to resolve any symbols into this module. This means that the current support for outside of the module is defined in is <ialready</ibroken. Consider for example will error out with "unresolved name ". I'm sure I could come up with other examples of currently broken behaviour like this.
the closing of that bug predates our RFC process, so there would not be a link to an RFC.
Interestingly, this breaks in the opposite direction if you qualify the :
My suggestion is that should be disallowed. I will submit an RFC with these changes.
Change:
fn all_impls(&self, trait_def_id: ast::DefId) -> Vec<ast::DefId> { /*! <del> * Returns se tof all impls for a given trait. </del> <ins> * Returns set of all impls for a given trait. </ins> */ ty::populate_implementations_for_trait_if_necessary(self.tcx(),

Discussion:
This code: generates this error: I couldn't find any existing issue on this, but this is expected to work, right?
cc
Was this in an RFC?
DST was pre-RFC (the design anyway), so no, it was not.
It as a good question whether this is supposed to work or not. Since traits are types now, just unsized, I would say "yes". But since an impl for a trait is no different to just providing default methods, perhaps we want to avoid that overlap. Shouldn't be hard to fix if we all agree on "yes", but cc to check he agrees.
As I understand it, an for a trait would be quite different than providing default methods: Even when a trait object is formed, there's no dynamic dispatch (vtable entries) for these methods. The methods cannot be overridden in an . The methods may also exist on the trait, in which case (according to our dispatch rules) the inherent versions would take precedence. I think the closer correspondence is to creating an extension trait with a blanket -- and given that inherent s are in some sense supposed to be equivalent to "anonymous", always-in-scope extension traits, I think that makes sense. My guess is that this was an intended, but implicit part of the DST proposal, but can speak more directly to that.
These subtle differences make me want it less. But the blanket impl-like use case seems legitimate. I agree with the intended but implicit assessment - I vaguely remember this coming up as a use case at some point
I've always assumed this would work but I'm curious was there a specific point in the libraries that required it?
IIRC this came out of playing around with the method definitions, which are currently all provided by extension traits. Not a huge deal if we can't do this for 1.0.
I started looking at this, but the hard bits seem to be some adjustment to method selection, so I'll wait on landing before doing this
I think there is some serious utility in providing this, especially for things like Any. I will try to dig up some other use-cases. Note that since is currently marked adding this later would mean deprecations etc.
Change:
fn sub(self, other: &SteadyTime) -> Duration { let diff = self.t as i64 - other.t as i64; <del> Duration::microseconds(diff * 1_000_000 / frequency() as i64) </del> <ins> Duration::nanoseconds(mul_div_i64(diff, NANOS_PER_SEC, frequency() as i64)) </ins> } } <ins> // Computes (value*numer)/denom without overflow, as long as both // (numer*denom) and the overall result fit into i64 (which is the case // for our time conversions). fn mul_div_i64(value: i64, numer: i64, denom: i64) -> i64 { let q = value / denom; let r = value % denom; // Decompose value as (value/denom*denom + value%denom), // substitute into (value*numer)/denom and simplify. // r < denom, so (denom*numer) is the upper bound of (r*numer) q * numer + r * numer / denom } #[test] fn test_muldiv() { assert_eq!(mul_div_i64( 1_000_000_000_001, 1_000_000_000, 1_000_000),  1_000_000_000_001_000); assert_eq!(mul_div_i64(-1_000_000_000_001, 1_000_000_000, 1_000_000), -1_000_000_000_001_000); assert_eq!(mul_div_i64(-1_000_000_000_001,-1_000_000_000, 1_000_000),  1_000_000_000_001_000); assert_eq!(mul_div_i64( 1_000_000_000_001, 1_000_000_000,-1_000_000), -1_000_000_000_001_000); assert_eq!(mul_div_i64( 1_000_000_000_001,-1_000_000_000,-1_000_000),  1_000_000_000_001_000); } </ins>

Discussion:
The of uses a 64 bit multiplication that will overflow frequently. Using floats would be the easy way out, but it would reduce precision to 53 bits.
As a datapoint, this is literally what . Where is a . But we're multiplying by an extra 1000.
In fairness to Microsoft, they're operating on a time difference computed mod 2^64, so as long as the interval length is reasonable (less than a few thousand hours for a typical tick rate) it can't overflow. But computes an absolute time rather than a difference, so overflows are guaranteed to happen at some point. The 1000x factor only makes it more noticeable.
Since we're dealing with absolute time (and therefore something large), it's probably not unreasonable to divide first, or maybe even partially multiply by . Something like: maybe? What are "typical" and "extreme" tick rates and absolute ticks like? An incredibly robust implementation could presumably branch on the size of ticks to determine the optimal split of the .
The x86_64 architecture has the 64 bit MUL instruction whose result is effectively a 128 bit integer which never overflows. Likewise, the DIV instruction takes an effectively 128 bit integer as the dividened. i386 offers (u32, u32) -u64 MUL and (u64, u32) -(u32, u32) DIV/MOD, so we should be able to implement 64 bit MUL and DIV without overflow. Windows RT runs on ARMv7 (=~ Cortex-A). It has (u32, u32) -u64 UMULL but lacks DIV and we have to call a division routine. Perhaps we can forget about it for now...
We could use techniques similar to . Of course, in this case, we also have the multiplier, which together with the "magic constant" is going to overflow even a 128 bit register, but multiplication can be done "in parts".
Don't OSX and iOS have a similar problem and ? What is the typical value of seems to suggest that is can be large, just like on Windows.
^
Change:
<del> // failure-status: 101 // rustc-env:RUST_BACKTRACE=0 // normalize-stderr-test "note: .*nn" -> "" // normalize-stderr-test "thread 'rustc' panicked.*n" -> "" // compile-flags: --crate-type=rlib // Regression test for https://github.com/rust-lang/rust/issues/78450 #![feature(min_type_alias_impl_trait)] #![no_std] pub trait AssociatedImpl { type ImplTrait; fn f() -> Self::ImplTrait; } struct S<T>(T); trait Associated { type A; } // ICE impl<'a, T: Associated<A = &'a ()>> AssociatedImpl for S<T> { type ImplTrait = impl core::fmt::Debug; fn f() -> Self::ImplTrait { //~^ ERROR unexpected concrete region in borrowck: ReEarlyBound(0, 'a) () } } </del>

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. --Minimized: also occurs for but not <!-- 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. --: also on Rust Playground <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Somehow I missed that this does not require async. Also crashes with and returning .
minimized:
-- the minimization no longer ICEs for me
-- this sure looks like a dup of
After a discussion with Niko about this and assigning to myself we saw that there's already a PR. Unassigning myself then :).
Change:
<ins> trait FromResidual<R = <Self as Try>::Residual> { fn from_residual(residual: R) -> Self; } trait Try { type Residual; } fn w<'a, T: 'a, F: Fn(&'a T)>() { let b: &dyn FromResidual = &(); //~^ ERROR: the trait `FromResidual` cannot be made into an object //~| ERROR: the trait `FromResidual` cannot be made into an object } fn main() {} </ins>

Discussion:
rustc crashes on the following input, found by :
searched nightlies: from nightly-2022-02-10 to nightly-2022-10-26 regressed nightly: nightly-2022-08-13 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This regressed in , specifically in . cc
Minimized:
This no longer ICEs, afaict.
According to , this got fixed in one of these commits: found 7 bors merge commits in the specified range commit[0] 2023-01-08: Auto merge of - GuillaumeGomez:rustdoc-gui-retry-mechanism, r=Mark-Simulacrum commit[1] 2023-01-08: Auto merge of - geeklint:loosenweakdebug_bound, r=dtolnay commit[2] 2023-01-09: Auto merge of - compiler-errors:rollup-emcj0o3, r=compiler-errors commit[3] 2023-01-09: Auto merge of - compiler-errors:better-spans-on-bad-tys, r=lcnr commit[4] 2023-01-09: Auto merge of - saethlin:propagate-operands, r=oli-obk commit[5] 2023-01-09: Auto merge of - aliemjay:astconv-normalize, r=lcnr commit[6] 2023-01-09: Auto merge of - fee1-dead-contrib:rollup-ticvmsd, r=fee1-dead ERROR: no CI builds available between and within last 167 days