Properly, contracts are now looked up via <source>:<contract> identifiers
called "fully qualified names." As a modicum of backward-compatibility,
failure on a lookup is now backed up by seeing if the ":" exists at all,
and if it doesn't, then the known contracts are scanned for any matching
contract name.
The library name clash checker throws errors when two libraries of the
same name are spotted. In a previous commit, this function was
rewritten to use fully-qualified names instead, which makes it redundant
to the checker for multiply-declared identifiers. Since it no longer
serves a clear purpose, the function is being dropped.
Because contracts are uniquely identified by their source unit, there
is no need for a unique error for this; it's actually covered by the
checker for double-declaration of identifiers.
Throwing a CompilerError on multiple contract definition violates the
expectations of the test suite, which thinks that compile() will
return false if the code can't compile. This brings contract
collision reporting in line with most of the other errors.
@chriseth had suggested that it would be better if contracts were
referenced in a file:contract notation, and that we output .bin files
that prepend original path names if necessary to avoid a collision.
This commit is mostly a draft; it still needs to be run through the test
suite.
The previous behaviour, courtesy of the [] operator in std::map, would
uncritically store a new ContractDefinition in m_contracts even when a
ContractDefinition already existed. This "resolved" collissions on contract
names by clobbering the original one with the new one, and could lead to
scenarios where the clobber would only be discovered when the original
ContractDefinition could not be found or referred to, which was an unhelpful
InternalCompilerError.
This change checks the m_contracts map for a collision first and will not let
the ContractDefinition be changed to a new one once it's set, throwing a
CompilerError with information about the conflict.
Unimplemented features moved to their own exception
InternalCompilerError is an exception that really should be reserved for
actual internal errors of the compiler. Unimplemented features can now
use either solUnimplemented( ) or, if it should be conditional, then
solUnimplementedAssert( ).
* Revert some unimplemented exceptions, add handlers
The jsonCompiler and CommandLineInterface needed handlers for the
new UnimplementedFeatureException, and some cases I had moved on to
the new exception were better treated as real internal compiler
errors.
* Standardize on "Unimplemented feature" message
