Tracking Issue for externally implementable items

[traviscross]

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) rust-project-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_mangle on EIIs is rejected properly
  • Hundreds of missing stability attribute errors with trivial Externally Implementable Item (eii) function in library/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 None in 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
    • 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 (context: Externally implementable items #146348 (comment))
    • Support -Cprefer-dynamic
  • Implement for Miri
  • EIIs as statics
  • 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:
  • Unsafe Extern Blocks rfcs#3484
• 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

• Externally implementable items #146348

cc @m-ou-se @Amanieu @tmandry @joshtriplett

[m-ou-se]

@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:

#[externally_implementable(thing_handler)]
fn do_thing();

#[thing_handler]
fn my_thing_handler() {
    ..;
}

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_thing is 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 place unsafe in the attribute itself, to separate "unsafe to implement" and "unsafe to call".

More updates soon!

[Amanieu]

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]

Does this introduce a new global namespace for thing_handler?

Nope! It behaves the same as any other attribute (macro), as an item with a path.