Kamil Śliwak

The first part of refactor for #15179. Introduces `ObjectSource` object that can store partial IR output (without the sources of dependent contracts). Then makes `IRGenerator` output it. Finally `CompilerStack` puts...

Reuse optimized IR for bytecode dependencies

4

The quick and easy solution for #15179, which only reuses the IR.

Fix `outputSelection` affecting compilation order

1

Fixes #12932.

Fixes #15062.

Graceful handling of non-ICE exceptions

1

## Abstract Currently exceptions such as `UnimplementedFeatureError`, `CodeGenerationError`, `StackTooDeepError` and `CompilerError` are reported as internal compiler errors, i.e. by completely interrupting what the compiler is doing and printing out diagnostic...

Update Z3 to 4.13.0 or later

1

The last time we updated Z3 was 4.12.1 over a year ago (#14074/#14076). 4.13.0 has been released in April, it's about time to update. This is not critical since it...

> @cameel Maybe an interesting side note. The resulting installation shrunk from 14.92 MiB to 14.33 MiB when switching from ld.gold to ld. Installation via https://aur.archlinux.org/packages/solidity. Considering the installation contains...

Different bytecode produced via IR for some of OpenZeppelin's contracts when extra contracts are included in the input

2

## Description This looks like yet another bug where different AST IDs lead to differences in the generated bytecode. I found it when experimenting with parallel compilation of OpenZeppelin. When...

Deduplicate bytecode dependencies used by both creation and deployed object

2

## Abstract When a contract deploys another contract (via `new`) or accesses its bytecode (via `.runtimeObject` or `.creationCode`), the compiler embeds that bytecode in the accessing contract. Depending on whether...

## Abstract While the IR code generator does reuse the IR that the current contract depends on (via `new`, `.runtimeCode` or `.creationCode`) it's only the unoptimized IR that is reused....