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

Add an early error when compiling different modules with mismatching -for-pack #1391

Merged
merged 5 commits into from Sep 13, 2022

Conversation

chambart
Copy link
Contributor

@chambart chambart commented Oct 2, 2017

Building different modules with different -for-pack options can lead to particularly inscrutable error messages. (See https://caml.inria.fr/mantis/view.php?id=7645)

This patch forbid it with ocamlopt. This is a breaking change, but I think that it can only uncover hidden build system bugs. This triggers for instance on the lib-dynlink-native test (The source of the travis failure). Which I consider to be such a build system bug (or quite strange test).

Such an early test is not possible in bytecode as cmo files are only used at link time and -for-pack is ignored.

@damiendoligez damiendoligez added this to the 4.07-or-later milestone Oct 11, 2017
Copy link
Contributor

@mshinwell mshinwell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good change. Can you confirm that it does fix cases such as MPR#7349 (which I think wasn't too hard to reproduce from the example given)?

@@ -44,7 +44,8 @@ type unit_infos =
mutable ui_apply_fun: int list; (* Apply functions needed *)
mutable ui_send_fun: int list; (* Send functions needed *)
mutable ui_export_info: export_info;
mutable ui_force_link: bool } (* Always linked *)
mutable ui_force_link: bool; (* Always linked *)
mutable ui_for_pack: string option } (* was it built with -for-pack ? *)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs a magic number change, I think.

@@ -205,6 +208,11 @@ let get_global_info global_ident = (
let (ui, crc) = read_unit_info filename in
if ui.ui_name <> modname then
raise(Error(Illegal_renaming(modname, ui.ui_name, filename)));
(match ui.ui_for_pack, current_unit.ui_for_pack with
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a comment explaining why this check isn't symmetric (between [ui.ui_for_pack] and [current_unit.ui_for_pack])?

fprintf ppf "%a@ was built with -for-pack %s, but this module isn't"
Location.print_filename filename pack_1
| Mismatching_for_pack(filename, pack_1, Some pack_2) ->
fprintf ppf "%a@ was built with -for-pack %s, but this module is built\
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is a space needed before the backslash?

@@ -443,6 +451,13 @@ let report_error ppf = function
fprintf ppf "%a@ contains the description for unit\
@ %s when %s was expected"
Location.print_filename filename name modname
| Mismatching_for_pack(filename, pack_1, None) ->
fprintf ppf "%a@ was built with -for-pack %s, but this module isn't"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is "this module" the correct terminology? I'm wondering if it should be more explicit that it corresponds to the current compilation unit.
Also, I would write "is not" instead of "isn't" here.

@chambart
Copy link
Contributor Author

chambart commented Jan 9, 2018

It won't fix this situation, but it will produce a proper error.

@mshinwell
Copy link
Contributor

Right, by "fix" I meant "produce a proper error", so that's good.

@chambart chambart changed the base branch from 4.06 to trunk January 30, 2018 17:10
@chambart
Copy link
Contributor Author

Rebased against trunk, add Changes.

@mshinwell
Copy link
Contributor

I've removed the magic number changes, since these are now done centrally, and merged this with trunk. Assuming this passes CI this can be merged.

@mshinwell
Copy link
Contributor

Hmm, I have a feeling the failures now are because this is catching a problem with one of the dynlink test cases, which I think I fixed in my big dynlink-refactoring patch that hasn't been reviewed yet...

@xavierleroy
Copy link
Contributor

One year later, is this PR dead? or could we bring it to a merge?

@mshinwell
Copy link
Contributor

I will discuss this with @chambart , as I've done some work in this area recently.

@gasche
Copy link
Member

gasche commented Apr 28, 2021

No change since september 2019, so closing. @chambart or @mshinwell, feel free to reopen if you wish to revisit the issue.

@gasche gasche closed this Apr 28, 2021
@chambart
Copy link
Contributor Author

chambart commented Sep 5, 2022

@lthls rebased it.

chambart and others added 5 commits September 5, 2022 16:13
…-for-pack

If module A is build with -for-pack X and module B with -for-pack Y and
A uses B, this will trigger when building A (with ocamlopt) rather than
when linking, or when building some further module using both A and B.
@lthls
Copy link
Contributor

lthls commented Sep 6, 2022

A quick note on the deleted test: I could have fixed it to refer to the pack through the Mypack module, but then it would have become almost identical to the pack_client.ml test so it would have been redundant. And of all the tests that are compiled, only three are actually run at the moment (and the pack tests are not in those three), so it didn't feel very important to keep the test.

However, looking at that test file I see that we do produce a packed1.cmxs file even though packed1.cmx is compiled with -for-pack Mypack, and I think this should be forbidden too.

@lthls
Copy link
Contributor

lthls commented Sep 13, 2022

Nobody has complained, so I'm merging this.

@lthls lthls merged commit c53e114 into ocaml:trunk Sep 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants