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

libexpr: diagnostics (warning/error), tags framework #9060

Closed
wants to merge 2 commits into from

Conversation

inclyc
Copy link
Member

@inclyc inclyc commented Sep 28, 2023

Motivation

This is an initial support for warning & diagnostics (it is really large so I pushed it here for review). We talked about Nix language versioning in NixOS/rfcs#137 , and this PR brings some deprecate warnings for nix parser.

Previously we are just throwing exceptions, but it may not work for encountered some syntax we want to give a "warning" to the user, so I deferred the throwing after parsing.

Diagnostic types are generated from diagnostics.nix declaratively and we can maintain such a list with less pain, but it introduces build-time dependency for a working nix.

Context

Depends-on: #9059

How to read the diff

Please skip commits in #9059

Priorities

Add 👍 to pull requests you find important.

This is an NFC PR that splits epilogue & prologue from parser.

As mentioned in NixOS#8812, we can add static checking tools & auto
formatting for these files, but if it is written .y directly, the clang
parser cannot understand the code is actually "C++".
Copy link
Member Author

@inclyc inclyc left a comment

Choose a reason for hiding this comment

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

This PR just takes up an initial approach of adding diagnostics, please design-review the implementation to determine if we can go on :)

yylex_destroy(scanner);

if (res)
throw ParseError(data.error.value());
data.diags.checkRaise(data.state.positions);
Copy link
Member Author

Choose a reason for hiding this comment

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

currently the diagnostic engine will raise exceptions here, for backward compatibility. I think in the future we can pretty print the list of diagnostic

in
{
declarations = ''
/// Generated from diagnostic-gen.nix
Copy link
Member Author

Choose a reason for hiding this comment

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

- diagnostic-gen.nix
+ diagnostics-gen.nix

} // namespace nix
'';
idmacros = ''
/// Generated from diagnostic-gen.nix
Copy link
Member Author

Choose a reason for hiding this comment

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

same as above

$(d)/diagnostics-id.inc.hh

$(d)/diagnostics-id.inc.hh: $(d)/diagnostics-gen.nix $(d)/diagnostics.nix
$(trace-gen) $(nixcmd) --experimental-features "nix-command" eval --raw --file $< idmacros > $@
Copy link
Member Author

Choose a reason for hiding this comment

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

It seems like there are many problems caused by this line, because we want to open some directories in the sandbox-ed environment, should I do this?

@edolstra
Copy link
Member

Diagnostic types are generated from diagnostics.nix declaratively and we can maintain such a list with less pain, but it introduces build-time dependency for a working nix.

👎 on this, we really don't want a cyclic dependency. (What happens when nixVersions.nix_2_14 is removed from Nixpkgs? What if the only available Nix versions have this build-time dependency on Nix?)

Also, Nix is not a general purpose language and it's definitely not intended for C++ codegen. Better to use C++ macros or templates.

(Haven't looked at the rest of the PR.)

@inclyc
Copy link
Member Author

inclyc commented Sep 29, 2023

Better to use C++ macros or templates.

Thanks, closing.

@inclyc inclyc closed this Sep 29, 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.

2 participants