Egor Suvorov

+1, would be very glad to see it in the book or somewhere. My understanding is that it's done for optimization purposes, see [Rust's RFC 2592's section "Waking up"](https://github.com/rust-lang/rfcs/blob/master/text/2592-futures.md#waking-up) (it's...

One can coerce non-capturing closure to a function pointer (just like with lambdas in in C++). However, the following example does not compile, as the closure is now capturing: ```rust...

Kludgy workaround is to alter [`lexer.js:21`](https://github.com/gnab/remark/blob/10b75158983d61cc07384e09713137c4f823d3c0/src/remark/lexer.js#L21): Before: ``` FENCES: /(?:^|\n) *(`{3,}|~{3,}) *(?:\S+)? *\n(?:[\s\S]+?)\s*\4 *(?:\n+|$)/, ``` After: ``` FENCES: /(?:^|\n)[ *]*(`{3,}|~{3,}) *(?:\S+)? *\n(?:[\s\S]+?)\s*\4 *(?:\n+|$)/, ``` I allowed a code block to...

@tmeasday I think it's because of `{reverse: true}` filter in this line. However, in this example I use reverse relations and here are steps to reproduce: 1. Create new meteor...

Looks like a tooling bug, not doctest's bug. The following code exhibits the same behavior (works ok, but crashes under gdb): ```c++ #include #include int main() { std::thread([&]() { thread_local...

Looks like mingw-w64 issue, not msys2-specific, so I filed it under https://sourceforge.net/p/mingw-w64/bugs/893/

Ok, so it's a very old mingw issue: non-trivial destructors of `thread_local` variables may be called in a wrong order, including being called after the underlying memory is free (which...

Kinda works, but I'd prefer to avoid calling `CHECK`s in other threads at all. It looks to me like a direct way to race conditions on `DOCTEST_THREAD_LOCAL std::ostringstream g_oss` and...

Ah, yes, sorry, it makes perfect sense in this case to avoid other unknown complications with `thread_local` (if any).

From a comment in #616: > Is the ability to escape the other characters with a special meaning (? and *) something worth considering? (I'm aware that their parsing is...