etyp

Ah, I used EDG for static analysis, but joined when we were switching over to using Clang for the frontend. I can't say for sure, but part of it was definitely just to save money using open source. The code that was hacked on top of EDG was also ridiculous, so there was a lot of accumulated tech debt there.

Looking back at that code definitely brings back memories. As a consumer of both frontends, I will say I much preferred working with Clang's. Both needed extra work on top to support everything we needed. Maybe I'm just not as acquainted with C as I would like to be. It's cool to look at this again, though.

There is a chance that the title here was intentionally worded to answer a question people are likely to search for, then actually answer their concerns.

This is one of those natural consequences of "everything is an expression" languages that I really like! I like more explicit syntax like Zig's labelled blocks, but any of these are cool.

Try this out, you can actually (technically) assign a variable to `continue` like:

let x = continue;

Funnily enough, one of the few things that are definitely always a statement are `let` statements! Except, you also have `let` expressions, which are technically different, so I guess that's not really a difference at all.

is ,AOE too far?

I read it as "this was a big news story which we care about. You may know it, but it is not the primary reason. Here is the primary reason."

Random note since Godbolt was mentioned: It's also fun to hop on play.rust-lang.org and see what different IRs look like via the "..." next to "RUN." Just look at how simple the HIR is pretty simple for "Hello world" - then check out the MIR ;)

This goes to show how Zig's language design makes everything look nicer and simpler - the `errdefer` patterns in tests are super nice! I've debugged my Zig tests with simple print debugging (or try to narrow it down to a standalone case I can use a debugger), but I'll certainly use some of these tricks in the future.

Zeek is well known in "security" spaces, but not as much in "developer" spaces. It did get me a bit excited to see Zeek here until I realized it was unrelated, though :)

I really love that static analyzers are pushing in this direction! I loved writing Clippy lints and I think applying that "it's just code" with custom checks is a powerful idea. I worked on a static analysis product and the rules for that were horrible, I don't blame the customers for not really wanting to write them.

Is there a general way to apply/remove/act on taint in Go checkers? I may not be digging deeply enough but it seems like the example just uses some `unsafeVars` map that is made with a magic `isUserInputSource` method. It's hard for me to immediately tell what the capabilities there are, I bet I'm missing a bit.

I like how this is structured. When I read that inline types get copied-on-borrow I was pretty put off. Then since fields of inline types can't be assigned new values it seems a bit better, as long as you roughly know what's happening. Hopefully the diagnostics are good enough there. I like the detailed alternatives that weren't chosen.

I appreciate being able to choose which side of the tradeoff (always-copy or heap allocated) you want to be on, but either way be assured it's safe. Not sure how I feel about it in practice without trying it, though :)

I've actually tried serializing languages into protobufs. The main reason was it made communication from X random programming language to Java in a consistent, structured way. Seems like it's just how they sent the IR from OCaml to C++. On either side you'll get the Bolt IR so I don't think debugging suffers too much. But the extra step for serializing and deserializing is a bit of a bummer