Co-authored-by: Hari <webmail.hari@gmail.com>
test: add parser and abi test cases
docs: add example on using named parameters for mappings
- Add changelog
feat: update antlr grammar to allow named parameters in mappings
fix: prevent conflicting mapping parameter names
ref: change order of mapping initializers
test: update expectations and fix build
test: add more tests
fix: use common error & code for conflicting params
fix: issue with accessing nested mapping
test: add conflicting params tests for more nested levels
Update libsolidity/analysis/DeclarationTypeChecker.cpp
Co-authored-by: Nikola Matić <nikola.matic@ethereum.org>
fix: error reported with the same code twice
test: add more tests for 3 level nested mapping
Address review comments
Clarify comment using language similar to that in the Array section of the documentation. Previously it said simply "Because of that..." but what the word "that" was about, was not evident.
docs: add notice for uint conversion before 0.8.0
docs: edit sentence structure + remove 'result in `address payable`'
docs: add keyword 'explicitly' to be more specific for `address payable`
docs: edit notice uint to address conversion change since 0.8.0
Co-authored-by: Kamil Śliwak <cameel2@gmail.com>
Currently the documentation suggests that a decimal literal can omit the
fractional part [1]:
> Decimal fractional literals are formed by a `.` with at least one
> number on one side. Examples include `1.`, `.1` and `1.3`.
However, commit ac68710 (May 30, 2018) disallowed trailing dots that are
not followed by a number [2].
Using decimal literals of the form `1.` will actually result in a
`ParserError` and so the docs should no longer recommend this form.
[1] https://docs.soliditylang.org/en/v0.8.15/types.html#rational-and-integer-literals
[2] ac68710789
It's already documented for push and this would clarify my incorrect assumption (that pop returns a value as in other languages) that caused confusion with https://github.com/ethereum/solidity/issues/13017
The docs state that a plain `address` cannot be sent Ether. But even though `send` and `transfer` members are not available for plain `address`, the `call` is. And `call` can be invoked upon a plain `address` type to send Ether to the address.
For instance, the `someone` (`address` type) can be sent Ether by invoking `sendSomeone()` method in the following `Dummy` contract:
```
contract Dummy {
address someone = 0xAb8...cb2;
function balanceOf(address addr) public view returns (uint) {
return addr.balance;
}
function sendToSomeone() public payable returns (bool) {
(bool sent, ) = someone.call{value: msg.value}("");
return sent;
}
}
```
Added the specificity that bytes1[] and bytes differ because of padding only in memory data location. Added extra sentence that they are similar when used in storage data location.
