# compiler: simplify IESes · gitcafe/zig

[View on GitCafe](https://git.cafe/gitcafe/zig/commit/5d47a207ea6d83a610bda40d22bf58ea188593aa)

Repository: [gitcafe/zig](https://git.cafe/gitcafe/zig)

Visibility: public

Requested revision: 5d47a207ea6d83a610bda40d22bf58ea188593aa

Requested commit: 5d47a207ea6d83a610bda40d22bf58ea188593aa

Commit: 5d47a207ea6d83a610bda40d22bf58ea188593aa

Tree: fc05e3158f42493c913dd0f872cf55a32e033936

Author: Matthew Lugg

Committer: Matthew Lugg

## Message

```
compiler: simplify IESes

It is always a bug in Sema to check whether an IES is resolved. This is
because whether the IES is resolved depends on whether the function
which owns it has been analyzed yet, which depends on the order the
compiler analyzes declarations in, which it is incorrect to have any
dependency on. Instead, we must always either not look at the resolved
set, or resolve it first (with `Sema.ensureFuncIesResolved`) and then
look at the definitely-resolved concrete error set.

Luckily, removing a bunch of the buggy logic which tried to
opportunistically use already-resolved inferred error sets actually
didn't regress anything! It seems this logic was mostly left over from
before Andrew reworked inferred error sets, and had become essentially
dead code. This is because inferred error sets are stricter than they
used to be, and in particular, we make no attempt to support mutual
recursion.

I suspect that most of the logic touching IESes can be simplified even
further than I have done here without regressing any existing code; my
goal in this commit was just to remove any *buggy* code I could find.

```

## Parents

- [9675cf2f880f096f34cec5a78b5b60f2b74c0583](https://git.cafe/gitcafe/zig/commit/9675cf2f880f096f34cec5a78b5b60f2b74c0583?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zig/tree/5d47a207ea6d83a610bda40d22bf58ea188593aa?format=markdown)