attributes: added missing RecordTypes for instrument

[kaffarell]

When using a function annotated with #[instrument] it parses the parameters of the function and records them either using Value or using std::fmt::Debug. There were a few types that implement Value but were missing the RecordTypes array. Added them + a unit test for a single one.

Fixed: #2775

[safinaskar]

I don't like this PR. I will write my arguments later (hopefully today), please, wait

[safinaskar]

It seems this code determines whether the type implements Value at macro level. By parsing type. This is fragile. And this doesn't agree with spirit of Rust. This is very ugly. This is easy to broke such code, for example:

use std::string::String as Foo;
#[tracing::instrument]
fn f(x: Foo) {}

In this example Foo is actually String, and hence implements Value, but the macro will not be able to see this.

Also current solution assumes that we need to keep in sync implementors of Value and that list in macro. Which is obvious violation of don't-repeat-yourself principle.

The problem should be solved at Rust language level, not in macro level. How to do this? Well, I know the solution. What we essentially need is writing macro, which will determine does given expression implement given trait or not. If yes, then perform some action, if not, then perform other action. This is possible to do in Rust using one very ugly trick. One of the ugliest of the tricks in the language. Which abuses over-complicated rules for method call expression ( https://doc.rust-lang.org/nightly/reference/expressions/method-call-expr.html ). Here is this trick: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=17babd1d98bb46d1aefa6c879cb31bc3 . It is possible that you can write something similar shorter, but the idea will be the same. Of course, the code possibly should be adapted for your needs. For example, it is possible that in your case T should not be stored inside A, and we need to store &T instead or even PhantomData<T>. I learned this trick from some article, but I lost it. If you know this article, please, let me know.

I think whole existence of such trick in the language proves that Rust is not perfect. I'm nearly sure that real PLT (programming language theory) people (such as people from https://types.pl or http://lambda-the-ultimate.org/ or https://langdev.stackexchange.com ) will completely dislike this trick. Still it works, and it saves our day. It is correct, unlike current macro level implementation, and hence lesser evil.

UPD Oct 30: I found slightly simpler way, see next comment

UPD Nov 2: This method is called autoref specialization. Thanks, @davidbarsky

[safinaskar]

I found slightly simpler way, based on the same idea. It exploits method similar to well-known a.clone() ambiguity.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=449ecdebc93012d4f32ec007a5b329b8

[davidbarsky]

@safinaskar I think that you're describing autoref specialization. Generally speaking, exposing type information to macros in a hygienic manner is generally considered to be an open research question in PL, and while it'd be nice for Rust to have a solution to this, I don't really expect one in the near future.

Also current solution assumes that we need to keep in sync implementors of Value and that list in macro. Which is obvious violation of don't-repeat-yourself principle.

My feeling is that if we want to prevent this issue from happening in the future, we can write a CLI that parses the rustdoc JSON output and ensures that the list is not out of date. A rust-analyzer style xtask approach can work here, but that's outside of the scope of this PR.

@kaffarell I think this PR is good and resolves the immediate issue. @safinaskar if you'd like to discuss alternatives, please open an issue.

[CAD97]

Old PR implementing the autoref specialization approach: #1612

[davidbarsky]

Old PR implementing the autoref specialization approach: #1612

Man, I forgot about that PR, but we should get it in for tracing 0.2, though. Would be nice to sidestep this issue.

[fduwjj]

Is there any reason why this change is not included in the release 0.1.27? We need this fix to make our logging works.

[kaffarell]

This was merged after the release of 0.1.27. It will be included in the next version.