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

Remove diagnostics from default features #379

Closed
wants to merge 1 commit into from

Conversation

tylerhou
Copy link
Contributor

@tylerhou tylerhou commented Feb 8, 2023

Diagnostics is still enabled for hydroflow and hydroflow_data when building non-wasm32 targets.

PR for #329.

Comment on lines 63 to 65
# Diagnostics feature does not work on wasm32.
[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
hydroflow_lang = { path = "../hydroflow_lang", features = ["diagnostics"] }
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't this be passed thru hydroflow_macro ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Arbitrarily chose hydroflow_lang since it was the only one not marked as optional. Can change to hydroflow_macro if you prefer that, I have no opinion.

Copy link
Member

Choose a reason for hiding this comment

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

Hmm yeah, I think we should have the feature in hydroflow_macro as well and go thru that, only have diagnostics enabled if the macros feature is enabled

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done, PTAL.

Copy link
Member

Choose a reason for hiding this comment

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

Hmm even when targeting wasm32 in hydroflow we should have diagnostics enabled, right? Because those diagnostics are for the macro which isn't being compiled to wasm32 regardless...

Copy link
Member

Choose a reason for hiding this comment

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

That's what I was thinking, if wasm is only the target we should still be able to have diagnostics

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Although, we don't even need these lines because when we build hydroflow_datalog, we will enable the diagnostic features anyway. So I think I can remove these lines from hydroflow/Cargo.toml entirely.

Copy link
Member

Choose a reason for hiding this comment

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

When we do [the macro parsing] compilation [step] in browser e.g. for the demo, that is when diagnostics dont work

@MingweiSamuel
Copy link
Member

This is just for compiling on your computer with wasm as a target, right? Why don't diagnostics work again?

@shadaj
Copy link
Member

shadaj commented Feb 8, 2023

Yeah I am slightly confused. I get disabling the default feature so that the core crates compile, but we should leave the feature on when we are depending on them from a proc macro crate because we aren't actually compiling to wasm32 in that case.

Diagnostics is still enabled for hydroflow and hydroflow_data when
building non-wasm32 targets.
@@ -3,6 +3,10 @@ name = "hydroflow_macro"
version = "0.1.0"
edition = "2021"

[features]
default = []
diagnostics = [ "hydroflow_lang/diagnostics" ]
Copy link
Member

Choose a reason for hiding this comment

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

So because this is a proc macro, diagnostics should just always be on rather than behind a propagated feature.

@tylerhou
Copy link
Contributor Author

Closing in favor of #414

@tylerhou tylerhou closed this Feb 27, 2023
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