Repository navigation
unsized_fn_params should not accept types that don't have a dynamically fixed size (such as extern types) #115709
Copy link
Copy link
Open
Labels
F-extern_types`#![feature(extern_types)]``#![feature(extern_types)]`F-unsized_fn_params`#![feature(unsized_fn_params)]``#![feature(unsized_fn_params)]`T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
Activity
- addedF-unsized_fn_params`#![feature(unsized_fn_params)]``#![feature(unsized_fn_params)]`
on Sep 9, 2023 - addedneeds-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triagingThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
on Sep 9, 2023 See also #79409.
There is no generic bound to distinguish extern types from other unsized types
rust-lang/rfcs#2984 and rust-lang/rfcs#3396 are open RFCs that attempt to address this.
Unfortunately just rejecting locals/arguments that are not known to be dyn-sized as a MIR pass does not work: the forget_unsized function in the standard library would stop compiling.
So currently something post-monomorphization is the only option. Is there even some place that check could be put without being duplicated across all codegen backends (and Miri)?
- changed the title
[-]unsized_fn_params should not accept types that don't have a dynamically fixed size[/-][+]unsized_fn_params should not accept types that don't have a dynamically fixed size (such as `extern` types)[/+]on Sep 10, 2023 - added 5 commits that reference this issue
on Sep 11, 2023 - added a commit that references this issue
on Sep 19, 2023 - addedT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.and removedneeds-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triagingThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
on Sep 19, 2023 - added a commit that references this issue
on Sep 19, 2023 - added a commit that references this issue
on Sep 25, 2023 In #116115 we agreed that this is not worth a post-mono check; this needs proper design to find a way that makes this work without a post-mono check. So for now we are living with the ICEs.
- added a commit that references this issue
on Dec 4, 2023 - added a commit that references this issue
on Dec 5, 2023 - added a commit that references this issue
on Apr 7, 2024 - added a commit that references this issue
on Apr 27, 2024 - added 2 commits that reference this issue
on Jan 27, 2026
Metadata
Metadata
Assignees
Labels
F-extern_types`#![feature(extern_types)]``#![feature(extern_types)]`F-unsized_fn_params`#![feature(unsized_fn_params)]``#![feature(unsized_fn_params)]`T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
The following code should not be accepted:
In terms of MIR semantics I think we want to view a function call as making copies of its arguments. This requires at least dynamically determining the size of the argument, and therefore we shouldn't accept
extern typearguments.I was extremely surprised earlier today when I learned that this code is getting accepted.
There is no generic bound to distinguish
externtypes from other unsized types, so the options we have areexternTrying to actually build any such code will lead to ICEs such as
or