Tags: snghnl/pyre-check
Tags
Use DaemonStatus to encapsulate time + connection status Summary: We always want both the connection status before and information about how long it has been since the server is ready; this combination of information makes it much easier to judge how big a problem availability is, because - we can't decide whether incremental status is bad or not *at all* without a timer, since it's expected that we'll be briefly busy - even for other statuses like starting, it's very helpful to have a record of how long start took; this, for example, can help us distinguish between an availability problem due primarily to long start times versus a problem due primarilily to frequent deamon (or persistent) restarts Putting these fields in the same dataclass makes it easier to ensure we always do the right thing, and that the logging is consistent across all telemetry events. It's worth noting that I caught another bug here: we weren't logging status in the telemetry for type coverage; this isn't a big deal today but it could be one if we ever start seeing heavy use of expression-level coverage. Reviewed By: grievejia Differential Revision: D43244195 fbshipit-source-id: d5ff1b0a39e2b09e3873a3131373a7f466c77d5d
automatic update for [email protected] Reviewed By: antonk52 Differential Revision: D39209227 fbshipit-source-id: be368d4d7cb0b27ba86606d08f813b32c652155f
Refactor parsing logic of expression level json Summary: ### Context: We want to refactor the parsing logic of `ExpressionLevelCoverageResponse` json before working onVSCode requests/responses, which will likely require similar code. ### Problem: Currently, `ExpressionLevelCoverageResponse` contains a `List[Union[CoverageAtPathResponse, ErrorAtPathResponse]]`. The `dataclasses json` library can't parse `Union` types, so the existing code was messy and needed to be refactored. ### Solution: We extract parsing of a `ExpressionLevelCoverageResponse` into a separate function instead of having some logic leak into `summary_expression_level`. Reviewed By: pradeep90 Differential Revision: D37529463 fbshipit-source-id: 12ef0d6253cfb5e1b5d22849899630fb8a37a101
Disallow accessing ambiguous abstract domain parts in a product domain Summary: Since D33037819 (facebook@5480bf6), we use `Features.BreadcrumbSet.t` at multiple locations in the taint representation. This means it is now ambiguous to use parts of `Features.BreadcrumbSet` (such as `.Self`, `.Element`) from the top level since it can refer to multiple sets (the local breadcrumbs or the propagated ones). To prevent future bugs, let's disallow using an abstract domain part if it is ambiguous. Note that this can only happen in the product domain, when computing the routing from parts to slots. Reviewed By: dkgi Differential Revision: D33488346 fbshipit-source-id: d418f5bb10fdee9648eeea3834c8ca56944bd2ce
Preserve `taint/` subdirectory structure when building `pyre-check` w… …heel Summary: Our open source builds have been broken for a long time, because the taint.config in the `taint` data folder shipped with our wheel has just been empty. It seems like the root cause was that all of our taint from various folders such as `taint/core_privacy_security`, `taint/common` was being copied into the wheel under `pyre_check/taint` rather than keeping the subdirectory structure, meaning that the empty taint.config under `common/` is being written to the `pyre_check/taint` folder in the wheel, overwriting the `core_privacy_security/taint.config` file at times, because files from both subfolders are being copied to the same destination location in the wheel. Since we need to release a new open source package due to recent GitHub issues asking about features we have long implemented (but have not pushed out), let's fix the script so we can make non-broken builds again. Reviewed By: 0xedward Differential Revision: D33247107 fbshipit-source-id: 67288937d4e640092c9b650af9f77184a08d5f27
PreviousNext