Georgi Lyubenov

So there are at least two bugs here: * `infer_main_module` is either "buggy" (it's getting passed `custom_main`, which is not a valid module name which gets checked, hence it returns...

Upon further inspection, the following assumption is currently made (and not documented as far as I can tell): * if `main_file` is present, we're **not** building with `haskell_module`s `determine_module_names` looks...

I think it would be fair to just document this and say "if you're building with modules, you **must** write the fully qualified name of the main function in `main_function`".

If we want to support a specifying `main_function` being not fully qualified and in a file that's not `Main.hs`, I guess we could go the route of adding `main_module` which...

> where do you see that assumption? `path_utils.bzl`, line 122 - https://github.com/pranaysashank/rules_haskell/blob/f0af91817ea66972c05b48b471fd58e5aae195f5/haskell/private/path_utils.bzl#L122

The buildifier test has failed (`bazel test //:buildifier_test`). You should run `bazel run //:buildifier-fix` and commit the fix it generated. EDIT: fixed this

What's the status here? Is this only a docs issue, or are there some improvements we could make towards better compatibility with HLS?

Upon some further thought - I'm not sure if supporting this is even desirable. Usually you'd prefer to let bazel manage the dependencies instead of introducing implicit such dependencies via...

I think the solution to add something like an `include_dirs` attribute to `haskell_{library,binary,test}` sounds better to me - it's very implicit otherwise, using the `includes` header of `cc_library`. It would...

Do you think it would be worth it to ask the ghc people to eventually expose some of the things that are copied from ghc? I can also do the...