No obvious way to format unreadable literals in generated code

[spease]

The string_cache_codegen crate uses quote to generate macros that consist of only an expression, and that expression in turn can contain a numeric literal. I was working on a patch to allow unreadable literals for that macro to push upstream to string_cache_codegen, but since you can't use attributes on expressions, it's a bit of a nonstarter. I shifted my approach to trying to figure out how to format numbers so as to separate via thousands, but so far I haven't found a way to do that either (save for maybe pulling in a third-party library).

EG: https://github.com/servo/string-cache/blob/435f62926456e5538c9f2a9612f07be1ea456710/string-cache-codegen/lib.rs#L196

The data gets passed to quote here:
https://github.com/servo/string-cache/blob/435f62926456e5538c9f2a9612f07be1ea456710/string-cache-codegen/lib.rs#L258

I'm not quite sure what the correct approach is here, but this seems like a bit of a hangup for certain cases.

[flip1995]

If the code is generated and triggers style lints, you should just allow these lints in the generated code, since style flaws don't really matter there.

[spease]

That doesn’t fix the issue in this case because clippy appears to lint post-macro-expansion. But I can’t add allow attributes within the generated macro because they can’t be used on an expression. Even after a couple hours of me and #beginners trying to come up with additional curly brackets, closures, assigning variables, etc we couldn’t get an attribute in the macro.

…

On May 14, 2019, at 02:10, Philipp Krones ***@***.***> wrote: If the code is generated and triggers style lints, you should just allow these lints in the generated code, since style flaws don't really matter there. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[oli-obk]

We could add an in_macro check for the lint. Seems not helpful to lint this in generated code

If I understand the issue, the lint is being triggered where the macros are invoked and not where they are defined. This just needs a macro check. Playground

[spease]

While this will make the warning go away, it will pollute the codebase with disconnected allow attributes. These could also have the effect of muting legitimate cases.

I also had the same problems with too_many_lines and unseparated_literal_suffix when I turned pedantic lints on.

Right now I’m working around it with a library-wide directive that can be removed if/when there’s a more modular approach that goes with the macro itself.

EDIT: Also not sure if this was clear, but the other approach of having the generated code generate correct literals doesn’t seem easily possible due to a lack of an easy way to generate literals compatible with the lint. Not sure if this is within the scope of the quote crate.

[flip1995]

Oh I misunderstood this issue.

I'm going ahead and add a macro check to the lints too_many_lines and unreadable_literal. The unseparated_literal_suffix should be easy to fix in macros, so I wouldn't add a macro check there.

[flip1995]

I can't reproduce this with a macro with the too_many_lines lint: Playground

[spease]

The too_many_lines lint occurred with the same generated string_cache_codegen files as the others, but it’s possible it was non-macro code- I just immediately switched it off because it was only two (generated) files. I’ll see about getting the allow attribute added to the code generated by the string_cache_codegen crate.