From 0aae30cdb67a85ca750d7d6ad1d260b5790809ee Mon Sep 17 00:00:00 2001 From: duaraghav8 Date: Sun, 27 Jan 2019 11:04:50 +0530 Subject: [PATCH] Add https://github.com/duaraghav8/solium-plugin-security/issues/33 to known issues --- docs/known-issues.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/known-issues.rst b/docs/known-issues.rst index b1c31b1..aa6a066 100644 --- a/docs/known-issues.rst +++ b/docs/known-issues.rst @@ -8,6 +8,18 @@ While Solium is being actively maintained, a few major issues are still lurking - The linter's internal parser supports Solidity ``v0.5``. This means that it supports the `calldata `_ storage location specifier, but in a non-backward-compatible manner. If you're currently using Solidity version < 0.5 and have used ``calldata`` as a name for a variable or function parameter, you might see false lint issues because ``calldata`` is treated as location and hence, the variable name is seen as ``null``. Regardless of whether you use Solium or not, it is a good idea to rename all such variables to keep your code compatible with Solidity 0.5. +- When installing the Linter from the ``ethlint`` NPM package, you might see the following warning: + +.. code-block:: bash + + npm WARN solium-plugin-security@0.1.1 requires a peer of solium@^1.0.0 but none is installed. You must install peer dependencies yourself. + +You can safely ignore this warning. + +Solium was recently `renamed `_ to Ethlint and the linter is available for download from both ``solium`` and ``ethlint`` NPM packages. Ethlint comes shipped with its Security plugin. This plugin checks to ensure whether ``solium`` NPM package is installed or not. + +There is currently no way in NPM to *allow any one of the specified packages to satisfy as peer dependency*, so we can't specify ``solium OR ethlint``. We also cannot change ``solium`` to ``ethlint`` in ``peerDependencies`` because its a potential breaking change. See the `original issue `_. + - There is a limitation when using the ``solium-enable`` comment directive: You cannot disable all rules (using ``// solium-disable`` for example) and then enable a select few (using ``// solium-enable rule1, rule2`` for example). The enabling part doesn't work and rules remain disabled even after using the ``enable`` directive. This is due to how the linter internally represents disabling **all** rules. In the below example, the ``security/no-throw`` rule will **not** be enabled on the ``throw;`` statement, against the expectations.