- User Since
- Apr 14 2017, 1:59 PM (58 w, 1 d)
Fri, May 25
@NoQ we should make sure the memory is not exploding and that we don't make the analyzer slower in other cases. Though we could commit this, and then let CI figure out potential regressions.
Reverted in r333257
Thu, May 24
George, how do you create such stack of patches? Is there any automated tool for that?
What happens without this change?
IIRC that's how it is for all sanitizers.
Wed, May 23
@morehouse we have issues with stdout/stderr arriving in unexpected order when run on devices and streaming across the network.
In this case adding -DAG seems like an easiest choice, since the test purpose is to check that close_fd_mask would close the corresponding file descriptor.
Definitely looks much cleaner, some nits inline. Can we protect against API misuse?
OK let's try to split it further.
Mon, May 21
Also we should make sure that all recursive transformations on expressions represented as DAGs should be memoized.
@NoQ I'm really wary of magic numbers.
Fri, May 18
@Szelethus I can, but since you've had quite a few patches accepted, do you want to just apply for a commit access ? https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access
Thu, May 17
Wed, May 16
LGTM provided that nits inline are fixed
Not sure yet whether i will land them right away, or wait for clang-tidy part.
Tue, May 15
I see four separate changes: s/.sys/mem one (can be committed without review), exposing printJSONValues and consequent adding of a lock, adding a constructor accepting a map, and fixing formatting in printJSONValue. All four look good to me, but probably should be reviewed separately.
LGTM! with stable-filename option we could even avoid the regexp.
that you don't need function to pointer decay when there's already a function pointer?