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

use file-embed to make TH file embedding more robust #1614

Merged
merged 2 commits into from
Feb 8, 2024
Merged

Conversation

Ptival
Copy link
Contributor

@Ptival Ptival commented Jan 23, 2024

NOTE: We don't necessarily need to merge this. It does bring up a new library and removes the Safe flag from the modified file. It's useful for VSCode users, and may no longer be necessary in the near-to-medium future. At least, having this branch, I can help new users who run into the same issue.


Haskell Language Server still struggles a bit with opening projects that are subprojects of larger projects (in the git submodule sense).

When opening such projects from within their parent project, the overall project path remains the outermost one, which breaks relative paths of subprojects.

The file-embed has a utility to help with such path adjustments. Theoretically, HLS will eventually support "multi-home units", where different files will be compiled under different home folders if they belong to subprojects, but in the meantime, this un-breaks HLS for users that open Cryptol as a subproject of, say, SAW.

@Ptival
Copy link
Contributor Author

Ptival commented Jan 23, 2024

To explain this a little better, when you open the saw-script project, you may want to access files in deps/cryptol/.... But when you access these files, Prelude.cry will raise a compile-time exception, complaining that lib/Cryptol.cry does not exist. That's because, until multi-home units are well supported, the current working directory is still saw-script/, so lib/Cryptol.cry does not exist, but deps/cryptol/lib/Cryptol.cry does.

The makeRelativeToProject function takes care of making such adjustments where needed.

@yav
Copy link
Member

yav commented Jan 23, 2024

Seems like a reasonable change, removing the Safe pragma, and the new dependencies is not a big deal, file-embed only depends on things that we already depend on anyway, and it is very small.

Copy link
Contributor

@RyanGlScott RyanGlScott left a comment

Choose a reason for hiding this comment

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

I concur with @yav.

@RyanGlScott
Copy link
Contributor

file-embed-0.0.16.0 now includes a embedFileRelative x combinator that behaves the same way as makeRelativeToProject x >>= embedFile, which could be used to patch this patch slightly cleaner.

Haskell Language Server still struggles a bit with opening projects that
are subprojects of larger projects (in the git submodule sense).

When opening such projects from within their parent project, the overall
project path remains the outermost one, which breaks relative paths of
subprojects.

The file-embed has a utility to help with such path adjustments.
Theoretically, HLS will eventually support "multi-home units", where
different files will be compiled under different home folders if they
belong to subprojects, but in the meantime, this un-breaks HLS for users
that open Cryptol as a subproject of, say, SAW.
@Ptival
Copy link
Contributor Author

Ptival commented Feb 7, 2024

Nice find, updated!

@RyanGlScott
Copy link
Contributor

I've pushed a follow-up commit to regenerate the freeze files so that cabal can find build plans involving file-embed-0.0.16.0.

@Ptival Ptival merged commit 6c5bca3 into master Feb 8, 2024
46 checks passed
@Ptival Ptival deleted the vr/file-embed branch February 8, 2024 19:02
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

Successfully merging this pull request may close these issues.

3 participants