jiebi/CodeConvo huggingface dataset:
Change:
<ins> // check-pass pub trait Test { type Item; type Bundle: From<Self::Item>; } fn fails<T>() where T: Test<Item = String>, { } fn main() {} </ins>

Discussion:
Trait bounds on associated types seem to be required, not implied, when the trait in question mentions an associated type on a type parameter. Concretely, this code (or ) produces an error: despite the bound being required by the definition of itself, and in fact this means that the trait can never be mentioned. This similar example () that doesn't use an associated type in the trait parameter compiles: while this version (), which uses a third trait to avoid the self-reference, does not: Is this just a missing normalization step?
Pretty sure I encountered the same bug when specifying an associated type explicitly in a signature.
/cc you wanted to ensure this test case fell into the trait system rewrite.
I've just run into this as well, it seems. Here's a very simple example:

See the testcase here: I'd normally run this by a few people before filing an issue, but #rust is quiet on a Saturday night. ;-) thoughts?
Trait resolution basically doesn't know how to figure out that two types are equal in the case of "dual traits". This is one of the inevitable issues is going to hit in his Servo script bindings refactor I do wish we had a more formalized notion of type families that could be used to better instruct the compiler in these cases. was talking about this in , and I've personally found the need for a family-trait type situation more than once, both when modeling dualities and when modeling generic abstractions over sets of types like you're trying to do.
This appears to work today; E-needstest.
I don't think it works necessarily -- if you remove the bound that highlighted, you still get an error.
The example that expected to pass (and I think he is right that it should) is :
Current output:
Change:
if self.get_toml("metrics", "build"): args.append("--features") args.append("build-metrics") <ins> if self.json_output: args.append("--message-format=json") </ins> if color == "always": args.append("--color=always") elif color == "never":

Discussion:
I think this is one of the reasons (maybe not the only one?) that introducing a build failure in src/bootstrap means that rust-analyzer doesn't show red squigglies in the IDE. Mentoring instructions: add a new flag to around and pass to cargo around if it's set. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc https://rust-
claim
Solving this may also solve
Change:
// 1 == dtor registered, dtor not run // 2 == dtor registered and is running or has run #[thread_local] <del> static mut STATE: $crate::primitive::u8 = 0; </del> <ins> static STATE: $crate::cell::Cell<$crate::primitive::u8> = $crate::cell::Cell::new(0); // Safety: Performs `drop_in_place(ptr as *mut $t)`, and requires // all that comes with it. </ins> unsafe extern "C" fn destroy(ptr: *mut $crate::primitive::u8) { <del> let ptr = ptr as *mut $t; unsafe { $crate::debug_assert_eq!(STATE, 1); STATE = 2; $crate::ptr::drop_in_place(ptr); } </del> <ins> $crate::thread::local_impl::abort_on_dtor_unwind(|| { let old_state = STATE.replace(2); $crate::debug_assert_eq!(old_state, 1); // Safety: safety requirement is passed on to caller. unsafe { $crate::ptr::drop_in_place(ptr.cast::<$t>()); } }); </ins> } unsafe { <del> match STATE { </del> <ins> match STATE.get() { </ins> // 0 == we haven't registered a destructor, so do //   so now. 0 => {

Discussion:
Miri detects UB when running the following program: With and With
I see the bug. We have (which means fns in std automatically trap aborts) but that doesn't apply to functions which are present in the macro expansion (some of which can't really be moved outside the macro). Ill fix in like an hour or two. We just need to guard panics in a couple places. In practice I think this should not call problems and we'd just hit an abort guard in an defined in a few frames up, although perhaps that's not true in 100% of cases (I can update on this once I implement the fix).
The is that the fix to this may need to be backported thus I am tagging this with P-high.
the fix was merged and a backport was rejected:
Change:
<ins> // Copyright 2014 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. trait Tr<T> { fn op(T) -> Self; } // these compile as if Self: Tr<U>, even tho only Self: Tr<Self or T> trait A:    Tr<Self> { fn test<U>(u: U) -> Self { Tr::op(u)   //~ ERROR expected Tr<U>, but found Tr<Self> } } trait B<T>: Tr<T> { fn test<U>(u: U) -> Self { Tr::op(u)   //~ ERROR expected Tr<U>, but found Tr<T> } } impl<T> Tr<T> for T { fn op(t: T) -> T { t } } impl<T> A for T {} fn main() { std::io::println(A::test((&7306634593706211700, 8))); } </ins>

Discussion:
(sorry about the bad title but I really have no clue what's going on here!) Compiles and prints . I think it's getting at the of the inside a . edit: As one might expect, does not compile.
Seems rather bad. cc
Nominating.
This is a fun bug, it's by far not limited to the operator. I tried to reduce the test case a bit, starting with a new non-operator trait, changed it to a static method that just returns for inference, and...
cc me
Assigning 1.0, P-backcompat-lang.
Even smaller:
Change:
<ins> error[E0308]: mismatched types --> $DIR/E0308-2.rs:9:6 | LL | impl Eq for &dyn DynEq {} |      ^^ lifetime mismatch | = note: expected trait `std::cmp::PartialEq` found trait `std::cmp::PartialEq` note: the lifetime `'_` as defined on the impl at 9:13... --> $DIR/E0308-2.rs:9:13 | LL | impl Eq for &dyn DynEq {} |             ^ = note: ...does not necessarily outlive the static lifetime error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
Causes the following error: This is somewhat confusing, especially since is not a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This looks similar to what I reported in
Here we don't account for anything other than type mismatches which means that later we use the generic prefix We need to account for in the first snippet and ferry the prefix strings from there to the later (instead of what we do now).
I'd like to work on this claim
do not hesitate to reach out if you need help!
Do we need to get the correct prefix strings from the contents of or are they just ?
I believe they can be just "trait".
Change:
<del> Subproject commit f2b0c67661f19bb2564225d47aca424ad0449791 </del> <ins> Subproject commit 48818e9f5d0f2d5978a9b43ad1a2e8d0b83f6aa0 </ins>

Discussion:
Any crate that uses fails to compile with a link error saying Test case on outputs: or from a bigger project: Nightly / works totally fine.
Is this reproducible after ?
Yes, happens on a fresh project I made for testing () and after
is the full commit range, which notably includes an LLVM upgrade -- cc Could you check with if is fine and is broken for you?
I can confirm that works fine but is broken. Also, that's a nifty tool.
Okay, LLVM update is then definitely at fault, cc
With default settings I'm not reproducing this locally with on . Do you have any rustflags set in your cargo config or environment variable? What is the full output of ?
Here is the full failing output from <details</detailsIndeed, my are set to Testing again without does not error, and compiles/runs fine.
If it helps, I'm on AMD Zen v1, or , and it looks like was introduced in the LLVM upgrade.
Fails the same way on Linux (GNU and musl) and Windows GNU using on Ryzen 2700X platform so it probably affects all the OSes. <details<summaryDetails</summary</details modify labels: -E-needs-bisection -O-windows-msvc +O-linux +O-windows +A-LLVM
This seems like LLVM's auto-detection of what CPU is on the host or what the target features your native CPU has may be broken. The next step for this is to probably use a build of Clang to reproduce and then report this upstream to LLVM itself.
Er sorry I have a guess as to where this is but I do not have time to investigate this right now, so I'm going to unassign myself since I can't take care of this.
Minimised: IR: I cannot build Clang/LLVM from master right now so I'm attaching IR from my code above. I'll try to find time tomorrow or somewhere next week.
Confirming that produces a call instead of a under .
I believe the cause is that the znver feature spec is missing (the 16B variant is listed).
LLVM bug reported at
Change:
match allow_c_variadic { AllowCVariadic::Yes => TyKind::CVarArgs, AllowCVariadic::No => { <del> // FIXME(Centril): Should we just allow `...` syntactically </del> <ins> // FIXME(c_variadic): Should we just allow `...` syntactically </ins> // anywhere in a type and use semantic restrictions instead? <ins> // NOTE: This may regress certain MBE calls if done incorrectly. </ins> let guar = self .dcx() .emit_err(NestedCVariadicType { span: lo.to(self.prev_token.span) });

Discussion:
<!-- [31mICE[0m: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: should have been handled elsewhere', 'error: internal compiler error: should have been handled elsewhere' 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: --
also repros with or with 2015 if you remove the :)
Regression in nightly-2020-12-20 fetching (via remote github) commits from max(, 2020-12-17) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 9 commit[0] 2020-12-18: Auto merge of - ehuss:update-cargo, r=Mark-Simulacrum commit[1] 2020-12-18: Auto merge of - GuillaumeGomez:str-to-symbol, r=jyn514 commit[2] 2020-12-19: Auto merge of - mibac138:fn-fat-arrow-return, r=davidtwco commit[3] 2020-12-19: Auto merge of - davidtwco:issue--const-param-attrs, r=lcnr commit[4] 2020-12-19: Auto merge of - JohnTitor:rollup-a31s996, r=JohnTitor commit[5] 2020-12-19: Auto merge of - jackh726:binder-refactor-part-2, r=lcnr commit[6] 2020-12-19: Auto merge of - CDirkx:ipaddr-const, r=oli-obk commit[7] 2020-12-19: Auto merge of - matthewjasper:revert-eval-order, r=nikomatsakis commit[8] 2020-12-19: Auto merge of - Nadrieril:usefulness-merging, r=varkor
This is also kinda bad because rustc does not tell you what you did wrong (theres no error shown) mvce:
very likely
Change:
<ins> // run-pass #![warn(disjoint_capture_drop_reorder)] fn main() { if let a = "" { //~^ WARNING: irrefutable `if let` pattern drop(|_: ()| drop(a)); } } </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. --Removing allows the code to compile successfully. <!-- 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 --<!-- TRIAGEBOT_END --
cc
I dont have too much context on how type folding works, but my guess is we are calling fold sooner that we should. I have this to the for RFC 2229, I'll bring it up during our sync tomorrow.
We want to use .
assign
Error: Parsing assign command in failed: ...'bot assign' ''... Please let know if you're having trouble with this bot.
claim
Thanks
Change:
<ins> error[E0261]: use of undeclared lifetime name `'missing` --> $DIR/dont-ice-on-object-lookup-w-error-region.rs:6:20 | LL | fn project(x: Pin<&'missing mut dyn Future<Output = ()>>) { |           -        ^^^^^^^^ undeclared lifetime |           | |           help: consider introducing lifetime `'missing` here: `<'missing>` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0261`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: self-type for ObjectPick never dereferenced to an object', 'error: internal compiler error: self-type for ObjectPick never dereferenced to an object' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [typeck] type-checking [analysis] running analysis passes on this crate --
bisects to cc
Change:
<ins> // Copyright 2018 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. // run-rustfix // edition:2018 // compile-pass // aux-build:remove-extern-crate.rs #![warn(rust_2018_idioms)] extern crate core; extern crate core as another_name; use remove_extern_crate; #[macro_use] extern crate remove_extern_crate as something_else; fn main() { another_name::mem::drop(3); another::foo(); remove_extern_crate::foo!(); bar!(); } mod another { extern crate core; use remove_extern_crate; pub fn foo() { core::mem::drop(4); remove_extern_crate::foo!(); } } </ins>

Discussion:
Migrated from It's been mentioned/requested multiple times on the that should remove the statements when moving to Rust 2018. One of the big draws of Rust 2018's module system is that all of the "redundant" lines can finally be removed. It took some of the excitement away when I went through all of the steps and still saw them there. I think it will just be a better experience for users to see one of the tangible benefits of this change. As it is right now, they just see the in front of all of their local imports and they might not realize what a nice change the module system updates really are. After I manually removed the 's I did get my satisfying result , but let's give this to users on the first go around. If I understand correctly this should be implemented in the compiler under the lints, rather than itself. cc
I'm moving this forward up on the milestone list due to just having closed in favor of this issue, which was itself on the RC milestone.
Ok so I've some triaging of related lint issues, and I believe the current work items are: A rustfix-fixable suggestion for removing needs to be implemented. The implementation would . Currently the lint suggests switching to simply . While technically correct and handles lots of corner cases, this doesn't achieve the desired goal of actually removing annotations. We can't blanket remove all statements, for example is correctly warned to use a rather than deleting the statement outright. I'm testing out some ideas locally as well.
I believe this should be fixed by , I think the naive solution actually works well!
Change:
LL |         Dog { .. } => {} |             ^^^^^^ <del> error: aborting due to 2 previous errors </del> <ins> error: aborting due to 4 previous errors </ins> For more information about this error, try `rustc --explain E0027`.

Discussion:
I tried this code: I expected to see this happen: A suggestion to change to Instead, this happened: A suggestion to change to (note the extra comma!) With the comma at the end, I get a parser error and a suggestion to remove the comma. Nightly on playground: 1.49.0-nightly (2020-10-27 )
modify labels: +A-diagnostics
Change:
} /// When encountering an fn-like type, try accessing the output of the type <del> /// // and suggesting calling it if it satisfies a predicate (i.e. if the </del> <ins> /// and suggesting calling it if it satisfies a predicate (i.e. if the </ins> /// output has a method or a field): /// ```compile_fail,E0308 /// fn foo(x: usize) -> usize { x }

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --should suggest if the argument is a closure instead of suggesting to call the closure Given the following code: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This probably can be generalized if the code is written carefully enough.
Do you mean, we should handle other types like which may use with a closure?
I know nothing about the internals of rustc diagnostics but a general way would be to check if a similar method in name accepts a closure and suggest that first, if nothing similar can be found then suggest calling the closure
I mean something more like what is suggesting, where you check if exists whose signature is compatible with a closure. But that requires doing a method probe, then doing some delicate logic to check argument compatibility.
Change:
Region(ty::EarlyBoundRegion), } <ins> /// Returns the list of parameters that are constrained by the type `ty` /// - i.e. the value of each parameter in the list is uniquely determined /// by `ty` (see RFC 447). </ins> pub fn parameters_for_type<'tcx>(ty: Ty<'tcx>) -> Vec<Parameter> { <del> ty.walk() .flat_map(|ty| parameters_for_type_shallow(ty)) .collect() </del> <ins> let mut result = vec![]; ty::maybe_walk_ty(ty, |t| { if let ty::TyProjection(..) = t.sty { false // projections are not injective. } else { result.append(&mut parameters_for_type_shallow(t)); // non-projection type constructors are injective. true } }); result </ins> } pub fn parameters_for_trait_ref<'tcx>(trait_ref: &ty::TraitRef<'tcx>) -> Vec<Parameter> {

Discussion:
You can create an inherent impl where the impl substs are not constrained by the impl signature. If the parameters are constrained by the method signature, you can even get code that usefully runs (otherwise you get "can't resolve" errors): Note that you need to use UFCS notation to avoid (which is an issue with method lookup). RFC447 is silent with regards to this issue, but this allows you to create an impl that is not resolvable by its trait-ref.
cc
Heh, I was just telling in IRC the other day that this case was broken. I agree, the current logic is too simplistic (it's also something I've been writing up in this RFC I keep talking about...). Basically, it currently considers all input/type parameters which appear as constrianed, but it ought to stop at projections. I made this gist, which is a similar example:
To be clear, I don't think that fixing this issue requires an RFC (it's just a bug, I think). I just meant that I was writing up various text that referenced the notion of "constrained type parameters" and tried to give a definition, which is how I realized this problem.
Change:
/// set.retain(|&k| k % 2 == 0); /// assert!(set.iter().eq([2, 4, 6].iter())); /// ``` <del> #[unstable(feature = "btree_retain", issue = "79025")] </del> <ins> #[stable(feature = "btree_retain", since = "1.53.0")] </ins> pub fn retain<F>(&mut self, mut f: F) where T: Ord,

Discussion:
This is a tracking issue for and (part of rust-lang/rfcs). The feature gate for the issue is . [x] Implement the RFC [x] FCP [ ] Adjust documentation [ ] Stabilization PR Is the performance of the current implementation (based on ) good enough to be useful? Concern raised in . Initial implementation:
We discussed this in today's meeting. We'd like to see a comment documenting the performance characteristics of this (as well as a corresponding update to ), and suggesting that this might not be what you want if you're removing a substantial number of elements. Beyond that documentation, though, we'd be happy to see this stable. 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.
Change:
<del> Subproject commit f76225e3887170743403af9204887918b5db5a80 </del> <ins> Subproject commit 1f6e2a63d89e485df6a3ee9df3e8ffbfddf26330 </ins>

Discussion:
branch: master Compiling cargometadata v0.2.3 Compiling clippylints v0.0.166 (file:///home/ryan/git/rust/src/tools/clippy/clippylints) error: :vis fragment specifier is experimental and subject to change (see issue ) --<declarelint macros:1:3 | 1 | ( NAME : ident , desc : expr ) =( | ^^^^^^^^^^^ | = help: add #![feature(macrovismatcher)] to the crate attributes to enable error: :vis fragment specifier is experimental and subject to change (see issue ) --<declarelint macros:1:3 | 1 | ( NAME : ident , desc : expr ) =( | ^^^^^^^^^^^ | = help: add #![feature(macrovismatcher)] to the crate attributes to enable error: aborting due to previous error error: aborting due to previous error error: Could not compile . warning: build failed, waiting for other jobs to finish... error: Could not compile . warning: build failed, waiting for other jobs to finish... error: build failed This failure is expected (see ) Build completed successfully in 1:46:49
Everything is actually fine, as you can see by the last two lines of the log. I hope to remove the error log if the failure is expected in the future, but not sure yet how best to do that.
Is it related to rust-lang-nursery/rust-clippy?