Quinton Miller

Maybe we could drop all those linker flags whenever cross-compiling, but I found that there is no way to tell in Crystal code whether we are also doing the cross-linking...

`LLVM_LDFLAGS` would differ from `--link-flags` if `require "llvm"` alone doesn't call any LLVM functions. But it turns out the class variable initializer for `LLVM::Attribute.@@kind_ids` will call `LLVMGetEnumAttributeKindForName`

This actually affects `Set` too, e.g. `Set#|` should more or less behave like `Hash#merge` in terms of `@compare_by_identity`. (`Set` doesn't have a default proc.)

Have you tried `Regex#match` with `Regex::Options::ANCHORED`? `getch` should be equivalent to `scan(/./)`, though a Crystal implementation is certainly faster than that.

I think the `unless` is supposed to check for `Keyword::IN` as well

Duplicate of #9029 (and several other issues that came before)

In that case, `expect_raises` itself returns the exception that was caught, so you could use normal matchers on the object afterwards: ```crystal error = expect_raises(ResponseError) { Object.new.foo } error.code.should eq(401)...

Loading symbols is also not thread-safe even after they have been initialized: ```crystal caller Array.new(4) do Thread.new do 100.times { caller } end end.each(&.join) ``` ```crystal # `-Dpreview_mt` require "wait_group"...

On MinGW-w64 the snippets may still produce `???`, but never break with an access violation, probably due to the DWARF parser being written in Crystal

You could somewhat circumvent multiplication by using `sizeof`, but it is a bit tricky since you need an extra type to store the result: ```crystal module Matrix(T, W, H) struct...