Bug in some contracts 0.4.x

[minhhn2910]

    ast = SolidityAst(flatten_source, solc_version, retry_num=retry_num, solc_options=solc_options)
  File "python3.9/site-packages/solc_json_parser/parser.py", line 256, in __init__
    self.build()
  File "python3.9/site-packages/solc_json_parser/parser.py", line 259, in build
    self.compile()
  File "python3.9/site-packages/solc_json_parser/parser.py", line 583, in compile
    raise SolidityAstError(f"Compile failed with solc version {self.exact_version}, err msg: {e}")
solc_json_parser.parser.SolidityAstError: Compile failed with solc version 0.4.26, err msg: An error occurred during execution
> command: `.solcx/solc-v0.4.26 --combined-json abi,bin,bin-runtime,srcmap,srcmap-runtime,asm,opcodes,ast -`
> return code: `1`
> stdout:

> stderr:
Error: No description given for param newOwner

Contract : smartian/B3/sol/0x10086399dd8c1e3de736724af52587a2044c9fa2.sol

[minhhn2910]

it's a weird py-solc-x err when we pass the source : the issue may be from py-solc-x using Popen to pass source code from stdin to solc. Somehow the trailing spaces at the end of line 324 of the 0x10086...sol contract were removed:

line 324:    * @param newOwner  [trailing space prevent error message  Error: No description given for param newOwner]

Reproduce py-solc-x err :

with open('.../0x10086399dd8c1e3de736724af52587a2044c9fa2.sol','r') as f:
    mysource = f.read()
solcx.compile_source(mysource,  solc_version="0.4.25")

The compilation on solc is normal

~/.solcx/solc-v0.4.25 - .../0x10086399dd8c1e3de736724af52587a2044c9fa2.sol

1 workaround is to pass file path instead of source code.

[minhhn2910]

If I use --no-flatten to pass file instead of src then there is a new kind of error in some contracts :

B3/sol/0xa62142888aba8370742be823c1782d17a0389da1.sol --no-flatten

  File "solc-json-parser/solc_json_parser/parser.py", line 262, in build
    self.contracts_dict: Dict = self._parse()
  File "solc-json-parser/solc_json_parser/parser.py", line 521, in _parse
    contract = self._process_contract(node)
  File "solc_json_parser/parser.py", line 453, in _process_contract
    contract_meta_data = self._get_contract_meta_data(node)
  File "solc-json-parser/solc_json_parser/parser.py", line 427, in _get_contract_meta_data
    line_number_range, _ = self.get_line_number_range_and_source(line_number_range_raw)
  File "solc-json-parser/solc_json_parser/parser.py", line 878, in get_line_number_range_and_source
    end_line = start_line + source_code_bytes[start_index:start_index + offset].decode().count('\n')
UnicodeDecodeError: 'utf-8' codec can't decode bytes in position 66-67: unexpected end of data

[cassc]

the problem with trailing whitespace is caused by how solc handles stdin, it might not be easy to handle it without modifying the source code:

~/.solcx/solc-v0.4.25 --combined-json abi,asm,ast,bin,bin-runtime,clone-bin,compact-format,devdoc,hashes,interface,metadata,opcodes,srcmap,srcmap-runtime,userdoc -                                                                                         pragma solidity 0.4.25;

contract Simple{

    /**
    * @param trailing_whitespace_after_this      
    */
    function transferOwnership(address trailing_whitespace_after_this) public {
    }
}

Ctrl-D
Error: No description given for param trailing_whitespace_after_this

[minhhn2910]

We dont have to change solc for this and It's not urgent to fix right now cuz I added some try catch and retry. We can place it in plan for the future: try to use standard json after flattening source.

But the second issue (utf-8 problem) still persist if source is read from file, I think this one needs to be fixed.

[cassc]

The windows style line ending make the first contract (0x10086399dd8c1e3de736724af52587a2044c9fa2) compilable, it also causes the incorrect source mapping reported by solc in the second case (0xa62142888aba8370742be823c1782d17a0389da1). It can be tested with the help of dos2unix to remove the windows line endings (trailign whitespaces not affected).

[cassc]

can we close this issue, as they are pretty rare cases and not easily fixed on the compiler and parser side? @minhhn2910