Skip to content
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

[RFC] Name Mangling for Package Private Libraries #3864

Open
rgrinberg opened this issue Oct 14, 2020 · 3 comments
Open

[RFC] Name Mangling for Package Private Libraries #3864

rgrinberg opened this issue Oct 14, 2020 · 3 comments
Assignees
Labels
proposal RFC's that are awaiting discussion to be accepted or rejected

Comments

@rgrinberg
Copy link
Member

This was supposed to be done as part of #3655, but since it turns out be a pretty large change, I decided to create a separate proposal for this.

Problem

Private libraries defined in different projects may collide. Consider these two private libraries defined in different dune projects:

(library
 (name helper)
 (package foo))

and

(library
 (name helper)
 (package bar))

While the two libraries can be installed, they cannot be used in the same library or executable.

Solution

Choose a compilation unit name that reflects that such private libraries are unique, and then use -open on libraries that users of such library to hide it. The scheme will look as follows:

  • pkg__private__helper will be the prefix for the compilation unit and the name of the lib interface module.
  • There will be an additional module pkg__private__helper__pub with the following rename:
module Helper = Pkg__private__helper
  • Whenever helper is used, -open Pkg__private__helper__pub will be inserted.

Note that this proposal will also require package private libraries to be (wrapped true). I think that's a good idea regardless.

I'd like to see what @bobot and @aalekseyev think about this.

@rgrinberg rgrinberg added the proposal RFC's that are awaiting discussion to be accepted or rejected label Oct 14, 2020
@bobot
Copy link
Collaborator

bobot commented Oct 15, 2020

Is it $pkg__private__helper so it becomes bar__private__helper and foo__private__helper?

I believe it is your idea but just to precise:

  • It must go before the flags of the users. So they could do -open Helper
  • compiled with the option -no-alias-deps.

I'm ok with it.

@rgrinberg
Copy link
Member Author

Is it $pkg__private__helper so it becomes bar__private__helper and foo__private__helper?

That's right. The package should guarantee uniqueness in this case.

It must go before the flags of the users. So they could do -open Helper

Good point.

@ghost
Copy link

ghost commented Oct 28, 2020

We discussed the proposal during the meeting and accepted it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal RFC's that are awaiting discussion to be accepted or rejected
Projects
None yet
Development

No branches or pull requests

2 participants