jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // check-pass #![feature(associated_type_defaults)] use std::io::Read; trait View { type Deserializers: Deserializer<Item = Self::RequestParams>; type RequestParams = DefaultRequestParams; } struct DefaultRequestParams; trait Deserializer { type Item; fn deserialize(r: impl Read) -> Self::Item; } fn main() {} </ins>

Related discussion:
text: <!-- 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
It looks like it's correctly complied on rustc 1.48.0-nightly:
I dont think this should compile at all. After all, we cause UB, the value of the const generic does not comply with the rules of .
A str being valid utf-8 is not a language invariant, so this should not be UB to my knowledge. cc I do expect this to be the correct behavior, so marking as
We do have to compare the s to check for equality though, which might cause library ub so :shrug:
I think you are free to decide on your own invariant here -- assuming that two are equal if and only if the underlying are equal, it's your call whether you want to allow non-UTF-8 in types or not. What is the plan for other library types? Like, imagine a user defined a newtype around that must be even. The compiler cannot even know that such an invariant exists so it cannot be enforced. Equality checking anyway happens by comparing the underlying bytes. So if we follow that analogy, the non-UTF-8 should be fine, but we have to make sure that we use the right notion of equality.
:+1: yeah, see for more details here I guess One concern is that we probably want to print s in and in encodings, so we need to either deal with invalid utf there or forbid it entirely :thinking: Will have to keep that in mind before stabilizing parameters.
Yeah, you could either use (so any special treatment of is confined to the printing code) or make a very special compiler-understood type even for the type system itself (and reject non-UTF-8 strings early). The former seems more principled to me but that is just a slight preference.
Code change:
<ins> // check-pass #![feature(associated_type_defaults)] use std::io::Read; trait View { type Deserializers: Deserializer<Item = Self::RequestParams>; type RequestParams = DefaultRequestParams; } struct DefaultRequestParams; trait Deserializer { type Item; fn deserialize(r: impl Read) -> Self::Item; } fn main() {} </ins>

Related discussion:
text: won't work for symbol mangling, as otherwise two distinct types can have the same symbol: (current ICE is unrelated, as const generics is not yet fully supported there) Printing invalid utf8 as bytes might be simpler there :thinking: I guess cc about that
Oh, this is not just pretty-printing but needs to be injective? Then I guess some or so (for "invalid") would work.
Code change:
ty::Ref(..) | ty::RawPtr(_) => { return self.field(cx, index).llvm_type(cx); } <del> ty::Adt(def, _) if def.is_box() => { </del> <ins> // only wide pointer boxes are handled as pointers // thin pointer boxes with scalar allocators are handled by the general logic below ty::Adt(def, substs) if def.is_box() && cx.layout_of(substs.type_at(1)).is_zst() => { </ins> let ptr_ty = cx.tcx.mk_mut_ptr(self.ty.boxed_ty()); return cx.layout_of(ptr_ty).scalar_pair_element_llvm_type(cx, index, immediate); }

Related discussion:
text: While working on , I've run into the following ICE. On further consideration, the issue also appears with as long as is non zero sized. This ICE was likely not encountered during testing of because in the case of , is zero sized. In the example below, removing the borrow of will cause the compilation to succeed. could you take a look at this? :) cc you may run into this as well on <!-- 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<pFrom playground </p</details
This ice is still showing up in . We are using it over in in embedded programming to allocate from heaps located on externally mounted sdram.
Vec is not affected by this, and can even be used to get a Box. This code did not ICE on playground.
Interestingly, trying to print the Box created in that way gives the same ICE as
Hello, I get this error in two flavor: By ref: Produce the following: Without ref: Cause: Where does implement both and traits.
I'm hitting this issue too, on code that basically equates to this: Seems like there are plenty of ways to reproduce this in here, but if a minimal test case is needed, I would be happy to try to provide one. I just made a repro, wasn't really that tricky.
As far as I understand it, the issue is as follows: std is special cased, it has the attribute This corresponds to , which returns true if the type as been annotated to be a Somewhere, some code which uses makes an assumption that such a box data type only contains one field, the inner pointer itself. This causes the allocator struct field to be removed. This breaks when there is a non ZST allocator field that needs to be accessed in generated code. I'm guessing this might be related to the special deref move semantics for boxes?
Code change:
ty::Ref(..) | ty::RawPtr(_) => { return self.field(cx, index).llvm_type(cx); } <del> ty::Adt(def, _) if def.is_box() => { </del> <ins> // only wide pointer boxes are handled as pointers // thin pointer boxes with scalar allocators are handled by the general logic below ty::Adt(def, substs) if def.is_box() && cx.layout_of(substs.type_at(1)).is_zst() => { </ins> let ptr_ty = cx.tcx.mk_mut_ptr(self.ty.boxed_ty()); return cx.layout_of(ptr_ty).scalar_pair_element_llvm_type(cx, index, immediate); }

Related discussion:
text: Is the case where the compiler should call for the for the box in the case where a deref move is performed even handled correctly as is today?
It seems that is the one that developed the feature, in He had been warned of the incomming issue, , and opt for a "workaround", can you give us more information about the problem you , the workaround you choose, any hint for why it isn't working, and maybe give us possible path to explore ?
Code change:
fn main() { static foo: Fn() -> u32 = || -> u32 { //~^ ERROR: mismatched types <ins> //~| ERROR: `std::ops::Fn() -> u32 + 'static: std::marker::Sized` is not satisfied </ins> 0 }; }

Related discussion:
text: This looks unintentional, and has been broken in all cases, until a few releases ago, AFAICT. Should this be covered by WF rules? cc Unsized constants cause an ICE, in both old trans and MIR trans: Unsized statics appear to work, but only in old trans: I believe this is possible because a constant DST lvalue in old trans is merely the fat pointer. It seems useful to allow an unsized , but IMO it should require a sized RHS instead, i.e.: And, of course, this should all go through the RFC process, to figure out all the finer details.
Should it be ? I don't think A needs to be an lvalue.
It makes more sense for constants, but I gave the example with because that's the only one that works today (although by accident).
Hmm? I mean the static is desugared into a const. works today.
The idea being that a static and a const reference both give access to one lvalue.
No, has different semantics: it allows an somewhere within and is guaranteed not to be duplicated.
Hmm? Both of these gives me a "error: cannot borrow a constant which contains interior mutability, create a static instead". This is what I'd suspect as the lvalue from the promoted has nothing to do with being a or a .
Let me rewrite my desugaring to account for that, oops.
Oh and my confusion really just stemmed from forgetting about the constants referring to statics rule. [Kind of a funny rule when works, but this is an orthogonal issue.]
I think in the meantime unsized statics should probably error, perhaps dependent on a crater run, though I doubt there's many people relying on said bug. It's much easier to relax restrictions than tighten them.
Will prepare a patch to turn this into an error, hopefully nobody has been abusing it.
Code change:
= note: the only supported types are integers, `bool` and `char` = help: more complex types are supported with `#![feature(adt_const_params)]` <del> error: aborting due to 7 previous errors </del> <ins> error: `&dyn for<'a> Foo<'a>` is forbidden as the type of a const generic parameter --> $DIR/unusual-rib-combinations.rs:29:21 | LL | struct Bar<const N: &'a (dyn for<'a> Foo<'a>)>; |                     ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: the only supported types are integers, `bool` and `char` = help: more complex types are supported with `#![feature(adt_const_params)]` error: aborting due to 9 previous errors </ins> <del> Some errors have detailed explanations: E0106, E0214, E0308. </del> <ins> Some errors have detailed explanations: E0106, E0214, E0308, E0771. </ins> For more information about an error, try `rustc --explain E0106`.

Related discussion:
text: This is a fuzzed test case, found with and minimized with . I wasn't able to find any similar issues: : <details<summary<strongBacktrace</strong</summary<p</p</details
This is related to , do we need to keep this ICE or we cover it at here:
The assert was in If you have a reproducer, then it can be to and the assert can be removed.
label +S-bug-has-mcve
Code change:
<ins> error[E0283]: type annotations needed: cannot resolve `_: A` --> $DIR/issue-63496.rs:4:21 | LL |     const C: usize; |     --------------- required by `A::C` LL | LL |     fn f() -> ([u8; A::C], [u8; A::C]); |                     ^^^^ error[E0283]: type annotations needed: cannot resolve `_: A` --> $DIR/issue-63496.rs:4:33 | LL |     const C: usize; |     --------------- required by `A::C` LL | LL |     fn f() -> ([u8; A::C], [u8; A::C]); |                                 ^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0283`. </ins>

Related discussion:
text: Binder(<[type error] as ToBytes) This only happens if there are two erroneous functions, if I take out it works fine. It seems like I was trying to do this wrong in the first place since the first function gives an error . Not sure what the right way to do this is. <details<summaryTraceback</summary</details
Tried to reduce it and found a similar case with the same ICE:
Compiler triage: Seems likely to be caused by the need for lazy norm. Marking as p-medium for now.
The ICE doesn't appear on the latest nightly, marked as E-needstest
Code change:
where A: DoubleEndedIterator + ExactSizeIterator, B: DoubleEndedIterator + ExactSizeIterator; <ins> fn fold<Acc, F>(self, init: Acc, f: F) -> Acc where F: FnMut(Acc, Self::Item) -> Acc; </ins> // This has the same safety requirements as `Iterator::__iterator_get_unchecked` unsafe fn get_unchecked(&mut self, idx: usize) -> <Self as Iterator>::Item where

Related discussion:
text: <!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: same codegen or similar in performance Instead, this happened: array has way worse codegen <details<summaryAssembly</summary<p</p</details<!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.64 <!-- Provide the version you are using that has the regression. --65 till now. Regressed in nightly-2022-08-13, maybe LLVM 15 ?: : <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. -- modify labels: +regression-from-stable-to-stable -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
WG-prioritization assigning priority (). cc since this regressed in the LLVM 15 update label -I-prioritize +P-medium +T-compiler
I've seen llvm doing these strange 1-byte-at-a-time "vectorizations" in other places too. This might be a more general problem. In this case we can probably paper over it by implementing TrustedRandomAccess for the array iter.
Unfortunately, the array iterator is fundamentally worse right now, because indexing into it -- a fundamental part of being a by-value array iterator -- keeps it from SRoAing and thus doesn't optimize well. This is why when I was making better I ended up making to not have to use . Sadly, for the foreseeable future you're better off using the "weaker" slice iterator when you can.
My guess is that the SROA is missing something in the opaque pointer mode.
Code change:
where A: DoubleEndedIterator + ExactSizeIterator, B: DoubleEndedIterator + ExactSizeIterator; <ins> fn fold<Acc, F>(self, init: Acc, f: F) -> Acc where F: FnMut(Acc, Self::Item) -> Acc; </ins> // This has the same safety requirements as `Iterator::__iterator_get_unchecked` unsafe fn get_unchecked(&mut self, idx: usize) -> <Self as Iterator>::Item where

Related discussion:
text: claim
It's not about vectorization. This optimization can be restored by using . But highly unrecommended. Upstream issue:
The upstream issue is closed. claim
Code change:
fn visit_impl_item(&mut self, ii: &'a ImplItem) { let def_data = match ii.node { ImplItemKind::Method(MethodSig { <del> header: FnHeader { asyncness: IsAsync::Async { closure_id, return_impl_trait_id, }, .. }, .. }, ..) => { </del> <ins> header: ref header @ FnHeader { asyncness: IsAsync::Async { .. }, .. }, ref decl, }, ref body) => { </ins> return self.visit_async_fn( ii.id, <del> closure_id, return_impl_trait_id, </del> ii.ident.name, ii.span, <del> |this| visit::walk_impl_item(this, ii) </del> <ins> header, &ii.generics, decl, body, </ins> ) } ImplItemKind::Method(..) | ImplItemKind::Const(..) =>

Related discussion:
text: suggested this is because when we lower the async function, we add `), whereas it should be parented as something outside of the impl trait context (as that is how such an expression would be parented, if it actually existing in the AST). I have a bit of code where I'd like to use a reference with a lifetime in an "async" function, which panics the compiler. I tried this code: I expected to see this happen: My understanding was that async functions are allowed to take references as parameters. helped to debug this a little bit and there is a suspicion that named lifetimes are somehow not properly propagated. I stumbled into this because I wanted to have 2 args with references, but if the lifetimes are elided the compiler asks for them to be . Adding them ICEs the compiler. Instead, this happened: I got a compiler panic. Backtrace:
suggested might be related
It would appear one can workaround this by using async blocks manually: I still need to test this does what I expect.
why do you need the immediately invoked closure there,
Yeah, just noticed. I think I also had some other issue / ICE, but I don't remember exactly what it was. Gonna have to check it again. Also, I don't think I knew that on blocks was a thing.
I didn't quite understand why I needed the move. I am trying to fix the original ICE, I think I got some time today tomorrow, hopefully, will make some progress. But compiler newbie, so might not work out.
You need to move to avoid the closure borrowing the references locally. It's the same situation as with I just removed all immeditaly invoked functions from eval :wink:
I am playing around with similar types of borrowing patterns, namely using StreamObj to carry a stream around inside of a struct. I can't seem to use the posted work-arounds: I am taking this working code and I'm refactoring it. Starts as: this works, compiles and runs. Then I try my hand at refactoring to move the stream out of the same scope as the await code pulling out values.
Code change:
fn visit_impl_item(&mut self, ii: &'a ImplItem) { let def_data = match ii.node { ImplItemKind::Method(MethodSig { <del> header: FnHeader { asyncness: IsAsync::Async { closure_id, return_impl_trait_id, }, .. }, .. }, ..) => { </del> <ins> header: ref header @ FnHeader { asyncness: IsAsync::Async { .. }, .. }, ref decl, }, ref body) => { </ins> return self.visit_async_fn( ii.id, <del> closure_id, return_impl_trait_id, </del> ii.ident.name, ii.span, <del> |this| visit::walk_impl_item(this, ii) </del> <ins> header, &ii.generics, decl, body, </ins> ) } ImplItemKind::Method(..) | ImplItemKind::Const(..) =>

Related discussion:
text: Now I can get the same ICE as this ticket: ICE: full backtrace: Then I try some of your posted workarounds and they don't do the trick, here's my best try: but this fails to compile due to an ownership issue I can't figure out:
your final borrow error is because Fahrenheit while your contains a local stack borrow. You could try using  instead of Fahrenheit.
Alternatively to what suggested, you could move the code in to an async fn:
Code change:
let path = cfg_file.unwrap_or_else(|| src_path.join("config.toml")); let settings = format!( "# Includes one of the default files in src/bootstrap/defaultsn <del> profile = "{}"n", profile </del> <ins> profile = "{}"n changelog-seen = {}n", profile, VERSION </ins> ); t!(fs::write(path, settings));

Related discussion:
text: New contributors haven't use before, so there's no reason for them to read the changelog: nothing has changed.
I can tackle this.
that would be great! To get started, take a look at . In addition to adding , also add . You'll have to move from to so you can access it in . You should also double check that the changelog warning isn't printed during the command itself. I'm not sure exactly how to do that without reading the code, but I expect it to be a simple or something like that.
Code change:
use std::path::PathBuf; pub static BINARY_PATH: OnceLock<PathBuf> = OnceLock::new(); <del> pub const RUN_OPTION: &str = "*doctest-inner-test"; pub const BIN_OPTION: &str = "*doctest-bin-path"; </del> <ins> pub const RUN_OPTION: &str = "RUSTDOC_DOCTEST_RUN_NB_TEST"; </ins> #[allow(unused)] pub fn doctest_path() -> Option<&'static PathBuf> {{

Related discussion:
text: The crater run for merged doctests () detected a large number of regressions due to tests examining the process arguments. (I don't have an exact number, but let's say ~50 projects.) Previously, there were no arguments, but now it gets arguments like which the user's CLI parsing code isn't expecting. For example, using something like  will now fail. It seems to be fairly common to have objects whose default constructor will parse the arguments from the command line. I'm not sure if or how we should resolve that. One idea is to use a different mechanism for passing in the test information (like via an environment variable).
I vaguely remember that using environment variables was discussed but can't find anything except mentioning it . Maybe it'd be a better approach indeed. Let me send a PR so we can make a crater run on it.
Code change:
<ins> fn hello<Q>() -> Vec<Q> { Vec::<Q>::mew() //~^ ERROR no function or associated item named `mew` found for struct `Vec<Q>` in the current scope } fn main() {} </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: param types with same index differ in name'', 'thread 'rustc' panicked at 'assertion failed: param types with same index differ in name'' File: --auto-reduced (treereduce-rust): original: Version information ` Command:
thanks for the stack trace for this class of ICEs, it's just the right thing that I need. Minimal:
Code change:
<ins> // Copyright 2012 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. //compile-flags: -Z borrowck=mir #![feature(slice_patterns)] fn mut_head_tail<'a, A>(v: &'a mut [A]) -> Option<(&'a mut A, &'a mut [A])> { match *v { [ref mut head, ref mut tail..] => { Some((head, tail)) } [] => None } } fn main() { let mut v = [1,2,3,4]; match mut_head_tail(&mut v) { None => {}, Some((h,t)) => { *h = 1000; t.reverse(); } } } </ins>

Related discussion:
text: Minimal example: This will complain about multiple mutable borrows, even though it should be valid.
Noted in (but may deserve a separate bug report?). (FYI, slice patterns are unstable for a reason; they're pretty buggy at the moment).
should be closed after MIR borrowck will be by default
Code change:
<ins> error[E0425]: cannot find value `bogus` in this scope --> $DIR/issue-59134-1.rs:8:37 | LL |         const CONST: Self::MyType = bogus.field; |                                     ^^^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </ins>

Related discussion:
text: When using this branch of bitflags: through a patch in a local directory rls crashes with the following errors:
i had enabled dev overrides for dependencies in using: removing that out the output from rls is now the normal debug flags but still the same errors:
This is now causing widespread ICEs in the RLS. Nominating to get this fixed (maybe has an idea?). See for a simpler reproducer.
I encountered this issue trying out which causes rustc to crash on when invoked by RLS. I can confirm it's the exact same backtrace as
I ran into this trying out on Windows 10. RLS inside vscode ends up panicking with this backtrace: (note for repro: I had changed the default feature in tui-rs to be "crossterm" because the default feature "termion" doesn't compile on windows - but after the termion compile errors, rustc was giving me a similar panic anyway)
JFYI I could work around this problem by adding to my
I tried that with the tui-rs (it had ) but same panic. [Edit] you're right, I had missed the inside the version.
Thanks !
Running into the same issue when trying to build Clap
Same issue in vscode on linuxmint and rust 1.34.1 when trying to build glib (dependency of gtk).
There is no need to list every crate which depends on , it only clutters the thread and makes less visible.
Here's a small repro, extracted from what is doing: I'm struggling to get a repro without the compile error, though.
Thank you for such a small repro! I’ll take a closer look tomorrow and see what may be causing that. On Tue, 7 May 2019 at 22:32, Sean Gillespie <:
Looks like isn't written back for a resolution error? That still repros without , right?
Correct, it does. Further minimized repro:
Interesting. I managed to reduce it to: with: Any other combination is okay, it has to be under under and it has to be combined with a field access (bare unknown identifier doesn't ICE). I'm only guessing but it seems that it tries to emplace def 'path' under a which seems to skip a def path segment?