Fixes a bug with iterating over the current value

[huntiep]

I found this bug when working with Enums. It looks like this is all that is needed to fix it, but I only looked at scanner.rs so I might have missed something.

[huntiep]

Related to this, are there any options available for improving error messages on parse failures? For this bug the error was

error: proc-macro derive panicked
  --> tests/iteration.rs:46:14
   |
46 |     #[derive(BartDisplay)]
   |              ^^^^^^^^^^^
   |
   = help: message: called `Result::unwrap()` on an `Err` value: Mismatch

which tells me nothing. I'm not familiar with proc macros; so I'm not sure if that is the issue or if it's something that could be improved in the library.

[maghoff]

Super, thanks!

Could you add a test for this in scanner.rs also? Something like bart_tag_matches_scope_section_opener?

[maghoff]

Oh, it is possible to make better error messages. The error messages are panic!s that originate in the BartDisplay proc macro. PRs welcome ;)

Unfortunately, it does not seem possible to get the compiler to point anywhere other than at BartDisplay. I have a few ideas I want to throw at the greater Rust community for error handling in derive proc macros, if I ever get around to it. I think Bart 1.0 would come first :)

[huntiep]

For this test should SectionType be Iteration? That is what bart_tag("{{#.}}") is returning. I'm not sure if it should be Iteration or Scope.

[maghoff]

The SectionType should be Iteration. In your other test you are using this to iterate over a Vec, so that checks out.

But it highlights a parsing ambiguity. The syntax for scoping is, for example, {{#ape.}}. So what then, if we want to scope into the . object? {{#..}}? Or iterate over the .. object? {{#..}}? I think the code on master always prefers Scope, while your branch always prefers Iteration. Both should be possible to express somehow... 🤔

[huntiep]

I tried looking into the parsing ambiguity, but I couldn't think of an example to test with. If you have some test cases in mind I can look into it. It might be beyond me though.

[huntiep]

Ping @maghoff Did you want to address the parsing ambiguity in this pull request, or in a different one?

[maghoff]

Hi, I'm traveling. I'll get to this PR in a while.