Skip to content

Remove support for extern "rust-intrinsic" blocks #132735

Closed

Description

@RalfJung

We currently have two ways to declare symbols that are invoked as intrinsics. The old way:

extern "rust-intrinsic" {
    fn unreachable() -> !;
}

The new way:

#[rustc_intrinsic]
unsafe fn unreachable() -> !;

The goal of this issue is to remove support for the old style, and consistently use the new style.

Activity

  1. added
    C-cleanupCategory: PRs that clean code up or issues documenting cleanup.
    E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
    on Nov 7, 2024
  2. added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Nov 7, 2024
  3. added
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    T-libsRelevant to the library team, which will review and decide on the PR/issue.
    on Nov 7, 2024
  4. compiler-errors commented on Nov 7, 2024

    @compiler-errors
    Contributor

    I do wonder if there's some way we could have body-less free function items when users write #[rustc_intrinsic_must_be_overridden]. Having all these dummy bodies like loop {} and unreachable {} seem kinda meh.

  5. RalfJung commented on Nov 7, 2024

    @RalfJung
    MemberAuthor
  6. compiler-errors commented on Nov 7, 2024

    @compiler-errors
    Contributor

    We actually reject them after expansion but before ast lowering.

    We could perhaps intercept these bodyless functions during ast lowering and fill them with a dummy body like loop {} or something that diverges rather than having it be manually written on each function.

  7. compiler-errors commented on Nov 7, 2024

    @compiler-errors
    Contributor

    Obviously only intercepting them if they're marked with rustc_intrinsic_must_be_overridden; if it's a regular function we'd issue the regular error for a bodyless free function, and if it's rustc_intrinsic we could tell the user that it needs to be marked with rustc_intrinsic_must_be_overridden.

  8. RalfJung commented on Nov 7, 2024

    @RalfJung
    MemberAuthor

    That's way beyond my knowledge of those parts of the compiler. ;) So sure, sounds great. :D

    Cc @petrochenkov

    Obviously only intercepting them if they're marked with rustc_intrinsic_must_be_overridden

    I was actually going to suggest that a #[rustc_intrinsic] not having a body should replace the rustc_intrinsic_must_be_overridden attribute.

  9. compiler-errors commented on Nov 7, 2024

    @compiler-errors
    Contributor

    Oh, that works too.

  10. workingjubilee commented on Nov 7, 2024

    @workingjubilee
    Member

    hmm do we have the notion of a builtin attribute macro...?

  11. compiler-errors commented on Nov 7, 2024

    @compiler-errors
    Contributor
  12. removed
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Nov 8, 2024
  13. aaishwarymishra commented on Nov 9, 2024

    @aaishwarymishra
    Contributor

    @rustbot claim

  14. 59 remaining items

  15. added a commit that references this issue on Apr 8, 2025
  16. added a commit that references this issue on Apr 8, 2025
  17. added a commit that references this issue on Apr 9, 2025
  18. added 2 commits that reference this issue on Apr 10, 2025
  19. added a commit that references this issue on Apr 10, 2025
  20. added a commit that references this issue on Apr 10, 2025
  21. added a commit that references this issue on Apr 19, 2025
  22. RalfJung commented on Apr 30, 2025

    @RalfJung
    MemberAuthor

    @oli-obk do you know of anything left to do here? I think it is all done, isn't it?

  23. oli-obk commented on Apr 30, 2025

    @oli-obk
    Contributor

    Nope, this is done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

C-cleanupCategory: PRs that clean code up or issues documenting cleanup.E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.T-libsRelevant to the library team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions