###### tags: ``Team Admin``,``Ecosystem`` :::danger Agenda moved to: https://notes.argot.org/@solidity-design-call-agenda ::: # Solidity Language Design Calls: Rolling Agenda :::success ## [Next design call](#Next-design-calls) 🗓️ When: Wednesdays, [3 PM CET/CEST](https://www.timeanddate.com/worldclock/converter.html?iso=20230215T140000&p1=tz_cet) 🖥️ Call location: https://meet.soliditylang.org/ ::: :::info **How to add a topic:** If you have a topic that want to discuss, simply add it bellow in our "[Backlog of topics to discuss](#Backlog-of-topics-to-discuss)" with: - a link to an issue - or forum post - and your initials in ``[ ]``. ::: :::warning ⚠️ Please **do not delete previous agendas**, instead **add new items to the Next Design call agenda**, or **copy an existing one** if you want to re-discuss it. ::: If you're interested, you can also read our last years agenda[^1]. [^1]: [2022 Design Calls Agenda](https://notes.ethereum.org/Il4T7XGtRNOTKGfS3aUeLA) ## Next design calls: ### Backlog of topics to discuss - [SOL] [ℹ️ ADD YOUR TOPICS HERE](https:/x/github.com/ethereum/solidity/issues)👇 - Possible improvements of Yul-EVM code transform. - Look at issues in the milestones and clean them up - Changing the Yul AST during optimization to use numeric names (a pair of name ID and a monotonic index for newly generated names) - potentially with (for now unused) support for phi-nodes as well. - Review [Sourcify's metadata improvement suggestions](https://github.com/ethereum/sourcify/issues/1523) - Fixed point stuff revisited - Verkle Trees - **Preparation for 0.9.0: decide which breaking changes we’ll do, add deprecation warnings where needed, revive breaking branch, start working on breaking features.** - Go through [breaking issues not in 0.9.0 milestone](https://github.com/ethereum/solidity/issues?q=is%3Aissue+state%3Aopen+label%3A"breaking+change+%3Awarning%3A"+-milestone%3A0.9.0+). ## Agenda for 2025-04-30 - Storage overflow bugfix: https://notes.argot.org/@solidity-clearing-arrays-and-wrapping-behavior# - EthDebug next steps (next step maybe rather than variables is initial deduplication support) - State of the SSA code transform - Refactor of Constant Evaluator ## Agenda for 2025-04-23 - ``pure`` - [Clarify pure. #12256](https://github.com/ethereum/solidity/pull/12256) - @cameel: Should we reopen [Strengthen the definition of ``pure`` potentially disallowing e.g. ``codecopy`` - or "the future of ``pure``". #8153](https://github.com/ethereum/solidity/issues/8153)? - Discussion: - We should distinguish internal and external `pure`. - This is not something we have to decide right now - schedule for 0.9.0. - We could easily do the part that relaxes restrictions on external `pure`, but probably better to do it all together. - The closed issue goes in the opposite direction, so we do not necessarily want to reopen, but we should put this somewhere. - [Immutable variables treated differently depending on type #15989](https://github.com/ethereum/solidity/issues/15989) - Alternative idea: don't try to force immutables to be pure, remove the feature and just recommend the use of a `constant` instead. - Discussion: - Also something for 0.9.0. - More detailed discussion on how we'll handle `EXT*CALL` return codes in EOF: 1. Low-level calls currently return `bool` and handle both EOF and legacy transparently. - Option A: Keep `bool` on legacy and make it `uint` on EOF. - Option B: Pretend the value is the same on both. - For now can keep returning `bool`. - In 0.9.0 change the returned type to `uint` (with `0` on success for legacy). - Option C: keep ``.call`` as is, deprecate it for EOF (potentially still keeping it in 0.9), and add ``.extcall`` returning the EOF status code. - Discussion - Writing code portable between EOF and non-EOF. - This is an issue with option C but also A. B is portable. - B and C are actually very similar. Difference only in the long term: one keeps `.call()` indefinitely, the other deprecates it and replaces with `.extcall()` eventually. 2. How to expose the return code in `try`/`catch`? ```solidity try foo() returns (uint v) { return (true, v); } catch Error(string memory), uint returnCode { return (false, returnCode); } ``` - There will never be a revert string with any status code other than 1 anyways, will there? It may be more reasonable to add a new kind of catch clause type for status code 2 (resp. status code >1). - @cameel: Should we introduce `Error(uint)` for this? It would then naturally go into a separate `catch` clause. - That'd be good, we could also raise it on malformed return- (resp. revert-) data (with a separate code), and also independently upon request for ABI decoding failures, etc.; just need to define error codes and in particular a mapping from EOF call status codes to them. - Discussion: - `Error(uint)` is a good solution, but we need to choose an error code scheme. - One code must be reserved to represent `2` returned from `EXT*CALL`. - No need for `0` and `1`, because these won't enter the same `catch` clause. - We can use remaining codes for situations where we currently revert with `Error(string)`. - How to introduce it? Is it breaking? - We could add a new choice to `revertStrings` that would enable this. - It does not fit the name well though. - We need to compile a list of these errors and figure out how to assign codes to them (especially with what granularity). - A two-level scheme with broad groups would likely be useful. Something like [the system we use for `Panic` codes currently](https://docs.soliditylang.org/en/develop/control-structures.html#panic-via-assert-and-error-via-require). - Handling the EOF part of this has the higher priority, handling of other errors this way can be added later, but we need to choose a scheme already in the first part to keep it extensible. - On the [last EOF call](https://github.com/ethereum/pm/issues/1429) @frangio requested again that salted creation on EOF should use address calculation that is as close to legacy as possible by default. - Any outside insights on this would be good. - We can't achieve full compatibility, i.e. the address calculation will remain different no matter what, so people need to adjust in general. - We can encode creation arguments more efficiently than users; still somewhat costly. - There should be a "compatibility" mode - the question is what should be default. - Precise hashing scheme? - Discussion: - Open question: how important is it to include the constructor arguments in address calculation. - The arguments are actually the only reason this might be worth doing on our side. If we expose initcode hash, the user can easily mix it into the salt on their own. This is not the case with the arguments. Encoding and hashing them separately is a big extra cost, while the compiler has to internally encode them for the call anyway. - The fact that arguments were included in `CREATE2` is just incidental - on legacy they are appended to initcode and indistinguishable from it on chain. - What matters to @frangio is retaining the same level of collision resistance, not necessarily preserving the same formula. - We should provide both options (raw salt and simulation of legacy scheme). - It would be technically feasible to also provide a third one, where we expect the user-provided salt to have everything but argument hash mixed in and the compiler does that last part. - Which address calculation should be the default, i.e. used with `{salt: ...}`? - Even if we use the one that includes initcode and argument hashes, we don't achieve full backwards compatibility, because the formula will be different. We still break code that does counterfactual address calculation (it will compile but no longer produce the right address). - Syntax? - `new C{salt: ...}()` + `new C{rawsalt: ...}()` - `new C{legacysalt: ...}()` + `new C{eofsalt: ...}()` - `new C{scheme: "legacy", salt: ...}()` + `new C{scheme: "EOF", salt: ...}()` - `new C(legacy){salt: ...}()` + `new C{salt: ...}()` (like "placement `new`" in C++) - No concrete decisions yet. We need decisions about: hashing scheme, defaults, syntax. More input from @frangio needed. ## Agenda for 2025-04-16 - Quick confirmation: are we fine with `EXT*CALL` return codes as defined in EOF's [EIP-7069](https://eips.ethereum.org/EIPS/eip-7069)? > Lastly, instead of returning a boolean for execution status, an extensible list of status codes is returned: `0` for success, `1` for revert, `2` for failure. - Yes, but we should actually handle it in codegen - e.g. raise a panic code on 2? Or actually more like an ``Error(string)`` similar to the extcodesize check. That's the main point of the status code generally. - Decision: It does not really fit requirements for a `Panic`, so has to be an `Error`. - Revisit the `eofcreate()` design discussion. - Use case: [Solady](https://github.com/Vectorized/solady). - Current [uses of `CREATE` in the repo](https://github.com/search?q=repo%3AVectorized%2Fsolady%20path%3A**%2F*.sol%20create&type=code). - So more like custom containers (e.g. in hex or such; as somewhat expected)? - A lot will likely depend on refactoring generated code to fixed code with generated data. - Going back to previous questions - Would it be useful to make it available also at Solidity level just like `type(C).name` already is? - Decision: no use case, better not to add things like this if they are not necessary. - It needs to be usable with literal arguments though. Should we make it available only in that context or more generally? - Decision; There is a good way to limit it only to `eofcreate()` without hard-coding it: instead of making it a string, introduce a new type of literal argument that represents a reference to a container. - Discussion - The use case for Solady seems to be deploying custom, hand-crafted bits of bytecode. Not even Yul. - 3 cases that we should eventually allow in `eofcreate()`: 1. Deploying an existing container. 2. Deploying a custom container specified as hard-coded piece of bytecode. - Not as dangerous as verbatim because it has to be a complete container and we won't be optimizing that it any way. - Could be implemented by making `eofcreate()` accept the bytecode as a literal string or by having the compiler create a Yul object. 3. Deploying a custom container produced by compiling a global assembly block into an object. - (1) we already have in Radek's PR, (2) is easy to implement in the variant with literal bytecode string and can be changed later. - [Ongoing discussion about `layout at` affecting transient storage as well](https://github.com/ethereum/solidity/issues/597#issuecomment-2762967113). - Discussion: - We're leaning towards introducing syntax for controlling transient storage layout independently. - `layout (storage, transient) at ...`? ## Agenda for 2025-04-09 - Request to [have `layout at` affect transient storage as well](https://github.com/ethereum/solidity/issues/597#issuecomment-2762967113). - Apparently in the [EIP-4337](https://eips.ethereum.org/EIPS/eip-4337) upgrade flow it is actually possible for both the new and the old code to run within the same transaction. - Conclusions: - The change is breaking, we can only change it easily in 0.9.0. - The main thing that we'd break is accessing transient variables via inline assembly. - Sharing same transient slot between contracts is only really an issue when not using it properly (i.e. not clearing after use). - We don't yet have a strong opinion on whether transient storage layout should match storage layout or not. - Maybe comment on [Mask generator optimizations #15935](https://github.com/ethereum/solidity/pull/15935) to update the contributor? - [Immutable variables treated differently depending on type #15989](https://github.com/ethereum/solidity/issues/15989) - Conclusions: - Most important thing: make sure that current compiler behavior around immutables that end up being marked `pure` is correct: - That after reassignment it's the new value that's visible. - No differences between internal and external function calls. - If they are allowed in array sizes, make sure nothing weird happens. - Other than that, this is a normal priority bug, not something critical. - The long term solution here is to make behavior consistent and amend the check for reinitialization. - It's unclear why some types (e.g. address) were excluded. Check why. It should only matter how the variable is initialized and whether it can change, not what type it is. - Ones that get reassigned should be detected and not marked as `pure`. - The root of the whole problem is the ambiguity about what `pure` should mean. - The reason immutables are not pure is that they can be initialized with values that depend on blockchain state. E.g. `block.number`. - This is broken now that the ones marked pure can be reassigned. It's undesirable but not critical - there are many other "holes" that allow subverting immutable checks. - Link to the older discussions around the meaning of `pure`, e.g. [Clarify pure. #12256](https://github.com/ethereum/solidity/pull/12256). - We'll discuss that next week, but one thing that is clear we should change is the internal `isPure` annotation that has a slightly different meaning, which is confusing when working on the compiler. ## Agenda for 2025-04-02 - Should finalize/merge https://github.com/ethereum/solidity/pull/15935 sooner than later. - Reviewing survey results. - Radek reports that users need `eofcreate()` to be available in inline assembly and wants to work on that next. - To do it we need syntax for referring to a contract's Yul object in inline assembly. - Proposal: do it the same way we handle slot and offset for storage variables. I.e. for a contract `C` expose a special name like `C.object` or `C.initcontainer` that represents the name of the object. When it's used, also create a bytecode dependency on `C`. ```solidity contract C {} contract D { function f() public { assembly { eofcreate(C.object, 1, 2, 3, 4) } } } ``` - It needs to be usable with literal arguments though. Should we make it available only in that context or more generally? - We should really be calling them "compile-time arguments" or something. `C.object` is not even a literal. - => No - Should we make it EOF-only? - => Yes, at least at first, probably generally. - Would it be useful to make it available also at Solidity level just like `type(C).name` already is? - unclear what that would mean - Do we only need it for deploying Solidity contracts or also Yul objects or even byte-wise custom EOF containers? - can we test the ppa builds for plucky? @clonker thinks the hanging issue should be resolved - Running at https://launchpad.net/~ethereum/+archive/ubuntu/ethereum-dev/+packages (https://launchpad.net/~ethereum/+archive/ubuntu/ethereum-dev/+build/30606525) ## Agenda for 2025-03-26 - numerical IDs PR, sadly slightly large but a lot of it is updated test expectations https://github.com/ethereum/solidity/pull/15969 - viaIR 19-25% faster in benchmarks ## Agenda for 2025-03-19 - We need to select a primary email address to be designated as the main contact for OSS-Fuzz: https://github.com/google/oss-fuzz/blob/master/projects/solidity/project.yaml#L3 and we should consider adding CCs so that more team members can access the fuzzer results. See: - https://google.github.io/oss-fuzz/getting-started/new-project-guide/#reviewing-results - https://google.github.io/oss-fuzz/getting-started/new-project-guide/#primary - The primary or a CC, will need to be a Google account to get full access. From the call we are thinking about adding [email protected] as primary contact. ## Agenda for 2025-03-12 - Check on ongoing release. - If the release is going well, initial post-release planning. - Krzysiek Fonał will come to talk about his research on using machine learning to improve the Yul optimizer sequence. - Re-evaluation of [Inconsistent Treatment of Storage Arrays on the Slot Overflow Boundary #15587](https://github.com/ethereum/solidity/issues/15587). - Should we reword warnings for oversized storage variables or overstepping the boundaries? - Do we officially support storage as a circular space that wraps around or do we consider it an invalid and dangerous use case? - Is the fact that partial array assignment works intentional? Should it be documented or disallowed? ## Agenda for 2025-02-26 - Readiness check for 0.8.29. ## Agenda for 2025-02-19 - Readiness check for 0.8.29. - [evmmax: Implement EVMMAX Solidity support. PoC #2](https://github.com/ipsilon/solidity/pull/2) - We should at least reverse a name for the `code` data location in 0.9.0. Which one (if we don't stay with `immutable` after all)? - Someone to look into adding gas statistics to the "testrunner" for Project GreY @clonker ## Agenda for 2025-02-12 - Solidity Survey - Code data location - [Add parser support for `code` data location. #13368](https://github.com/ethereum/solidity/issues/13368) - [Type-Checking for `code` data location. #13369](https://github.com/ethereum/solidity/issues/13369) ## Agenda for 2025-02-05 - Need to move ahead with merging the storage layout soon to make it for the hardfork. (It would be very good to not cut it too close on this one, i.e. to have it merged ahead of the actual fork) - Who's taking over the Osaka bump PRs until Rodrigo is fine again? (Probably mainly need review and merge) - EOF design questions. - [Impact of EOF on Solidity, Yul and EVM assembly syntax](https://notes.ethereum.org/@solidity/eof-impact-on-solidity-syntax) - libevmasm optimizer after assembly-json import: - I'd say: should be allowed. - Madrid people would benefit from it. - Who's up for it? Should be relatively simple. - What/how much to do about import resolution? (eg https://github.com/ethereum/solidity/issues/13985) - Not urgent, deal with it post Osaka. ## Agenda for 2025-01-29 - **Preparation for 0.9.0: decide which breaking changes we’ll do, add deprecation warnings where needed, revive breaking branch, start working on breaking features.** - First pass through issues currently in Milestone. - Issues we should start issuing deprecation warnings for: - [Remove support for the catch all (*) in the using statement #11882](https://github.com/ethereum/solidity/issues/11882) - [Reconsider operators on ContractType #11700](https://github.com/ethereum/solidity/issues/11700) - [Remove abi.encodePacked #11593](https://github.com/ethereum/solidity/issues/11593) - [Remove .send and .transfer. #7455](https://github.com/ethereum/solidity/issues/7455) - [Remove ABIEncoderV1 #11323](https://github.com/ethereum/solidity/issues/11323) - [Disallow internal function pointers in storage #15794](https://github.com/ethereum/solidity/issues/15794) ## Agenda for 2025-01-22 - EF Next Billion is inviting Solidity to take part in their ecosystem-wide internship program. > -> How it works: Projects select, onboard interns and mentor them. These interns work on projects specified by mentor orgs for a period of 3 months, EF supports with coordination and stipends for interns. - Storage base location: on a second look: should we actually introduce an AST node right away after all? Quite relevant especially for AST import/export. - Post initial-EOF-PR priorities: https://github.com/ethereum/solidity/issues/15310#issuecomment-2607206475 ## Agenda for 2025-01-15 - EOF conditional compilation, create business etc. - Maybe we should get in touch with library authors about this (i.e. conditional compilation)? - forum post - a link in solc-tooling - Can we deprecate BMC engine of SMTChecker? - It's up to Martin. But ask for feedback on the forum first. - Anything to take serious about: [The optimizer incorrectly removes assembly block that initializes function pointer #15716](https://github.com/ethereum/solidity/issues/15716) - Document this aspect of internal functions: - Note that non-refernced functions are not guaranteed to be preserved - Warning that internal pointers in storage may get invalidated on code update - Ask for feedback on deprecating storing internal function pointers in storage (on the forum). - Announcing deprecations - Create a forum category for asking for feedback on backwards-incompatible changes - As a rule, cross-post the threads to #solc-tooling on Matrix - More important ones can be cross-posted to Twitter as well. Not all of them - the fact that this stable place for such announcements exists and that they are adertised will bring people to the others as well. ## Agenda for 2025-01-08 - Initial look at Roadmap draft https://github.com/orgs/ethereum/projects/26/views/1 ## Agenda for 2024-12-18 ## Agenda for 2024-12-11 - SSA CFGs ## Agenda for 2024-11-27 - Ipsilon asking for feedback on the [proposal to change address calculation for `EOFCREATE`](https://github.com/ipsilon/eof/issues/162#issuecomment-2503198108). - The proposal is to drop the hash of the initcontainer altogether and simply use `keccak256(sender_address + salt)`. The argument being that it's more in line with banning code introspection and that: > the user is mainly interested that *other* users cannot trivially produce a collision with some salt they want to deploy to, but the EVM can let them be responsible for making sure they don't produce a collision with themselves which this new design does satisfy. - The main alternative is [a more complex scheme that involves subcontainer indexes and physical address of the deploying code](https://github.com/ipsilon/eof/issues/162#issuecomment-2463795391) (robust against `DELEGATECALL`). > - Non-nested EOFCREATE: `keccak256(sender_address + code_address + salt + sub-container-index)` > - Nested EOFCREATE inside initcode: `keccak256(sender_address + salt + sub-container-index)` ### Notes ``` contract D { constructor(uint x) {} function f() public { ... } } contract E { function g() public { ... } } contract C { D a1; D a2; E b; function f(uint256 x, uint256 y) public { a1 = new D{salt: x}(y); a2 = new D{salt: x}(y + 1); b = new E{salt: x}(); } } ``` ## Agenda for 2024-11-20 - Can we deprecate the `verbatim_` builtins in Yul and replace them with `verbatim()` with literal arguments? - Decision: We can change it (without going through a deprecation phase) in 0.9.0 because `verbatim` is not widely used. ## Agenda for 2024-10-30 - Devcon Talk State - Some initial task for Erik while we're in Phuket/Devcon? ## Agenda for 2024-10-23 - [Yul object names with dots are accepted but ambiguous #15540](https://github.com/ethereum/solidity/issues/15540) - decision: disallow dots, non-breaking - [Insufficient check for uninitialized storage pointer access #14021](https://github.com/ethereum/solidity/issues/14021) was at the core of one of the submissions in the underhanded contest, which means it should prioritized a bit more. - [Fix verbatim control flow size effects. #15542](https://github.com/ethereum/solidity/pull/15542) - We give `verbatim` worst `SideEffects`, but not `ControlFlowSideEffects`. - Does it actually result in optimizer doing something wrong or is it just a theoretical problem? - Probably yes: try a storage write that will be optimized out due to revert/termination. - Decision: not an important error, documentation actually says that verbatim block should not change control flow. - Add a warning about previous version in the docs. - Multi-level break in Yul ``` do { if (<someCond>) continue; } while(<cond>); ``` ``` let isFirstRun := 1 for myloop {} true {} { if iszero(isFirstRun) { if iszero(<cond>) { break } } .... isFirstRun := 0 } for mylabel {} true {} { for {} true {} { break<mylabel> break[mylabel] break(mylabel) break:mylabel break->mylabel } mylabel: { break } for mylabel {} true {} { break(2) break } } ...break 2 target... ``` ## Agenda for 2024-10-16 - Issue linked in Matterlabs doc: https://github.com/ethereum/solidity/issues/15142 - Quick follow-up on: `do ... while` loops are inherently less gas efficient in code compiled via IR due to lack of jumps or native `do ... while` in Yul. [Should we have them in Yul?](https://github.com/ethereum/solidity/issues/15442#issuecomment-2378257690) - education session about ABI encoding? ## Agenda for 2024-10-09 - education session about ABI encoding - `do ... while` loops are inherently less gas efficient in code compiled via IR due to lack of jumps or native `do ... while` in Yul. [Should we have them in Yul?](https://github.com/ethereum/solidity/issues/15442#issuecomment-2378257690) ## Agenda for 2024-10-02 - Look again at Prague https://eips.ethereum.org/EIPS/eip-7600 - Check other hardhat workarounds: https://github.com/ethereum/solidity/pull/15461 (@matheus) - https://github.com/ethereum/solidity/pull/15252 ## Agenda for 2024-09-25 ## Agenda for 2024-09-18 - Storing nightlies in solc-bin on GitHub is becoming more and more of a nuisance - workarounds are needed to even clone the repo, `bin/` file listing is so long it errors out on GitHub. - Is preserving historical nightly builds even useful to anyone? I think they're relevant only for a very short time. And more often than not we're interested in sharing a binary from an unmerged PR rather than `develop`. - Would deleting them all and only having nightlies from the last 30 days on CircleCI be good enough instead? - Could we get rid of them more permanently, e.g. by archiving the current solc-bin and starting over with a new directory structure and without nightlies? - If we do want to preserve them, could we move them to something less permanent, e.g. make them pre-releases in solc-bin? - Conclusion: - Short term: do nothing - Long term: nice IPFS setup; split between releases and nightlies (different subdomains, different easier upload mechanism for nightlies and feature branch releases, etc.) - State of Transient Storage - State of EOF - State of Storage Layout Specification https://github.com/ethereum/solidity/issues/597 - Next steps: - Prepare final spec showing what we'll implement and post in the issue. - Announce it. ## Agenda for 2024-09-11 - The external "contant evaluator" PR does not seem to provide any gas savings, even when moved after FunctionSpecializer. Ask the contributor to investigate. - It also does not make any visible difference in compilation time benchmarks. But this does not prove much - it might just not have enough input to work on. - Broken `bin/soljson-latest.js` symlink during last release. We should finally fix [#13508](https://github.com/ethereum/solidity/issues/13508). ## Agenda for 2024-09-04 - Nick's fixed point udvt assembly idea ``` fixed8x80 <=> uintABC function f(fixed8x80 x) external { fixed8x80 y = x; assembly { y := x } } "f(fixed8x80)" ``` - abi encoded errors request by Hadrian https://github.com/ethereum/solidity/pull/14974#issuecomment-2324307483 - https://github.com/ethereum/solidity/issues/15388 - SMTChecker going into maintenance mode; Paweł Gębal to potentially move to other Solidity work - are we interested in that? Notes: ``` type error is bytes memory; function CustomError(uint x) returns (error) { return error.wrap(abi.encodeWithSignature("CustomError(uint256)", x)); } error someError = CustomError(42); /// <- this is the costly part return bytes(someError); ``` ## Agenda for 2024-08-.. - Review [Sourcify's metadata improvement suggestions](https://github.com/ethereum/sourcify/issues/1523) ### Agenda for 2024-08-28 ### Agenda for 2024-08-21 - Quick Chat about Erik - Is the ossfuzz stuff settled? - Need dedicated EOF review sessions. ## Agenda for 2024-08-14 - SMTChecker SMTlib-switch progress - Review/progress strategy for [EOF PR](https://github.com/ethereum/solidity/pull/15294) - (Hopefully) final review pass on [Legacy Value-Type Transient Storage Codegen](https://github.com/ethereum/solidity/pull/15257) - "lower review intensity required"/"low hazard risk" label for PRs? maybe "moderate risk" something hidden ### Agenda for 2024-08-07 - Some discussion around removing typed yul and simplifying Yul ASTs, etc. - Some coordination about the Madrid SSA CFG work. - Some reviewing. ### Agenda for 2024-07-24 - [EOF Presentation](https://drive.google.com/file/d/1LE2YSMh7_8XvGZruSd3wLEdOBXKtz6jy/view?usp=drive_link) - EOF PR Review and Merge Planning - Post EOF PR Planning - Assembly JSON import/export for EOF functions (Madrid collaboration) - Source mappings and various other compiler artifacts. - Remove stack-to-memory; adjust code transform to exploit EIP-663 - High-level Language Changes? => At least: salted create address calculation ### Agenda for 2024-07-17 - Opinions on https://github.com/ipsilon/eof/pull/144 - we should at least comment. - Should we expose whether the target is EOF as language construct? Builtin address calculation primitive? - How to proceed with https://github.com/ethereum/solidity/issues/597 - Collision-detecting: that's bit weird - collision detection is basically the entire point of all this in the first place :-D. Or is the point collision-freeness wrt mappings and not for base locations? That we cannot do anyways. - https://blog.ethereum.org/2024/07/08/attackathon - Readthedocs **deprecation of Sphinx context injection at build time** mail: check if and how that affects us. - https://notes.ethereum.org/BNATXOfARBCF09BcZmZ6yQ ### Agenda for 2024-07-10 - How to proceed with https://github.com/ethereum/solidity/issues/597 - Check-in on Yul object hashing for optimization deduplication (are we fine with that approach for now?) - How to proceed with https://github.com/ethereum/solidity/pull/15238 ### Agenda for 2024-06-24 - Another session about [Allow specifying storage locations #597](https://github.com/ethereum/solidity/issues/597) ### Agenda for 2024-06-12 - Another session about [Allow specifying storage locations #597](https://github.com/ethereum/solidity/issues/597) - Check what's holding up transient storage PR. - Anything needed for next week? (@ekpyron on vacation) ### Agenda for 2024-06-05 - [Allow specifying storage locations #597](https://github.com/ethereum/solidity/issues/597) in the context of EIP-7702 - Disadvantage of specifier in contract body: breaking (arbitrary type names); order of contract body elements; multiple mentions, etc. - Kamil dislikes prefix specifiers - Postfix - it should probably be after the inheritance specifiers, since otherwise scoping is weird. #### Syntax brainstorming ```solidity abstract contract Example { /// @custom:storage-location erc7201:example.main struct MainStorage { uint256 x; uint256 y; } //address owner; MainStorage virtual $; //address virtual owner; function _getXTimesY() internal view returns (uint256) { return $.x * $.y; } } contract ExampleWithConcreteStorage is Example { layout{slot: keccak("...ABC...")} MainStorage override mainStorage; storage for contract Example override; address override owner; } contract ExampleWithConcreteStorage is Example, Ownable { using storage{slot: keccak("...ABC...")} for Example; using storage{slot: keccak("...ABC...")} for owner; } ``` ```solidity abstract contract Example { /// @custom:storage-location erc7201:example.main struct MainStorage { uint256 x; uint256 y; } //address owner; MainStorage $; //address virtual owner; function _getXTimesY() internal view returns (uint256) { return $.x * $.y; } } contract ExampleWithConcreteStorage is Example storage of Example at <expr>; { } ``` ### Agenda for 2024-05-29 - [Allow specifying storage locations #597](https://github.com/ethereum/solidity/issues/597) in the context of EIP-7702 - Any cases in which location should be independent for base contracts from derived contracts? - Make it a contract definition property, which could also syntactially distinguish between inheritance behaviour - Decision: https://github.com/ethereum/solidity/issues/597#issuecomment-2137917945 ### Agenda for 2024-05-15 - Final pre-release checkin - Post-release planning - require with custom error in legacy (via call into the Yul function) - Progress on Transient Storage - Yul AST refactor with numeric IDs; refactor of data structures in DataFlowAnalyzer - Progress on SSA Transform and Forward Yul->EVM codegen - Evaluate Ipsilons upcoming EOF draft - Bugfixing - Merge strategy for EthDebug PRs - C++ Coding Style: auto: https://github.com/ethereum/solidity/pull/15077 - Somewhat related: https://github.com/ethereum/solidity/issues/14403 ### Agenda for 2024-05-08 - How to proceed with [Add abi.encodeError #14974](https://github.com/ethereum/solidity/pull/14974). - SMTChecker: Upgrading `CVC4` to `cvc5` using SMT-LIB2 interface - [https://github.com/ethereum/solidity/pull/15078](https://github.com/ethereum/solidity/pull/15078) - Should we go through intermediate step (`cvc4` using SMT-LIB2 interface)? - No tests using `cvc4`? - No `cvc4` in OSX job in CI? - If there is time: small summary of current projects for Moritz - Ping tooling to try a nightly with JSON-corner-cases if they have any ### Agenda for 2024-04-17 - General Focus Areas - Yul Optimizer Performance - Research worst cases: - how much is the code transform roundtrip (to be solved by code transform work) - how much is data flow analyis - in particular: what's special about worst cases - number of variables? Control flow? - Community-Collection of bad case - - Yul Code Transform (Rodrigo & Fe & Madrid) - EthDebug - One High-Level Language Feature ### Agenda for 2024-04-10 - [Code Deduplication Creates Wrong Source Mappings #14930](https://github.com/ethereum/solidity/issues/14930) - Marko says that arbitrarily choosing one of the locations creates problems more often than it helps. - In the long term ethdebug will solve this, but can we either allow disabling it or mark such locations as guesses in the short term? Marko would be willing to work on implementing that. - Is adding a new element to the source location tuple breaking? - Decision: we're still inclined to wait for a proper solution with ethdebug (more details will be posted in the issue) - [New macOS Universal Binaries are signed #14813](https://github.com/ethereum/solidity/issues/14813) - is there anything else we can do to get rid of the ad-hoc signature or do we just leave it at that? - Wait for complaints. - How to handle the contribution: [Add binary string/literal/number to solidity and yul #15003](https://github.com/ethereum/solidity/pull/15003) - Mention that it's uncommon to jump on closed issues, better to talk to us before picking one up. - Ask to join the Matrix channel or a design call to avoid spending effort on PRs we would not accept. - Mention that adding the `bin` keyword is breaking so we can't accept that as-is but we're open to accepting a PR that's just the part that adds support for `0b` prefix. - It would also be easier to us to review it in smaller steps. Especially a PR with just the Solidity support would be a better as the first step. Then Yul support could be added in a separate PR on top of it once the first one is merged. ### Agenda for 2024-03-27 - High-Level Support for Transient Storage - Value Type Only (as state variables only)? - Parser Hack - Layout? - Legacy vs via-IR? - Compiler Output Artifacts about Layout - Limited optimizer support - Assembly Access - Later: reference types: - First version: non-convertible to other locations. ### Agenda for 2024-03-06 - Talk about the upcoming release ### Agenda for 2024-02-28 - require with custom errors (https://notes.ethereum.org/g6f0Xi6JQySEFqLX7jyqnw) - results of optimizer research (sequence + libevmasm CSE) - Cancun release: - Schedule March 13th/14th (Cancun is scheduled for March 13th) - Make cancun default EVM version. - Dial down the transient storage warning to annoy people a bit less. - Ideally we also still manage to (optionally): - Have an initial tweak of the optimizer sequence (with a minimal impact, but some performance improvement) - A nice feature to also ship - like custom errors above. - handling of semver breaking changes (https://github.com/ethereum/solidity/pull/14886) ### Agenda for 2024-02-21 - JSON Schema Grant? (https://github.com/pboettch/json-schema-validator/issues/153#issuecomment-1076384370) - Initial quick report about Optimizer Sequence and libevmasm CSE. - Survey evaluation (continued) ### Agenda for 2024-02-07 - EthDebug implementation: - Current mechanisms for transporting debugging data. - Initial plan for extending to account for EthDebug. - Stack shuffling ### Agenda for 2024-01-10 - Style Guide (handing it over to the community) - Experimental Solidity Codegen next steps ### Agenda for 2023-12-20 - Cancun support ### Agenda for 2023-12-06 - ReadTheDocs WebHook Integration Secret Requirement: Hello, Previously, manually configured webhooks from integrations did not have a secret attached to them. In order to improve security, we have deployed an update so that all new integrations will be created with a secret, and we are deprecating old integrations without a secret. You must migrate your integration by **January 31, 2024**, when they will stop working without a secret. We are contacting you because you have at least one integration that does not have a secret set. These integrations are: If you aren't using an integration, you can delete it. Otherwise, we recommend clicking on "Resync webhook" to generate a new secret, and then update the secret in your provider's settings as well. You can check [our documentation](https://docs.readthedocs.io/en/stable/guides/setup/git-repo-manual.html) for more information on how to do this. You can read more information about this in our blog post: . Keep documenting, Read the Docs Note: already settled, just need to quickly confirm that it keeps working. ### Agenda for 2023-11-08 - Discuss bug blog post. - https://github.com/ethereum/solidity/pull/14673 - AST schemata open question (if applicable) ### Agenda for 2023-11-01 - Discuss optimizer options (current adjustment and long-term plan). - Settle on verbatim bug description and release date. ### Agenda for 2023-10-18 - Discuss 0.8.22 release comms: https://notes.ethereum.org/wwMq--okTneeu07vYAERxQ ### Agenda for 2023-10-04 - Future of `legacyAssembly` - is it going to be deprecated and removed? - Currently we have two assembly formats: 1. `assembly`/`--asm` (text) 1. `legacyAssembly`/`--asm-json`/`--combined-json asm` (JSON) - `legacyAssembly` was called that ever since Standard JSON was introduced. - @chriseth says that the legacy format was not machine-readable, and he wanted to remove it eventually. Though it's not certain if it was really the same as current legacy format (the non-machine-readable one was apparently text, not JSON). - [comments from @chriseth and @axic on a related bug](https://github.com/ethereum/solidity/issues/8171#issuecomment-588184845) - We're using the legacy JSON format for the assembly import feature that's being implemented. If we accept it as input, we should also be able to output it so that it can be modified and fed back. - The naming is confusing (I never remember which one is JSON) and also tells users to stay away from it (legacy features eventually go away). If it's going to stay, perhaps it should be renamed to `assemblyJSON`. ### Agenda for 2023-09-13 - Experimental type system: - Rough next steps. - Continue splitting/moving builtins. - Split into type variables and free types - Construct SCC forest from call graph. - Use SCC forest for ordering type inference. - After the above: Take care of current quirks (types for type-expressions; member access construction; type variables in signatures & syntax for type variables) - Independently: Extension of IR Generation with IRVariables. - Later: - algebraic data types (sounds worse than it is); generalized type classes (will take some doing); literals. Then basically done with first milestone in terms of expressivity; can refine syntax (note: reference types are next milestone) - Also need: testing-only option for using in-tree stdlib files (to avoid annoyance of having to recompile the compiler for development) - Split between fixed free type variables and schematic type variables. (Including: flukes in current inference in presence of explicit type variables that can still be unified) ### Agenda for 2023-09-06 - Yul Optimizer still depending on AST IDs: https://github.com/ethereum/solidity/issues/14494 https://github.com/ethereum/solidity/issues/14535 - Another quick look at the recent (likely false-positive) vulnerability report; potentially still fix the alignment in question. ### Agenda for 2023-08-23 - Experimental type system: - AST Translations (postpone!) - Polymorphic recursion as complication (reject!) - Challenges and advantages of deferred unification - Advantages of further generalization by unification via solver - Compile-time constant evaluation (stack size as type class!) - "Early" monomorphization? ### Agenda for 2023-08-16 - verbatim in inline assembly https://github.com/ethereum/solidity/issues/12067 - Inheritance improvments and external interfaces ### Agenda for 2023-08-09 - Native WebAssembly builds and implications for solc-js - Exception support in browsers may be sufficient for native WebAssembly builds today - Implications for solc-js and tooling and backwards-compatibility (maintain soljson.js and soljson.wasm? Is rebuilding old versions feasible here (compiler versions & exception support)?) - Overview of Dominators (out of time for: and brainstorm on possible improvements of Yul-EVM Code transform.) ### Agenda for 2023-08-02 - Initial Verkle-Tree discussion (long-term awareness) ### Agenda for 2023-06-21 - Separate namespaces for terms and types and name and type resolution. - Modernization of the scanner. ## Past design calls ### Old Backlog of topics - inference of data locations together with mixed locations and tying locations to types (https://github.com/ethereum/solidity/issues/13730) - We need to gather possible corner cases for discussion. - Codebase purge: - Drop support for old EVM versions - Drop snap config - Drop old EVM code transform - Drop cvc4? - Drop typed yul (breaking?) - Drop assorted scripts - Drop our custom Homebrew formula for older compiler versions - [breaking?]: - solc --link - --combined-json - abi.encodePacked - abi.encodeWithSignature/Selector - ABIEncoderV1 - outdated assembly options https://github.com/ethereum/solidity/issues/13714 - libraries - Schedule dedicated design calls for the upcoming larger tasks that are still under-defined: - Generics - owned by Daniel - Compile-time-constant expression evaluation - owned by Daniel - Better memory optimizations - owned by Chris, still in research phase, not yet in an explanatory stage, documented in hackMD here -> https://notes.ethereum.org/WnsIlf8RSASJFr8S7m5yvQ - Code data location / value type immutables - owned by Daniel - ...? - Decide whether it is worth adding type definitions to ABI and compiler I/O standard in solc-js (https://github.com/ethereum/solc-js/pull/630). And what would be the best way to maintain that (e.g., using a JSON schema). - Should we allow omitting location for function parameters in interfaces just like we decided to do for function pointers? - Do we want tangential features like [Yul formatter #13550](https://github.com/ethereum/solidity/issues/13550) or [Exposing evmasm::disassemble a "poor man's disassembler" #12753](https://github.com/ethereum/solidity/issues/12753) in the compiler? ### Agenda for 2023-06-14 - [x] Policy on awarding bounties for codegen errors that do not qualify as proper security vulnerability. - [x] Statements as expressions in experimental solidity; match, if - [x] Syntax brainstorming: type classes, instantiations, free type variables Notes: https://notes.ethereum.org/@solidity/ByhPnEwwh general preference towards angular brackets; keeping the issue open, though ### Agenda for 2023-05-17 - [x] Decision on [User-defined literal sufixes](https://github.com/ethereum/solidity/issues?q=literal+suffixes+is%3Aopen+) - Decision: Doing nothing about it and going for the experimental route. - Legacy code gen will be too expensive. - ~~Alternative: restricting it to via-ir (initial scope).~~ - It would mean refactoring the PR. - [ ] Decision: Restricting the experimental pragma to constantinople. - [[experimental] Postfix types. #14237](https://github.com/ethereum/solidity/issues/14237) - Split the work between Nikola and Matheus - [Generalizing Hindley-Milner Type Inference Algorithms](https://www.researchgate.net/publication/2528716_Generalizing_Hindley-Milner_Type_Inference_Algorithms) - Experimental Solidity Type Checking - Immutables ### Agenda for 2023-05-10 - Weekly long-term light syntax brainstorming: lambda functions & higher-order functions as replacement for modifiers - Notes: https://notes.ethereum.org/6-h78QXOTbKkufpQj5ZpFg ### Agenda for 2023-05-03 - [Support EIP-712 typehash in type #14157](https://github.com/ethereum/solidity/issues/14157) - Next steps for [Markella](https://github.com/GiokaMarkella) on [Add support for Yul ASTs output](https://github.com/ethereum/solidity/pull/14177) - [Introduce solidity-next pragma](https://github.com/ethereum/solidity/pull/14168) - Naming it `pragma experimental solidity` for now. - We still have some (irrelevant) experimental functions. - Adjust the Solidity Roadmap to reflect the new changes. - [EIP-1153: Transient storage opcodes](https://eips.ethereum.org/EIPS/eip-1153) in Cancun - `TLOAD` and `TSTORE` are transaction local. - Expose the opcodes (people won't like it) **with limited highlevel support**. - Cancun should be out in Q4. - [Add support to import evm assembly json (updated). #13673](https://github.com/ethereum/solidity/pull/13673) - [Add support to import AST via Standard JSON. #14171](https://github.com/ethereum/solidity/pull/14171) - [Add support for Yul ASTs output #14177 ](https://github.com/ethereum/solidity/pull/14177) ### Agenda for 2023-04-26 - We postpone merging the literal PR and discussing it until after the next release. - We may decide to limit it only to the IR codegen or maybe even completely drop it. - JSON schemata - weighing effort against benefits (long- and short-term) - considering in combination - Two options: use a standalone schema validation library or use `nlohmann/json`, which has it built-in, but requires us to migrate to that library at the same time. - Decision: we won't do that yet, but we'll consider it after all the JSON import work is finished. ### Agenda for 2023-04-19 - Implementing the new pragma for upcoming experimental features. ```solidity pragma experimental solidity-next; ``` - Stdlib import syntax. ### Agenda for 2023-04-12 - More discussion about postfix typing. ```solidity= let x:uint256 = 42; uint256 x = 42; uint256[3][4]; uint256[3][4] x; x[3][4]; struct S { uint256 x; } S[3][4]; let x:(uint256,uint256) = ...; function f(a, b) -> c:uint256 { (a:uint256) + complexFunction(b,1:uint256) } cond ? 1 : 2 cond ? 1:uint256 : 2:uint256 cond ? (1:uint256) : (2:uint256) let // Not a severe change // "More than half of the community is in favour of adding it" // "The var keyword is now disallowed to favor explicitness." In solidity 0.5 // https://docs.soliditylang.org/en/v0.8.19/050-breaking-changes.html ``` - The type system we're aming for: Hindley Milner Type Inference with Type Classes restricted by Functional Dependencies - [Further concerns about making `shanghai` the default EVM version](https://github.com/ethereum/solidity/pull/14107#issuecomment-1503663287) and the effect of that change on tools and non-mainnet EVM implementations. ### Agenda for 2023-04-05 - [Shanghai Support #14073](https://github.com/ethereum/solidity/issues/14073) - Shanghai introduces a new opcode (`PUSH0`) that is not available in L2 EVM implementations yet (e.g. Optimism). Making it the default EVM version will result in the default compiler output not being deployable there. - We have always been considering Ethereum mainnet as the primary target so that's the main consideration when choosing the default. - This should be just a short-term problem. If it persists in the longer term, it's the frameworks (which know the target deployment network) that should prevent the user from choosing an unsupported EVM version. - On our side should make sure that the potential issue is pointed out in the release notes. ### Agenda for 2023-03-22 - Proper tuple types. - Sum and product types in the language and parsing issues that come with it. - Random notes: https://notes.ethereum.org/8TiA-epPQ82t4cgWm5UlKw - From discussion after the call: we'll likely go with introducing postfix types. ### Agenda for 2023-02-15 - Quick decision about what to do about [The old optimizer breaks public function equality #13969](https://github.com/ethereum/solidity/issues/13969). - Decision: disallow. Warning now, error in a breaking release. - Syntax proposals for extending `try`/`catch` to handle local reverts, [from @chriseth](https://github.com/ethereum/solidity/issues/13869#issuecomment-1422879881) and [from @cameel](https://github.com/ethereum/solidity/issues/13869#issuecomment-1423021751). - Another idea: replacing `try`/`catch` with `tryCall()` and match expressions. - Hari: We could ignore `try`/`catch` for now, give people `abi.tryDecode()` and see if it's enough for them. - [`try`/`catch` for `abi.decode()` or `abi.tryDecode()`](https://github.com/ethereum/solidity/issues/10381) - Decision: - Try to get feedback from the community on the [`internal catch`/`external catch` proposal](https://github.com/ethereum/solidity/issues/13869#issuecomment-1423021751). This is something that we could potentially implement right away. - In the meantime we can see if we can do anything about `abi.tryDecode()` (but we don't really have everyting needed to implement it right now). ### Agenda for 2023-02-08 - which keyword to use for dynamic immutables; new developments potentially counterindicative for using ``code`` (EOF may transition ``codecopy`` -> ``datacopy``) ([Code data location (0.9 release)](https://github.com/ethereum/solidity/issues/13723), [Immutable dynamic arrays](https://github.com/ethereum/solidity/issues/12587) - internal/external/public library function inconsistencies: - [Calls to attached functions in a library do not always match equivalent direct calls in terms of being internal/external](https://github.com/ethereum/solidity/issues/13908) - Goal: deprecate, remove, replace; - Immediate step: gather data from various sources about external/public library functions in particular - Other possible sources of user information: Twitter Survey: If people complain, we can write a short blogpost explaining why we are deprecating it. - Example of project using it is [forge-std](https://github.com/foundry-rs/forge-std/blob/master/src/StdMath.sol#L4). - try...catch and decoding & extcodesize failures - [Unable to use try/catch to reliably catch errors](https://github.com/ethereum/solidity/issues/13869) - [try/catch doesn't catch some call errors.](https://github.com/ethereum/solidity/issues/12725) - and probably a few others [try/catch block does not catch the exception caused by EXTCODESIZE check on external calls](https://github.com/ethereum/solidity/issues/11373) - The problem is that changing the behavior of the `catch` clause would be breaking. - There were ides on how to change it in a non-breaking way from @chriseth and @cameel. They'll write them down in the issue and then we'll evaluate. - abi decoding *to* calldata types https://github.com/ethereum/solidity/issues/13518 - good change; technically breaking - question: do it anyways? - Decision: take being breaking seriously - Consider allowing data locations in type tuple on RHS! - Codebase purge: - Drop EWASM backend (decision: drop now) - Drop LSP (decision: not now) - Drop gas estimator (decision: maybe non-breaking) - Drop error recovering parser (decision: ask around) - Design decisions regarding operators: - Support for `!`, `<<`, `>>` and `**`. - Support for increment, decrement and assignments. - Should other comparison operators be automatically derived from `==` and `<`? - probably eventually, but that would be requested by the user explicitly - spaceship operator? - Do we want to ever allow external and/or non-pure operators? - external: never - operators on storage must necessarily be non-pure but we won't implement them now - Do we require definitions to be global and exclude library functions? - we think it's good like that but we could reconsider if people demand relaxing it - we want to have enough at least for PRBMath and this does not prevent that - Operators on structs and other reference types. - definitely not before we deal with locations but possible later - probably not directly on arrays but encapsulated in a user-defined type might be fine - tl;dr: not soon - Operators on mixed types. - not soon; we need to fit it into a generic type system - Should we disallow defining the same operator in multiple declarations? - yes, we can disallow it - Should we go back to building completely static binaries on Linux to avoid breakage due to glibc incompatibilities? - Daniel: we can't unless we want to drop SMT support or increase binary size by an order of magnitude. Also we don't have to, at least for now, we just need a compatible build CI run again. - Long-term we could think about interfacing with Z3 in a different way, without linking it into the binary. - [Support public functions in interfaces #13890](https://github.com/ethereum/solidity/issues/13890) - The proper solution is the inheritance overhaul planned for Q3. - Unclear if OZ will be fully satisfied with that. It will require replacing interfaces with abstract contracts. -