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

Generated code incompatible with -D rust-2018-idioms #364

Closed
shayne-fletcher opened this issue Nov 1, 2022 · 7 comments
Closed

Generated code incompatible with -D rust-2018-idioms #364

shayne-fletcher opened this issue Nov 1, 2022 · 7 comments

Comments

@shayne-fletcher
Copy link

With -D rust-2018-idioms and warnings as errors hidden lifetime parameters in generated code are causing compilation failures e.g.

603 |                       mut __gt_args: ::std::vec::Drain<'_, ::lrpar::parser::AStackType<lrlex::lexemes::DefaultLexeme<u8>, __GtActionsKind<'input>>>,
    |                                                        +++
error: hidden lifetime parameters in types are deprecated

I'd disable this by injecting #![allow(elided_lifetimes_in_paths)] at the start of the generated module but I can't find a way to do this (is there one?)

@shayne-fletcher
Copy link
Author

never mind, i think i'm just using the tool in an unexpected way :)

@ratmice
Copy link
Collaborator

ratmice commented Nov 1, 2022

FWIW, I had a look using the quick start/calc example from the grmtools book, and rustc 1.64, and wasn't able to reproduce with RUSTFLAGS="-D rust-2018-idioms" cargo build, so if it is something that we want to support, I haven't been able to reproduce it yet

@ratmice
Copy link
Collaborator

ratmice commented Nov 1, 2022

I'd disable this by injecting #![allow(elided_lifetimes_in_paths)] at the start of the generated module but I can't find a way to do this (is there one?)

Forgot to respond to this, I think there used to be a hack (I'm not sure if it still works, I seem to recall it might not),
that you could do something to the effect of:

mod _tmp_ {
    #![allow(elided_lifetimes_in_paths)]
   lrpar_mod!("calc.y");
}
use _tmp_::*;

To add attributes at the start of a module, it might be worth trying that.

@shayne-fletcher
Copy link
Author

shayne-fletcher commented Nov 1, 2022

thanks for taking a look!

i expect it would be nice to sort out.

i have straightened out my usage scheme and a workaround. here's how i'm doing it (in case it helps somebody in some way). i'm building a crate asdl. the crate root is asdl.rs:

// ---
// asdl.rs
#![allow(elided_lifetimes_in_paths)]  
pub mod lexer;
pub mod parser;

// ---
// lexer.rs
include!(env!("asdl_l"));                                                                 
pub use asdl_l::*;                                                                        

// ---
// parser.rs
include!(env!("asdl_y"));
pub use asdl_y::*;

in the presence of the lint group -Drust-2018-idioms (or equivalently the flag -Delided-lifetimes-in-paths) and without the #![allow(elided_lifetimes_in_paths)] the error manifests.

seems i'm using rustc 1.64.0-dev.

@shayne-fletcher
Copy link
Author

thanks again @ratmice. i'm having a great experience with these tools! 😀

@shayne-fletcher
Copy link
Author

I'd disable this by injecting #![allow(elided_lifetimes_in_paths)] at the start of the generated module but I can't find a way to do this (is there one?)

Forgot to respond to this, I think there used to be a hack (I'm not sure if it still works, I seem to recall it might not), that you could do something to the effect of:

mod _tmp_ {
    #![allow(elided_lifetimes_in_paths)]
   lrpar_mod!("calc.y");
}
use _tmp_::*;

To add attributes at the start of a module, it might be worth trying that.

lol. great minds think alike! ;)

@ratmice
Copy link
Collaborator

ratmice commented Nov 3, 2022

in #367 we did change the code generation so this should work with that lint without hacks in the next release.

ratmice added a commit to ratmice/grmtools that referenced this issue Dec 13, 2023
The unsafe code test was triggering a clippy lint, in fixing that
it became apparent that unsafe code in the program section was
being denied inadvertently.

Reorganize the codegen so the generated parse tables and parse
functions are in their own `mod` separate from user actions.
That module now denies unsafe. User actions are kept in the
parent module where unsafe is still allowed.

The user provided program section is now placed at the top
of the module so it may contain it's own `#![inner_attributes]`.
This is a desired feature see softdevteam#364 for one instance. While
this can be used it also applies the attribute to the generated
code in the submodule in ways that could compilation failure.

Since there is not currently a way to isolate the attributes of the
parser module from the user code section, it isn't currently a
documented or well supported feature.
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

2 participants