Make sure Bigarray shadows Stdlib.Bigarray#2256
Conversation
Signed-off-by: Jeremie Dimino <jeremie@dimino.org>
|
The limitation is serious, as it means that we cannot try an uninstalled compiler without getting some weird behaviors. And as you noticed it somewhat messes up our test suite. This means it's probably time to try reopening #1569 or something similar. |
|
Personally, I would like #1569 to be reopened as it makes reasoning about all this a lot simpler and it is also beneficial for users. I can think of alternative ways, but that would be more complexity that might make things more difficult in the future. |
|
I'm closing this since this is not a good fix. I sent an email on caml-devel to discuss how to proceed. |
|
@diml Would you mind pinging this issue again with the number of the follow-on issue or PR, once it is open/reopened, so that subscribers can monitor it? |
|
Sure, no problem |
|
@aantron, we discussed this on caml-devel. The only additional feature provided by the FTR, we have been slowly moving |
|
Thanks, @diml. I'll adapt Lwt with some conditional compilation (since we need to support old versions of OCaml). |
|
Thanks @damiendoligez! |
In trunk and 4.08,
Stdlib.BigarrayshadowsBigarray(from thebigarraylibrary). The reason is that the initial environment is constructed as follow:Where
dXare the include directories specified by the user via the-Ioption andMXare the implicitly opened modules specified via-open. This seems correct, however there is one catch: thebigarraylibrary is installed in the same directory as the stdlib, which means that theopen(env, Stdlib)shadows the toplevelBigarraymodule :/To workaround this issue, this patch reintroduces the names coming
stdlib_dirafter opening theStdlibmodule, i.e. the initial environment is now constructed as follow:I tried but I didn't managed to write a test for this; in any test I wrote,
Stdlib.Bigarraywas still shadowingBigarrayeven after this patch. I'm assuming that this is because the testsuite must use some special flags such as-nopervasivesor-nostdlibin order to use a local stdlib. However, I did the following manual testing:with trunk, I get a
unbound value map_fileerror, while with this patch I properly get a deprecation message.Limitation
If one uses compilation flags such as
-nopervasives -open Stdlibfor special purposes, thenStdlib.Bigarraywill still shadowBigarray. I don't have a good solution for this, except installing the various libraries in their own sub-directory as done in #1569, which would avoid this issue altogether.