Repository navigation
Tracking Issue for externally implementable items #125418
Description
This is a tracking issue for the lang experiment on externally implementable items. This currently covers these proposals:
- [RFC] externally implementable functions rfcs#3632
- [RFC] externally definable statics rfcs#3635
- Externally implementable traits rfcs#3645
- RFC: Existential types with external definition rfcs#2492
The feature gate for the issue is #![feature(extern_item_impls)].
Example of how to use what's implemented now
#![feature(extern_item_impls)]
#[eii(eii1)]
pub fn decl1(x: u64)
// body optional (it's the default)
{
println!("default {x}");
}
// in another crate, maybe
#[eii1]
pub fn decl2(x: u64) {
println!("explicit {x}");
}
fn main() {
decl1(4);
}About tracking issues
Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
- Get alternate proposals.
- Original proposal from @m-ou-se. [RFC] externally implementable functions rfcs#3632
- Alternative proposal from @m-ou-se. [RFC] externally definable statics rfcs#3635
- Alternative proposal from @Amanieu. Externally implementable traits rfcs#3645
- Alternative proposal from @tmandry. [RFC] externally implementable functions rfcs#3632 (comment)
- Pick a design for the experiment.
- Using attributes rather than new syntax: Tracking Issue for externally implementable items #125418 (comment)
- Submit project goal: Add project goal: Externally Implemtable Items (EII) goals#198
- Approval
- Implement the experiment.
- First fix attributes so we can do name resolution in them: Attribute handling reworks compiler-team#796
- Implement externally implementable items using attributes: Externally implementable items #146348
- Check
no_mangleon EIIs is rejected properly - Hundreds of
missing stability attributeerrors with trivial Externally Implementable Item (eii) function inlibrary/std#150514- make them semiopaque compiler: Make Externally Implementable Item (eii) macros "semiopaque" #151046
- ICE: eii on impl:
expected statement#149980 - ICE: eii on generic
Instance::mono: DefId(..) has type parameters#149983 - ICE: eii: fn / macro rules
Nonein find_attr() #149981 - Busywork
- rename eii_extern_target Rename EII attributes slightly (being consistent in naming things foreign items, not extern items) #150972
- Rename extern to foreign everywhere Rename EII attributes slightly (being consistent in naming things foreign items, not extern items) #150972
- Disallow in statement position Disallow eii in statement position #150971
- Simplify expansion using ecx Simplify
#[eii]macro using methods on ecx #150906 - Compute alias symbols during codegen Store defids instead of symbol names in the aliases list #150811
- Reduce encoding time: remove extern target from encoded decl (it's duplicated)
- Similar for the encoded EiiImpl
- Track caller on the declaration
- Look at attribute forwarding
-
For now: fwd everything: compiler: Forward attributes to eii-expanded macros #150913 - reject all but a few disallow most attrs on eiis #157312
-
- Test resolving to a proc (attribute) macro
- Platform support:
- Implement for codegen_gcc (needs support for aliases)
- Implement for windows
- mingw needs a trick similar to how alloc handlers are currently generated
- msvc needs us to implement /export inside the linker flags (see: Use the .drectve section for exporting symbols from dlls on Windows #142568, [WIP] Use weak linkage instead of compiler generated shims #134522, [WIP] Use weak aliases for the allocator shim #142366, )
- macos support Use function shims to make sure EII works on apple targets #151733
- Support
-Cprefer-dynamic
- Implement for Miri EII, support
extern_item_implsmiri#5247 - EIIs as statics Implement EII for statics #154193
- Demonstrations:
- rewrite panic_handler in terms of EII. Should be easy, no weak symbols needed
- (WIP) on-broken-pipe Use the .drectve section for exporting symbols from dlls on Windows #142568
- rewrite alloc_handler in terms of EII. Harder because it requires defaults
- Verify proposals are consistent with:
- Write/update RFC based on experiment.
- Accept an RFC.
- Add documentation to the dev guide.
- See the instructions.
- Add documentation to the reference.
- See the instructions.
- Add formatting for new syntax to the style guide.
- See the nightly style procedure.
Unresolved Questions
- Which exact alternative or alternatives should we adopt?
Related
- [RFC] externally implementable functions rfcs#3632
- [RFC] externally definable statics rfcs#3635
- Externally implementable traits rfcs#3645
- RFC: Existential types with external definition rfcs#2492
Implementation history
Reacted by Martin Nordholts, RandomScientist, lolbinarycat, Alex, José Luis Cruz and Jacob Pratt
Reacted by Ltrlg, Jacob Pratt and Alex
Reacted by Mara Bos, Dario Nieuwenhuis, Jana Dönszelmann, Martin Nordholts, Levente Morva, Aurelia Molzer, citorva, Martin Atkins, Alex, marziply and 4 more
Metadata
Metadata
Assignees
Labels
Blocker: In-tree experiment; RFC pending, not yet approved or unneeded (requires FCP to stabilize).Category: An issue tracking the progress of sth. like the implementation of an RFC`#![feature(extern_item_impls)]`Relevant to the language teamRelevant to the types team, which will review and decide on the PR/issue.
Type
Projects
- Status
Activity
m-ou-se commentedon Sep 19, 2024
@jdonszelmann and I are currently implementing this, with a different syntax. Instead of using new syntax (e.g.
extern impl fn ...) as in the RFC draft, we're using attributes instead:This has a number of advantages.
#[thing_handler]could be replaced by a proc_macro in semver-compatible versions of the crate, so we don't need to worry about providing conversion/upgrade mechanisms. It also makes it look identical to#[panic_handler]and#[global_allocator]attributes. It clarifies the naming and visibility issue:do_thingis the function to call, and#[thing_handler]is the attribute to override it, so they each have their own name and visibility. And it allows us to placeunsafein the attribute itself, to separate "unsafe to implement" and "unsafe to call".More updates soon!
Amanieu commentedon Oct 1, 2024
Does this introduce a new global namespace for
thing_handler? I would prefer if this was a proper path to an item within a crate since that properly takes care of things like multiple instances of the same crate with different major versions.m-ou-se commentedon Oct 24, 2024
Nope! It behaves the same as any other attribute (macro), as an item with a path.
nikomatsakis commentedon Feb 21, 2025
84 remaining items
Unrolled build for #158723
Rollup merge of #158235 - cezarbbb:eii-metadata-opt, r=bjorn3
Rollup merge of #158723 - AsakuraMizu:windows-msvc-eii, r=bjorn3
Rollup merge of #158535 - cezarbbb:eii-track-caller, r=bjorn3
Rollup merge of #158235 - cezarbbb:eii-metadata-opt, r=bjorn3
Rollup merge of #158723 - AsakuraMizu:windows-msvc-eii, r=bjorn3
Rollup merge of rust-lang#159783 - AsakuraMizu:safe-eii-unsafe-impl, …
Rollup merge of rust-lang#159783 - AsakuraMizu:safe-eii-unsafe-impl, …
Rollup merge of rust-lang#159783 - AsakuraMizu:safe-eii-unsafe-impl, …
Rollup merge of rust-lang#159783 - AsakuraMizu:safe-eii-unsafe-impl, …
Rollup merge of rust-lang#159783 - AsakuraMizu:safe-eii-unsafe-impl, …
Unrolled build for #159783
Rollup merge of #159783 - AsakuraMizu:safe-eii-unsafe-impl, r=mejrs,J…
Auto merge of #146348 - jdonszelmann:eiiv3, r=lcnr,oli-obk
Auto merge of #146348 - jdonszelmann:eiiv3, r=lcnr,oli-obk