Link Search Menu Expand Document

solang GitHub

PR #842 Fix parse location of FunctionCallBlock
`Expression::FunctionCallBlock` location does not surround entire expression, and this fixes that by moving the location start to the beggining of the expression. This also adds `pretty_assertions` for easier debugging of dot files in tests
Created At 2022-05-20 09:53:45 +0000 UTC
PR #841 Parse assembly statement flags
Just update the parser and produce errors, no actual support yet. See https://github.com/hyperledger-labs/solang/issues/828 and #787 Signed-off-by: Sean Young <sean@mess.org>
Created At 2022-05-20 09:35:22 +0000 UTC
PR #840 Parse override(list) syntax on variable definition
- The parser does not parse an override list specified on a variable definition - The override list may be specified via an import path. Found in #787
Created At 2022-05-20 09:06:17 +0000 UTC
PR #839 Fix parser locations of expressions
The parser locations for unary and binary expression are inconsistent. Often only the operator itself is included, and not operand(s). This is causes incorrect diagnostics. ``` /home/sean/git/solang/tests/contract_testcases/substrate/arrays/array_dimensions.sol:3:21-22: error: zero size array not permitted Line 3: bool[10 - 10] x; --------^ ``` This is now fixed: ``` error: zero size array not permitted ┌─ /home/sean/git/solang/tests/contract_testcases/substrate/arrays/array_dimensions.sol:3:18 │ 3 │ bool[10 - 10] x; │ ^^^^^^^ ``` This issue was found by the Foundry work to create a formatter based on the solang-parser, see https://discord.com/channels/900503503162724452/975868842125455390/976527889166135357 --- This also means we have to deal with overlapping expressions in the language server Now the locations for binary expressions overlaps with their operands. This means that we have overlapping locations for hovers in the language server. We deal with this by finding all matching hovers, and returning the hover which is the shortest. Unfortunately this involves a linear scan of the hovers. This is linear scan of memory, so it should be fast. However, there may be a better data structure we can choose for this, should performance be an issue. I was thinking we could use something like an r* tree but this is a bit heavy for our use-case. Any suggestions?
Created At 2022-05-19 08:54:12 +0000 UTC
PR #838 Load stdlib only once
This PR fixes #807. We are now only loading the stdlib module only once and linking it against any other modules we create. Although LLVM types are global, I believe LLVM adds a `.0` to the end of the type name for disambiguation, because it does not check if two types of equal names represent the same structure in the memory. In this sense, whenever we load stdlib again, LLVM understands that is a totally new module and tries to disambiguate type names. Please, @seanyoung check if I did not remove any necessary pointer cast.
Created At 2022-05-18 14:31:44 +0000 UTC
PR #837 Refactor emit
In order to solve #807, I need to implement changes in Binary. This PR removes Binary from `emit/mod.rs`, so that I can work on it without modifying the `TargetRuntime`. The issue of LLVM renaming our types happens because we load the stdlib multiple times. Instead, we must load it once, build an LLVM module and link this same module to all other ones we create. Once this PR is merged, I'll submit my changes. In addition, I split the contract test into three functions, so that they run in parallel and make our testing faster.
Created At 2022-05-17 12:41:32 +0000 UTC