Tags: esiebomaj/pyre-check
Tags
Make parent file / directory tests robust to existing files Summary: I created files `/tmp/a` and `/tmp/b` when working on some ocaml tests yesterday, because I wanted to diff some json output. This broke my unit tests! It turns out that the existing `find_parent_directory_containing_*` logic is not possible to test robustly in the current form - it does a recursive search of all parents of a temp directory, but we have no control at all on the contents of directories outside of the ones we control. So, I tweaked code to - allow us to optionally truncate the search at some path - make two levels of directories in the tests - stop search after checking the outer level Reviewed By: grievejia Differential Revision: D31800614 fbshipit-source-id: 6e20e8074699f9ac13ea7e8ad3a0dc3b093d8877
Line-level coverage information match file-level statistics (1/3) Summary: ### Context We already surface file-level coverage information, this is collected by AnnotationCountCollector in statistics_collector. We are now interested in providing finer-grained coverage information that is line-level, this is collected by CoverageCollector in coverage_collector. The existing implementation of CoverageCollector was a placeholder one with a trivial implementation. This stack of diff is intended to bring the line-level coverage information match the file-level statistics that we collect. ### This diff As a first step towards it, collect information in CoverageCollector in a fashion similar to AnnotationCountCollector, but more granularly. So instead of counting, we are actually collecting the items that we were counting in AnnotationCountCollection. For testing, we verify that the lengths of the items we are collecting are the same as would have been with AnnotationCountCollector. ### Stack-to-be The diffs in the stack that will follow will do the following: 1. Change the `covered_lines` and `uncovered_lines` be based on globals, attributes, parameters, etc. 2. Refactor CoverageCollector and AnnotationCountCollector, so that we have base class AnnotationCollector and share more code. We intentionally do not do this first, so as not affect statistics jobs. Reviewed By: grievejia Differential Revision: D30622246 fbshipit-source-id: 05479efe0eb2867959cb7d39e6f6606127abe9c4
Clean up another c qualifier error Summary: Filenames are `const char *`, not `char *` and the `statfs` interface respects this; we should as well. Reviewed By: grievejia Differential Revision: D28464007 fbshipit-source-id: 10cbe9875d9f036a075a7b0ca09834170555a431
Fix up comments on Define.Signature.t Summary: We had inline comments (by that I mean trailing comments) for fields in Define.Signature.t, and in a refactor the autoformatter moved our comments for us to the next line. This is bad because comments should always go above the code, not below, and it was actually kind of disastrous in this case because `parent` and `nesting_define` - the very things we wanted to the comment to clearly distinguish - are right next to each other so the comment became a lie. Anyway, patching up the comments to be above the record fields they refer to, and also to be consistent across the .mli file, the signature, and the struct. It's probably not a good idea for us to make too much use of inline comments for this reason - autoformatting can easily drop them to a new line at which point they go from being helpful to actively misleading. To be honest I think this is an issue in the specification of `ocamlformat`, moving an inline comment down is probably almost never the right thing to do. Reviewed By: grievejia Differential Revision: D28151440 fbshipit-source-id: 52dff080c158db0f54dbd6ddbba93307524d2dea
Resolve concatenation of tuples via unpacking. Summary: Problem: We used to resolve `(1, *(2, 3))` as `Tuple[int, unknown]`. This was because we correctly resolved `(2, 3)` as `Tuple[int, int]` and then dropped the ball on the `Starred` expression because there is no type to express a naked unpacked tuple. With variadic tuples, we can handle different kinds of unpacked tuples. Reviewed By: dkgi Differential Revision: D26821042 fbshipit-source-id: 7aad420ca4b2775e32617077a4f1d0e965efff30
PreviousNext