You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 6736 Reporter: jordojw Status: closed (set by @xavierleroy on 2016-12-07T10:47:23Z) Resolution: not a bug Priority: normal Severity: minor OS: OS X OS Version: Yosemite Version: 4.02.0 Target version: 4.02.2+dev / +rc1 Category: ~DO NOT USE (was: OCaml general)
Bug description
My fork of the OCaml compiler is slightly in disarray at the moment, so it's entirely possible that I've done something to break the compiler, but when passing
-intf ./blah.customInterfaceExtension
to specify that this file is an interface with a custom extension, ./blah.ml is not checked against it. Instead, it silently passes because it still looks for ./blah.mli and cannot find it. If I pass the -intf-suffix flag to be ".customInterfaceExtension", everything works correctly, but the benefit of -intf is that you can mix your standard .mli files with your custom extensions.
Here is the line in typemod.ml that appears to be the culprit:
Misc.chop_extension_if_any sourcefile ^!Config.interface_suffix in
It always falls back to the --intf-suffix version of the ml file.
Though, I have a hard time believing that this has never been caught before. On the other hand, the nature of the bug is that compile errors are incorrectly suppressed due to not checking against an interface file at all so that might explain why it hasn't been reported. The most likely explanation is that I've done something horrible to my fork of the compiler, but at the very least this code looks plain wrong/confusing.
Steps to reproduce
Run ocamlc with -intf ./yourFile.customExtension yourFile.ml
Interface type errors are not caught.
The text was updated successfully, but these errors were encountered:
Actually, this doesn't even look like a bug to me: the specification of -intf is that it compiles the following file as an interface. It is nowhere stated that this should register the file to be used as interface for a following module. Of course this specification is too weak for some use cases, this is why there is an -intf-suffix option.
It could be possible to change the semantics, but this looks like a hack to me, because it requires to compile the interface and the implementation simultaneously.
So you're saying the workaround is to compile each file individually? It would be nice to be able to supply a list of files and somehow indicate which specific file should be treated as the interface for an implementation. I suppose it's low priority, but it was strange how the behavior was different for -intf when passing multiple input files to ocamlc. It was strange that -intf required that I perform several more separate compiler invocations than without -intf. Just a thought.
Original bug ID: 6736
Reporter: jordojw
Status: closed (set by @xavierleroy on 2016-12-07T10:47:23Z)
Resolution: not a bug
Priority: normal
Severity: minor
OS: OS X
OS Version: Yosemite
Version: 4.02.0
Target version: 4.02.2+dev / +rc1
Category: ~DO NOT USE (was: OCaml general)
Bug description
My fork of the OCaml compiler is slightly in disarray at the moment, so it's entirely possible that I've done something to break the compiler, but when passing
-intf ./blah.customInterfaceExtension
to specify that this file is an interface with a custom extension, ./blah.ml is not checked against it. Instead, it silently passes because it still looks for ./blah.mli and cannot find it. If I pass the -intf-suffix flag to be ".customInterfaceExtension", everything works correctly, but the benefit of -intf is that you can mix your standard .mli files with your custom extensions.
Here is the line in typemod.ml that appears to be the culprit:
ocaml/typing/typemod.ml
Line 1569 in 055d5ff
It always falls back to the --intf-suffix version of the ml file.
Though, I have a hard time believing that this has never been caught before. On the other hand, the nature of the bug is that compile errors are incorrectly suppressed due to not checking against an interface file at all so that might explain why it hasn't been reported. The most likely explanation is that I've done something horrible to my fork of the compiler, but at the very least this code looks plain wrong/confusing.
Steps to reproduce
Run ocamlc with -intf ./yourFile.customExtension yourFile.ml
Interface type errors are not caught.
The text was updated successfully, but these errors were encountered: