Skip to content

Disambiguate distributed slices with the same name #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dtolnay opened this issue Jan 27, 2019 · 2 comments · Fixed by #53
Closed

Disambiguate distributed slices with the same name #3

dtolnay opened this issue Jan 27, 2019 · 2 comments · Fixed by #53

Comments

@dtolnay
Copy link
Owner

dtolnay commented Jan 27, 2019

The only unique identifier in the link section name currently is the name of the static. Multiple crates could make distributed slices with the same name. We should do one of:

  • disambiguate using the crate name in which the static is declared,
  • trigger failure during compilation or linking,
  • detect the duplication with a runtime panic.
@mmastrac
Copy link

Could TypeId somehow be used for this? It's const in more recent builds.

@luser
Copy link

luser commented Aug 19, 2020

In the interest of "principle of least surprise" I would suggest:

  • Link section names should be prefixed by crate name.
  • Declaring distributed slice items to be consumed by a different crate should require explicitly specifying that crate's name as a prefix. #[distributed_slice(X)] should be equivalent to #[distributed_slice(::crate::X)]–that is, if an explicit crate name is not provided, it should use the current crate name as a prefix.
  • Duplicate distributed slice declarations with the exact same name resulting from multiple semver-incompatible versions of a crate being linked into the same binary should produce an error. This situation already occurs with crates that use static globals like env-logger. An alternative would be to explicitly include the target crate's version number in the section name and allow multiple versions to coexist. That would fit with cargo's existing willingness to work with multiple versions of crates in your dependency tree, since that's a situation people find themselves in in the real world.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants