We are thrilled to release Solidity v0.8.29!

Announcements
1

This version of the compiler brings support for EVM Object Format (experimental), custom storage layouts, ethdebug, and more.

Notable Features

  • Experimental Support for EVM Object Format
  • Support for Custom Storage Layouts
  • Initial Support for ethdebug

Language Features:

  • Allow relocating contract storage to an arbitrary location.

Compiler Features:

  • Error Reporting: Errors reported during code generation now point at the location of the contract when more fine-grained location is not available.
  • ethdebug: Experimental support for instructions and source locations.
  • EVM: Support for the EVM version “Osaka”.
  • EVM Assembly Import: Allow enabling opcode-based optimizer.
  • General: The experimental EOF backend implements a subset of EOF sufficient to compile arbitrary high-level Solidity syntax via IR with optimization enabled.
  • SMTChecker: Support block.blobbasefee and blobhash.
  • SMTChecker: The option --model-checker-print-query no longer requires --model-checker-solvers smtlib2.
  • SMTChecker: Z3 is now a runtime dependency, not a build dependency (except for emscripten build).
  • Yul Parser: Make name clash with a builtin a non-fatal error.

Check out our release blog post to learn more about other features in the release and read the full changelog.
:memo: Blog: Solidity 0.8.29 Release Announcement | Solidity Programming Language
:floppy_disk: GitHub: Release Version 0.8.29 · ethereum/solidity · GitHub

:speaking_head: Help us spread the word by sharing our announcement on Twitter:
https://x.com/solidity_lang/status/1899862612361568312

1 Like
2

I was checking out the new functionality with support for custom storage layouts using the layout at keywords at the top level contract and had a few questions/comments.

1 - I see that the documentation says " The storage layout cannot be specified for abstract contracts, interfaces and libraries. Also, it is important to note that it does not affect transient state variables." I just wanted to clarify that the storage layout cannot be defined on abstract contracts, interfaces, and libraries BUT that custom storage that is defined at the top level IS inherited by abstract contracts. Is that true?

2 - Is there plans at all to make this feature overrideable or changeable? For context, it would be nice for us to be able to not have to copy an entire implementation of a contract because we want essentially two versions of the same functionality but whos storage is initialized at different locations.