LLL: support symbols in the LIT keyword

[zigguratt]

The lit keyword works as expected when used inline:

(sha3 0x00 (lit 0x00 "Initialized(bool)"))

As with any LLL keyword, lit should be usable in a macro:

(def 'keccak (input)
  (sha3 0x00 (lit 0x00 input)))

However, when the keccak macro is subsequently invoked:

(keccak "Initialized(bool)")

the compiler produces this error:

Parse error.
/tmp/cpp-ethereum-20160629-19326-1m7sp55/solidity/liblll/CodeFragment.h(53): Throw in function void dev::eth::CodeFragment::error() const [T = dev::eth::InvalidLiteral]
Dynamic exception type: boost::exception_detail::clone_impl<dev::eth::InvalidLiteral>
std::exception::what: std::exception

[axic]

Is it happening in every case or certain cases only? Do you need some help tracking it down?

[zigguratt]

The error happens in all cases where lit is executed in a def and a string literal is expected. I haven't tested other input types. The lit docs describe three possible input literal types. This fails in a def macro because I believe the lit handler doesn't expect the type of input provided to it by def.

I'm not yet familiar enough with the liblll C++ source to be able to follow the trail effectively so yes, help tracking it down would be greatly appreciated. The lit handler is at line 274 of CodeFragment.cpp, and def is at line 225. I'll continue to try to figure it out as well.

Thanks, @axic!

[zigguratt]

I would normally look through the assembly code produced by the compiler to see what lit is getting, but the error prevents the assembly code from being generated.

[zigguratt]

A quick update: I just tested the other two types of input to lit in a macro and they both fail in the same way. So it's not specific to string literals.

[zigguratt]

Actually, I'd like to try to figure this out myself for a bit longer. There's no huge hurry and it would be good for me to get more familiar with the code anyway. I appreciate the offer of help and I'll probably take you up on it in the near future.

Thanks again, @axic!

[zigguratt]

It's not looking good for being able to fix this bug. @axic and I have looked in-depth at the lit code in the compiler. Having to look up symbols at compile time is a problem because, according to @axic, "the whole compiler works on the assumption that everything is evaluated runtime and no instructions are there to be evaluated an compile time".

That makes sense. Sadly, it introduces a situation where a legitimate LLL keyword can't be used in a macro because in that context it gets a symbol as input, which would require a compile-time evaluation.