You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

Jules Villard d4bdfec49a [pulse] record invalidation events in histories ... Summary: The eventual goal is to stop having separate sections of the trace ("invalidation part" + "access part") when the "access part" already goes through the invalidation step. For this, it needs to record when a value is made invalid along the path. This is also important for assignements to NULL/0/nullptr/nil: right now the way we record that 0 is not a valid address is via an attribute attached to the abstract value that corresponds to 0. This makes traces inconsistent sometimes: 0 can appear in many places in the same function and we won't necessarily pick the correct one. In other words, attaching traces to *values* is fragile, as the same value can be produced in many ways. On the other hand, histories are stored at the point of access, eg x->f, so have a much better chance of being correct. See added test: right now its traces is completely wrong and makes the 0 in `if (utf16StringLen == 0)` the source of the NULL value instead of the return of `malloc()`! This diff makes the traces slightly more verbose for now but this is fixed in a following diff as the traces that got longer are those that don't actually need an "invalidation" trace. Reviewed By: skcho Differential Revision: D28098337 fbshipit-source-id: e17929259		4 years ago
..
c	[pulse] record invalidation events in histories	4 years ago
c_cpp/pulse	[pulse] Loosen fieldname comparison in state	4 years ago
cpp	[pulse] record invalidation events in histories	4 years ago
dotnet	Infer# integration (#1361)	4 years ago
java	[pulse] record invalidation events in histories	4 years ago
objc	[pulse] record invalidation events in histories	4 years ago
objcpp	[pulse] record invalidation events in histories	4 years ago