[Change]: Remove no_link attribute

[bjorn3]

Change description

Remove the #[no_link] attribute

Area

linkage

Category

Other

FLS Paragraph ID

fls_ch9nkxkloozv

Change description (extended)

This is a pre-1.0 attribute that accidentally got stabilized. It was meant for compiler plugins, not regular crates. rust-lang/rust#152854 (comment) It is also rather fragile. If you use any function defined inside a crate you import using #[no_link] it might or might not work depending on if another crate has a normal dependency on it, if the function is codegened cross-crate and if the call site is optimized out or not. As such I think it should be deprecated and eventually removed. Even if we chose not to remove it from Rust, I do think it should not be documented in the FLS to avoid this fragile behavior in safety critical systems.

[skade]

Hi, good catch!

I don't think it should be fully removed, but should definitely be marked as not to be reimplemented in some form or fashion. I see an issue that removing it may just make other people later figure out that it's a public interface of rustc. This is an interesting case, and the first time we encounter one, where rustc is divergent against what should be the Rust spec. This is fine. We should spend some time designing the communication around it.

My proposal would be instead of removing it:
a) greying it out at the place where its visible and marking it in some way, at least for some time
b) collecting in a close (as in distance from the spec) document that clarifies where the rustc is divergent. This is absolutely no issue, spec divergence is a daily fact of life and needs to be highlighted to avoid people running into the same issue. This could even be done as part of the FLS as a start, we can always move it somewhere else.

This illustrates my earlier point btw. that specs are not necessarily the source of truth, but a discussion anchor.

[bjorn3]

Doesn't the FLS already only specify a subset of Rust? It only covers the 2021 edition for example. Removing #[no_link] from the FLS would just make this subset slightly smaller. Rustc would still be compliant to the FLS as it doesn't reject anything the FLS accepts, it just accepts things the FLS doesn't like is already the case.

[skade]

@bjorn3 You're confusing the current state with the scope. It should cover all.

The FLS does e.g. not cover the borrow checker, but that's mainly because there's reasons why I think it should not have an authoritative spec for now (such a specification may block future evolution) and it is constrained by having to enforce the referencing rules correctly. 2024 edition is in the works.

Compliance is not the main point of a spec, it's a discussion starter due to separate engineering.