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

Handle module abbreviations better #23

Closed
safesparrow opened this issue Nov 15, 2022 · 1 comment
Closed

Handle module abbreviations better #23

safesparrow opened this issue Nov 15, 2022 · 1 comment

Comments

@safesparrow
Copy link
Owner

Currently when we see a module, we decide that the given file depends on all the previous files and all the files above it depend on it:

// Assume that a file with module abbreviations can depend on anything
match node.Data.Abbreviations |> Array.isEmpty |> not with
| true -> nodes |> Array.map (fun n -> n.File)

This is a safety we need without fully understanding the behaviour and implementing it.

This ticket is to avoid this defensive mechanism.

Also: module abbreviations in signature files are currently not supported, we should fix it:

failwith "Module abbreviations are not currently supported"

@safesparrow safesparrow changed the title Handle module and type abbreviations better Handle module abbreviations better Nov 15, 2022
@safesparrow
Copy link
Owner Author

This is being handled in #24

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant