Review suggestions.

4 files changed, 5 insertions, 5 deletions

diff --git a/docs/control-structures.rst b/docs/control-structures.rst
index 9b5d21bb..d69d5404 100644
--- a/docs/control-structures.rst
+++ b/docs/control-structures.rst
@@ -376,7 +376,7 @@ series of function calls that will reach a failing assertion. If this is possibl
 in your contract you should fix.
 
 There are two other ways to trigger execptions: The ``revert`` function can be used to flag an error and
-revert the current call. In the future, it migt be possible, to also include details about the error
+revert the current call. In the future, it might be possible, to also include details about the error
 in a call to ``revert``. The ``throw`` keyword can also be used as an alternative to ``revert()``.
 
 When exceptions happen in a sub-call, they "bubble up" automatically. Exceptions to this rule are ``send``
@@ -430,4 +430,4 @@ Internally, Solidity performs a revert operation (instruction ``0xfd``) for a ``
 the EVM to revert all changes made to the state. The reason for reverting is that there is no safe way to continue execution, because an expected effect
 did not occur. Because we want to retain the atomicity of transactions, the safest thing to do is to revert all changes and make the whole transaction
 (or at least call) without effect. Note that ``assert``-style exceptions consume all gas available to the call, while
-``revert``-style exceptions will not consume any gas starting from the metropolis release.
\ No newline at end of file
+``revert``-style exceptions will not consume any gas starting from the Metropolis release.
\ No newline at end of file
diff --git a/docs/units-and-global-variables.rst b/docs/units-and-global-variables.rst
index 6d6b21c3..7d21f065 100644
--- a/docs/units-and-global-variables.rst
+++ b/docs/units-and-global-variables.rst
@@ -130,8 +130,8 @@ This means that, for example, ``keccak256(0) == keccak256(uint8(0))`` and
 
 It might be that you run into Out-of-Gas for ``sha256``, ``ripemd160`` or ``ecrecover`` on a *private blockchain*. The reason for this is that those are implemented as so-called precompiled contracts and these contracts only really exist after they received the first message (although their contract code is hardcoded). Messages to non-existing contracts are more expensive and thus the execution runs into an Out-of-Gas error. A workaround for this problem is to first send e.g. 1 Wei to each of the contracts before you use them in your actual contracts. This is not an issue on the official or test net.
 
-.. _address_related:
 .. index:: balance, send, transfer, call, callcode, delegatecall
+.. _address_related:
 
 Address Related
 ---------------
diff --git a/libsolidity/codegen/ExpressionCompiler.cpp b/libsolidity/codegen/ExpressionCompiler.cpp
index 2fc3bf6b..a7cfe4dc 100644
--- a/libsolidity/codegen/ExpressionCompiler.cpp
+++ b/libsolidity/codegen/ExpressionCompiler.cpp
@@ -886,7 +886,7 @@ bool ExpressionCompiler::visit(FunctionCall const& _functionCall)
 			auto success = m_context.appendConditionalJump();
 			if (function.kind() == FunctionType::Kind::Assert)
 				// condition was not met, flag an error
-				m_context << Instruction::INVALID;
+				m_context.appendInvalid();
 			else
 				m_context.appendRevert();
 			// the success branch
diff --git a/test/libsolidity/JSONCompiler.cpp b/test/libsolidity/JSONCompiler.cpp
index 1e44e1a7..aa690f0b 100644
--- a/test/libsolidity/JSONCompiler.cpp
+++ b/test/libsolidity/JSONCompiler.cpp
@@ -73,7 +73,7 @@ BOOST_AUTO_TEST_CASE(basic_compilation)
 	Json::Value contract = result["contracts"]["fileA:A"];
 	BOOST_CHECK(contract.isObject());
 	BOOST_CHECK(contract["interface"].isString());
-	BOOST_CHECK(contract["interface"].asString() == "[]");
+	BOOST_CHECK_EQUAL(contract["interface"].asString(), "[]");
 	BOOST_CHECK(contract["bytecode"].isString());
 	BOOST_CHECK_EQUAL(
 		dev::test::bytecodeSansMetadata(contract["bytecode"].asString()),