[RFC] Enforce logger being available via proc-macro #4322
+1,371
−752
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was trying to explore this as an option to remove the passing of
loggeraround everywhere in thechainandln::channelmodules. It didn't get nearly as clean as I was hoping, so really just curious if people would prefer this or what we currently have. Since its early-RFC didn't bother to clean up the commits, they're a mess.The advantage of this approach is that it enforces that loggers are always available (in tagged-
implblocks). It also handles passing loggers in many cases, especially method calls onself, but also inner fields that need such parameters.The disadvantage is that its really not fully automated. Because proc-macros can only be run within the context of a single file, and because they can't have global state (due to only being called on changed files), the proc-macro can only add loggers to calls made on things with explicit types (function parameters/declared variables with explicit types/etc). As a result, you end up either having to add a
let x: Type = xin things like for loops (which is largely demonstrated here) or simply manually adding theloggerargument where required. In cases where the logger isn't used this feels a bit annoying, and the magic isn't, well, magic.I don't have any feelings at all either way on this, the overhead of having to add the
loggerparameter or explicit type declarations in some places isn't very high, but also the win of not having to add explicit loggers doesn't feel that high to me either. The macro itself is a chunk of code, but its almost all boiler plate so not all that bad, really.Note that some of the code changes were move-onlys so you might have to look at a few of the commits.