FromMeta parsing doesn't error on unrecognized literals in attribute list

[leighmcculloch]

FromMeta doesn't error in all cases that unexpected tokens end up in the attribute list.

It doesn't error in the case that a string literal is in the attribute list. For example:

#[myattribute(myfield = "export", "randomliteral")]

Parsing the attribute list will error if it sees a field that is anticipated, but not for "randomliteral" which it will ignore.

cc @jonjove

[leighmcculloch]

I expect this is being caused because the NestedMeta::Lit case is not being treated as an error when it is encountered in the AttributeArgs.

[leighmcculloch]

Maybe this block of generated code in the macro is the issue, since it ignores metas that are of the literal type:

darling/core/src/codegen/variant_data.rs

Lines 60 to 68 in dbdcd93

	for __item in __items {
	if let ::syn::NestedMeta::Meta(ref __inner) = *__item {
	let __name = ::darling::util::path_to_string(__inner.path());
	match __name.as_str() {
	#(#arms)*
	__other => { #handle_unknown }
	}
	}
	}

I suspect the fix might be the following, however it is unclear to me what the ramifications if this code path has broader use:

  for __item in __items { 
      if let ::syn::NestedMeta::Meta(ref __inner) = *__item { 
          let __name = ::darling::util::path_to_string(__inner.path()); 
          match __name.as_str() { 
              #(#arms)* 
              __other => { #handle_unknown } 
          } 
+     } else {
+         // TODO: Error?
      }
  } 

[leighmcculloch]

@TedDriggs I've opened a fix for this issue in #193.

[casey]

Just wanted to mention that I ran into this. I was trying to parse something like this:

#[derive(MyTrait)]
#[my_trait("foo")]
struct Foo {
}
``

Which was not working, but which wasn't throwing an error, I think because the literal "foo" was being ignored.