Non-existing attributes are silently ignored

[Veetaha]

I tried this code

#[derive(Facet)]
#[facet(non_existing_config)]
struct Example {}

and it complied just fine. Instead, I expected to see a compile error rejecting a non-existing config attribute.

Meta

cargo tree | grep facet     
├── facet v0.27.15
│   ├── facet-core v0.27.15
│   ├── facet-macros v0.27.15 (proc-macro)
│   │   └── facet-macros-emit v0.27.15
│   │       ├── facet-macros-parse v0.27.15
├── facet-toml v0.25.17
│   ├── facet-core v0.27.15 (*)
│   ├── facet-reflect v0.27.15
│   │   ├── facet-core v0.27.15 (*)
│   ├── facet-serialize v0.24.17
│   │   ├── facet-core v0.27.15 (*)
│   │   ├── facet-reflect v0.27.15 (*)

[fasterthanlime]

I agree that it's a bug, and that arbitrary attributes should have special syntax (maybe start with a @ or something).

[Veetaha]

If you are referring to attaching arbitrary values to types, then it may not be strictly required. As long as the value you are trying attach is not in scope - you'd get an error "no function or variable exist with this name"

[fasterthanlime]

What I'm saying is:

• We should catch silly mistakes like doing #[facet(renam = "blah")]
• We should still allow #[facet(@my_custom_attribute = "Do something weird!")]

[ppentchev]

FWIW, I use custom attributes in my WIP crate for parsing various Debian Apt files in the so-called "deb822" format. (inb4: if anybody actually looks at the code that I use to parse those attributes, yes, I will learn to use unsynn RSN, I know this is just silly). So yeah, of course I'm completely open to the idea of renaming those attributes to e.g. have a custom prefix, but please keep it possible to use them :)

(and thanks again for making it possible to use them at all, as well as for making facet a thing at all)