Refactor AsRef and AsMut derives

[MegaBluejay]

Synopsis

This PR is a part of replacing all attributes having syn::Meta syntax to custom parsing, similarly to #241, #248

Paves the way for #285, and possibly other enhancements such as an opt-in #123

Solution

Implement custom attribute parsing without State

Checklist

• Documentation is updated (if required)
• Tests are added/updated (if required)
• CHANGELOG entry is added (if required)

[JelteF]

Thanks for the contribution. Just to be clear, this isn't adding any new features yet right? Only doing refactoring to allow future features. (I like that approach, just making sure I understand correctly)

[MegaBluejay]

Only doing refactoring to allow future features.

Yes, that's correct, this PR is refactoring only

[MegaBluejay]

Since they're essentially identical, I think it makes sense to use the same deriving function for AsRef and AsMut.

I can't think of any hypothetical features that should apply to only one of them, and this would facilitate keeping them in sync.

[tyranron]

@MegaBluejay not bad, but needs polishing.

I've restructured modules in the way we have for fmt macros.

Also, please look at tests/as_ref.rs and tests/as_mut.rs, whether it makes sense to extend their test cases to cover more edge cases.

[tyranron]

@JelteF the interesting question:

Since AsRef and AsMut are effectively the same regarding implementation, should we unite them under a single as_ref Cargo feature as we do for Display-like derives?

I think it's quite reasonable. May be done as a separate PR, though, after merging this one.

[JelteF]

I think it's quite reasonable. May be done as a separate PR, though, after merging this one.

Yes sounds good to me. But indeed let's do that in a follow-up PR.

[JelteF]

@tyranron feel free to sign off on after you are happy. I took a quick look and it looks reasonable to me.

[tyranron]

@MegaBluejay I've heavily refactored your implementation. Consider the changes.

Regarding the implementation itself, it's good enough for merging already. However, the tests are still lacking features coverage very much, which I requested in previous review. No tests for #[as_ref] and #[as_ref(skip)] were added at all. I've restructured the existing tests in as_mut, so they have some logical sequence, but I think it's not good enough yet.

Let's break it by modules:

mod single_field {
    mod tuple {
          // Clean
          // Forward
          // FieldForward
          mod generic {
              // Clean
              // Forward
              // FieldForward
          }
    }
    mod named {
          // Clean
          // Forward
          // FieldForward
          mod generic {
              // Clean
              // Forward
              // FieldForward
          }
    }
}
mod multi_field {
    mod tuple {
          // Clean
          // Forward
          // Field (multiple impls)
          // Ignored (multiple impls)
          mod generic {
              // Clean
              // Forward
              // Field (multiple impls)
              // Ignored (multiple impls)
          }
    }
    mod named {
          // Clean
          // Forward
          // Field (multiple impls)
          // Ignored (multiple impls)
          mod generic {
              // Clean
              // Forward
              // Field (multiple impls)
              // Ignored (multiple impls)
          }
    }
}
```

[tyranron]

@MegaBluejay in other derive macros (see compile_fail for them) we always talk about skip attribute and keep ignore as an alias. Why do the opposite here?

I've created utils::skip::Attribute, which can be reused, so we don't repeat the same logic everywhere.

After merging this PR, please open a new one which refactors From/Into/Debug/Display to reuse utils::skip and utils::forward where applicable.

[tyranron]

@MegaBluejay good! 👍

After merging this PR, please do as subsequent ones:

1. Since AsRef and AsMut are effectively the same regarding implementation, should we unite them under a single as_ref Cargo feature as we do for Display-like derives?

   I think it's quite reasonable. May be done as a separate PR, though, after merging this one.

2. After merging this PR, please open a new one which refactors From/Into/Debug/Display to reuse utils::skip and utils::forward where applicable.