jiebi/CodeConvo huggingface dataset:
Change:
<ins> // check-pass // Ensure that we don't ICE when an alias that has escaping bound vars is // required to be live. This is because the code that allows us to deduce an // appropriate outlives bound for a given alias type (in this test, a // projection) does not handle aliases with escaping bound vars. // See <https://github.com/rust-lang/rust/issues/117455>. trait Foo { type Assoc<'a, 'b>: 'static; } struct MentionsLifetimeAndType<'a, T>(&'a (), T); fn foo<'a, 'b, T: Foo>(_: <T as Foo>::Assoc<'a, 'b>) {} fn test<'b, T: Foo>() { let y: MentionsLifetimeAndType<'_, for<'a> fn(<T as Foo>::Assoc<'a, 'b>)> = MentionsLifetimeAndType(&(), foo); } fn main() {} </ins>

Discussion:
Check out ICU4X (tested on commit ), and build : However this started happening in our nightly CI since (one nightly before this one). The PR must have landed in the recent past. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Working on bisection, so far I have this
regressed commit: <detailsbash cargo bisect-rustc --start 2023-10-28 --end 2023-10-30 </details
Regression is , cc
Change:
<ins> error: type parameter `T` is part of concrete type but not used in parameter list for existential type --> $DIR/issue-58887.rs:16:41 | LL |       fn unwrap_items(self) -> Self::Iter { |  _________________________________________^ LL | | LL | | LL | |         self.map(|x| x.unwrap()) LL | |     } | |_____^ error: type parameter `E` is part of concrete type but not used in parameter list for existential type --> $DIR/issue-58887.rs:16:41 | LL |       fn unwrap_items(self) -> Self::Iter { |  _________________________________________^ LL | | LL | | LL | |         self.map(|x| x.unwrap()) LL | |     } | |_____^ error: could not find defining uses --> $DIR/issue-58887.rs:13:5 | LL |     existential type Iter: Iterator<Item = T>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 3 previous errors </ins>

Discussion:
probably related to
cc might not be impl-trait-in-let-binding related after all
Ah, good to know. Are you going to tackle this? I'm not sure if the RFC for should support this syntax (I suspect not), but it would be nice (for the sake of my upcoming PR) to support within impls at an HIR level, at least.
Existential types for associated types in trait impls are already supported and suggested to exist by the RFC. The issue here is probably that I never considered generics in that light. Or am I misunderstanding what you mean by "this syntax"?
Ah, I was probably thinking of the case of inherent impls... glad these are supported.
The ICE doesn't appear on the latest nightly via the above link.
Good spot. Not sure what PR fixed this, but I suspect it can be closed now...
Before closing this, we can add the tests for this.
It depends if there is already an equivalent (minimal) example. If there is, no need... if not, then yes (and let's minimise this one).
It's sorta harder to minimize something that no longer ICEs... I think it would be sufficient to simply add a test with the above snippet for now and close the issue after.
Fair point. I mean, we could use an old nightly, but that's a pain.
Change:
<ins> // compile-flags: -Zsave-analysis </ins> #![feature(type_alias_impl_trait)] type Closure = impl FnOnce(); //~ ERROR: type mismatch resolving

Discussion:
When running in the subdirectory, a call to with causes the following ICE: I'm not exactly sure what additional information to provide? I filed an issue with , and was forwarded here since it is an ICE.
I've minimized it a bit: It still uses external crates but the example itself is very small.
compile it with: Although is behind a feature gate it will ICE without the feature gate! modify labels: F-typealiasimpltrait ICE code:
Change:
} } <del> let tcx = self.hir.tcx(); </del> let tcx_hir = tcx.hir(); let hir_typeck_results = self.hir.typeck_results();

Discussion:
When compiling () The generated assembly includes a prologue with unexpected 's (as well as a trailing , already reported in ) Expected behaviour would be to have no prologue (and prevent compilation of a function that is not as this would require implementing an undefined ABI, contrarily to what seems to happen ). This is treacherous, as it dereferences some memory locations that may not be accessible, as happened to me and led to hours of debugging to finally figure out the compiled function was not the one defined. cc
IIRC this is invalid and rustc should reject such a function, naked functions can't take arguments and the compiler should probably enforce that.
Hmm, my understanding of the RFC (“The following variant is not an error because the C calling convention is well-defined and it is thus possible for the programmer to write a conforming function”, even if the example is not with an argument) would mean that if the function is declared , then the function can actually respect the said ABI, thus should be well-formed?
Is there an update on this? I was hit by this issue as well. I hit the problem when compiling a tock app (baremetal-ish and jumped to by the tock OS) A naked function with arguments would produce this prolog (RV32): Which would result in an invalid access as s0 would be 0. Removing the arguments would remove the prologue and fix the problem. Removing the naked cfg would also work as teh stack pointer was already setup by the OS and result in this. If arguments with naked functions aren't supported rustc should generate an error as this is a difficult problem to debug.
This is an LLVM bug. Has it been reported upstream?
Change:
} eprintln!( "warning: {updated_master} is used to determine if files have been modifiedn <del> warning: if it is not updated, this may cause files to be needlessly reformatted" </del> <ins> warning: if it is not updated, this may cause files to be needlessly reformatted" </ins> ); <del> Ok(()) </del> <ins> } pub fn warn_old_master_branch_( config: &GitConfig<'_>, git_dir: &Path, updated_master: &mut String, ) -> Result<bool, Box<dyn std::error::Error>> { use std::time::Duration; *updated_master = updated_master_branch(config, Some(git_dir))?; let branch_path = git_dir.join(".git/refs/remotes").join(&updated_master); const WARN_AFTER: Duration = Duration::from_secs(60 * 60 * 24 * 10); let meta = match std::fs::metadata(&branch_path) { Ok(meta) => meta, Err(err) => { let gcd = git_common_dir(&git_dir)?; if branch_path.starts_with(&gcd) { return Err(Box::new(err)); } std::fs::metadata(Path::new(&gcd).join("refs/remotes").join(&updated_master))? } }; if meta.modified()?.elapsed()? > WARN_AFTER { eprintln!("warning: {updated_master} has not been updated in 10 days"); Ok(true) } else { Ok(false) } } fn git_common_dir(dir: &Path) -> Result<String, String> { output_result(Command::new("git").arg("-C").arg(dir).arg("rev-parse").arg("--git-common-dir")) .map(|x| x.trim().to_string()) </ins> }

Discussion:
When running any bootstrap command, it complains that it can't figure out whether my master branch is outdated. Of course it does, as it just YOLOs into , which is just a file and not a directory for worktrees: it should probably not do that (i don't have a suggestion on what to do instead) regressed by
i would say adding a bit of error handling that checks if it's in a worktree doesn't sound too hard. there's two options from there: emit the warning in a worktree. this is basically trivial, but if someone does 100% of their work in a worktree, they may end up with an outdated upstream and not know it back to a more reliable method when in a worktree
Change:
} _ => { check_pat(pcx, inner, ty::mk_err()); <del> let resolved_expected = fcx.infcx().ty_to_str(fcx.infcx().resolve_type_vars_if_possible(expected)); fcx.infcx().type_error_message_str(span, |actual| { fmt!("mismatched types: expected `%s` but found %s", resolved_expected, actual)}, fmt!("%s pattern", match pointer_kind { Managed => "an @-box", Owned => "a ~-box", Borrowed => "an &-pointer" }), None); </del> <ins> fcx.infcx().type_error_message_str_with_expected( span, |expected, actual| { expected.map_default(~"", |&e| { fmt!("mismatched types: expected `%s` but found %s", e, actual)})}, Some(expected), fmt!("%s pattern", match pointer_kind { Managed => "an @-box", Owned => "a ~-box", Borrowed => "an &-pointer" }), None); </ins> fcx.write_error(pat_id); } }

Discussion:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in
Change:
} fn warn_dead_code(&mut self, id: LocalDefId, participle: &str) { <del> self.warn_multiple_dead_codes(&[id], participle, None, false); </del> <ins> self.lint_at_single_level(&[id], participle, None, false); </ins> } fn check_definition(&mut self, def_id: LocalDefId) {

Discussion:
At some point between (works) and (does not work) the following stopped compiling: I have not bisected for the exact commit that broke this. I have only tried to reproduce this error using . It's possible that this is also broken for other lints. PR:
Without properly double-checking this, I'm certain that this regressed in (merged April 14) which condensed multiple diagnostics triggered by methods into a single one for readability meddling with the affairs of . I don't know how is implemented but if it only considers the first primary span of a (buffered) lint diagnostic, then one fix will be changing the relevant part of the code to consider all primary spans. label T-compiler A-lint F-lintreasons
Change:
Err(ty::terr_projection_name_mismatched( expected_found(self, a.item_name, b.item_name))) } else { <del> // Note that the trait refs for the projection must be // *equal*. This is because there is no inherent // relationship between `<T as Foo>::Bar` and `<U as // Foo>::Bar` that we can derive based on how `T` relates // to `U`. Issue #21726 contains further discussion and // in-depth examples. let trait_ref = try!(self.equate().trait_refs(&*a.trait_ref, &*b.trait_ref)); </del> <ins> let trait_ref = try!(self.trait_refs(&*a.trait_ref, &*b.trait_ref)); </ins> Ok(ty::ProjectionTy { trait_ref: Rc::new(trait_ref), item_name: a.item_name }) } }

Discussion:
Attempting to compile with and yields the following ICE:
Reduced test case: Still ICEs with The ICE goes away if the on the is changed to a bare instead of a reference.
Slightly different test case: EDIT: Nevermind, it's the same but uses a closure instead of the more general .
I have bisected this issue to rust-lang/rust (from )
A workaround would be simply:
This doesn't help much if you need to call methods that are on the trait (which was on the original code).
cc me
This is blocking collect-rs from compiling.
This is interesting. The culprit is : it registers obligations from implementation's methods into an hybrid parameter environment which has trait's methods in it. In the example given in this issue, when the associate type is projected out, the implementation's method acquires an extra lifetime variable. The trait's method doesn't have it so the lifetime resolution fails in an ICE later on. I'm not sure how to fix that though.
This compiles so at first glance it looks like a viable workaround: But if one tries to really use as an , compiler panics on an assertion failure:
Getting this with some hashing code.

will output something along the lines of: Start hash BYTES: [69, 84, 87, 87, 100, 57, 118, 102, 80, 97, 122, 56, 100, 116, 80, 82, 74, 78, 104, 116, 109, 51, 88, 54, 56, 98, 56, 97, 66, 119, 105, 116, 90, 114, 50, 83, 107, 99, 51, 52, 89, 121, 121, 112, 86, 116, 57, 66, 120, 87, 86, 112, 88, 55, 66, 49, 76, 90, 86, 48, 49, 53, 56, 53, 52, 48, 56, 56, 49, 53, 54, 48, 51] lyra2 finished: CfV9jehQVXsVnx6Vrg5f9VgHVkWeatbrFGxKVz2knfEc Starting argon thread 'certificate::tests::checkcertdiff' panicked at 'index out of bounds: the len is 0 but the index is 31',
Change:
cp_debugger_script("lldb_lookup.py"); cp_debugger_script("lldb_providers.py"); <ins> cp_debugger_script("lldb_commands") </ins> } } }

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: To be able to use lldb commands as I can if I use lldb directly Instead, this happened: error: file specified in --source (-s) option doesn't exist: 'lldbcommands' <!-- 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 same happens on a macOS machine I saw that is on directory together with shell script, and I also saw that script calls it directly, but I'm not sure how it should behaves in my machine since the is not there (rustup is not installing it) I've asked it on Rust users forum, and also in the discord chat, but no answers, so I'm considering it a bug, feel free to close it if it is something wrong with my installation and, if possible, guide me on where should I look to fix it.
cc who introduced in . I also notice the script references which isn't set anywhere.
The issue happens because expects and its dependencies resides on the current directory. Just to let you know that I got it working doing this: Cloned this repo on : Edit changing the first line to: Then run the following to link the files to the current directory:
Another important highlight, as mentioned, this is a recent change, so 1.45 was working fine and the issue appeared only on 1.46
Change:
<ins> error: comparison operators cannot be chained --> $DIR/issue-82566-1.rs:18:7 | LL |     T1<1>::C; |       ^ ^ | help: use `::<...>` instead of `<...>` to specify type or const arguments | LL |     T1::<1>::C; |       ^^ error: expected one of `.`, `;`, `?`, `}`, or an operator, found `,` --> $DIR/issue-82566-1.rs:19:9 | LL |     T2<1, 2>::C; |         ^ expected one of `.`, `;`, `?`, `}`, or an operator | help: use `::<...>` instead of `<...>` to specify type or const arguments | LL |     T2::<1, 2>::C; |       ^^ error: expected one of `.`, `;`, `?`, `}`, or an operator, found `,` --> $DIR/issue-82566-1.rs:20:9 | LL |     T3<1, 2, 3>::C; |         ^ expected one of `.`, `;`, `?`, `}`, or an operator | help: use `::<...>` instead of `<...>` to specify type or const arguments | LL |     T3::<1, 2, 3>::C; |       ^^ error: aborting due to 3 previous errors </ins>

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. --Given the following code: The current output is: Ideally the output should mention that the user needs to use a turbofish here: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
the help message seems to only be missing if there are 2 const arguments: using type parameters or just one const param causes a useful help message
claim
It turns out 's repro is different than the original repro. My PR fixes 's examples but not the original one. I'll update it to fix the original one too.
All fixed.
Change:
<ins> // check-pass #![feature(coerce_unsized, unsize)] use std::marker::Unsize; use std::ops::CoerceUnsized; struct Foo<T: ?Sized>(Box<T>); impl<T> CoerceUnsized<Foo<dyn Baz>> for Foo<T> where T: Unsize<dyn Baz> {} struct Bar; trait Baz {} impl Baz for Bar {} fn main() { let foo = Foo(Box::new(Bar)); let foobar: Foo<Bar> = foo; } </ins>

Discussion:
Full code: Given a smart pointer, which only works on types implementing the trait or on trait objects, such that is allowed to coerce to , and the corresponding implementation : Applying the operator on two will try to coerce them to , even though this isn't needed. This is an issue since coercion moves the original pointer. Removing the implementation lets the code build, which means that the coercion is not needed. As , if the is restricted to pointers with identical types (), then no coercion occurs. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Seems related to
I've discovered a simpler reproduction: Curiously, when you just do , there's no problem. The overeager coercion can only occur in the presence of type inference. It also only occurs when the is non-parametric, i.e. not written like this: Likely because this allows to coerce to itself, hiding the issue. This also explains why it hasn't come up in the stdlib, because no type tries to coerce to a specific unsized type; it's all parametric.
The original code compiles with no errors today, so seems like E-needstest.
I think I tested the wrong thing; not E-needstest.
The linked reproduction from no longer fails to compile; is this fixed?
This is fixed but does need a test, though I think it could also be closed without a test, since it's been open for so long there's probably already coverage :thinking:
I think we should add the test just to be sure.
claim
Change:
//! A bunch of methods and structures more or less related to resolving macros and //! interface provided by `Resolver` to macro expander. <ins> use crate::errors::{AddAsNonDerive, MacroExpectedFound, RemoveSurroundingDerive}; </ins> use crate::Namespace::*; use crate::{BuiltinMacroState, Determinacy}; use crate::{DeriveData, Finalize, ParentScope, ResolutionError, Resolver, ScopeSet};

Discussion:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable
Change:
<ins> #![crate_type = "rlib"] #![crate_type = "cdylib"] #[macro_export] macro_rules! asm_func { ($name:expr, $body:expr $(, $($args:tt)*)?) => { core::arch::global_asm!( concat!( ".p2align 4n", ".hidden ", $name, "n", ".global ", $name, "n", ".type ", $name, ",@functionn", $name, ":n", $body, ".size ", $name, ",.-", $name, ) $(, $($args)*)? ); }; } macro_rules! libcall_trampoline { ($libcall:ident ; $libcall_impl:ident) => { asm_func!( stringify!($libcall), concat!( " .cfi_startproc simple .cfi_def_cfa_offset 0 jmp {} .cfi_endproc ", ), sym $libcall_impl ); }; } pub mod trampolines { extern "C" { pub fn table_fill_funcref(); pub fn table_fill_externref(); } unsafe extern "C" fn impl_table_fill_funcref() {} unsafe extern "C" fn impl_table_fill_externref() {} libcall_trampoline!(table_fill_funcref ; impl_table_fill_funcref); libcall_trampoline!(table_fill_externref ; impl_table_fill_externref); } </ins>

Discussion:
This will take quite a while; sorry, I don't have a more minimal reproduction on hand since the issue doesn't reproduce on a toy example and reducing the actual reproduction into a minimal example is tricky when it takes forever to reproduce. The compilation succeeds. Linking fails. rustc 1.69.0-nightly ( 2023-01-23) rustc 1.69.0-nightly ( 2023-02-13) Linux+amd64 The issue also reproduces on macOS+aarch64. I'm not sure whether this is a generic LTO bug, or a bug with . The  crate sets up a bunch of trampolines like this: <details<summaryRelevant code</summary</detailsSo as you can see the symbol that's being unnecessarily stripped out is being passed into the block () and that is being called from assembly (). That symbol is just a normal mangled extern "C" function (). What's also interesting is also that this seems to affect only these two symbols (there are more that are defined, and it seems like those are not being stripped out for some reason), and that it doesn't reproduce on toy examples. There are also two potential workarounds; first workaround is to just mark the function as : The other is to create a dummy variable with a on it: After applying either of those the linking succeeds even when LTO is enabled. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Might or might not be related:
This is a minimal reproduction that works on macOS and Linux (x86_64). I think the fixes this issue.
label +A-llvm
claim
Change:
let vec_ty = ty::mk_uniq(tcx, ty::mk_vec(tcx, unit_ty, None)); let scratch = rvalue_scratch_datum(bcx, vec_ty, "__unsize_unique"); <del> if len == 0 { Store(bcx, C_null(type_of::type_of(bcx.ccx(), unit_ty).ptr_to()), get_dataptr(bcx, scratch.val)); } else { // Box<[(), ..n]> will not allocate, but ~[()] expects an // allocation of n bytes, so we must allocate here (yuck). let llty = type_of::type_of(bcx.ccx(), unit_ty); if llsize_of_alloc(bcx.ccx(), llty) == 0 { let ptr_unit_ty = type_of::type_of(bcx.ccx(), unit_ty).ptr_to(); let align = C_uint(bcx.ccx(), 8); let alloc_result = malloc_raw_dyn(bcx, ptr_unit_ty, vec_ty, ll_len, align); bcx = alloc_result.bcx; let base = get_dataptr(bcx, scratch.val); Store(bcx, alloc_result.val, base); } else { let base = get_dataptr(bcx, scratch.val); let base = PointerCast(bcx, base, type_of::type_of(bcx.ccx(), datum_ty).ptr_to()); bcx = lval.store_to(bcx, base); } } </del> <ins> let base = get_dataptr(bcx, scratch.val); let base = PointerCast(bcx, base, type_of::type_of(bcx.ccx(), datum_ty).ptr_to()); bcx = lval.store_to(bcx, base); </ins> Store(bcx, ll_len, get_len(bcx, scratch.val)); DatumBlock::new(bcx, scratch.to_expr_datum())

Discussion:
I this to get DST landed. For types I use a fat pointer. If the vector is empy I use null for the pointer, so when this deallocates via drop glue jemalloc segfaults. It should be fairly easy to do a zero sized allocation or something and use that value and then we can remove the null check. That also allows us to use the Option to non-null pointer optimisation. For now I just want to get this branch landed though. cc
FWIW, as the sentinel value for this sort of situation (to ensure that still works, since that uses the "non-null" pointer as the discriminant).
It seems that landed the non-null pointer optimization for slices so this shouldn't be required anymore. Can it be closed?
This ended up landing as part of the initial implementation, but I don't think it is actually accomplishing anything.