Lines Matching full:it
7 It touches problems of modelling C++ standard library constructs in general,
29 The standard does hint that it should be possible to implement
35 Or, at least, it should be possible to explain to the analyzer that the list
36 somehow "takes hold" of the values put into it. Initializer lists can also be
47 So this sounds good, however apparently it does nothing to address our false
49 guessing that the metadata symbol attached to it, together with its contents,
50 should also escape. In fact, it's impossible to trigger a pointer escape from
56 triggering escapes when binding list elements to the list. However, it'd be as
67 turns out to be reachable. This requires no work on checker side, but it sounds
73 to escape. This puts a stress on the checkers, but with a smart data map it
79 symbol attached to it should also escape". This sounds like an ultimate freedom,
83 I'm personally liking the approach (2) - it should be possible to avoid
98 If we want to simplify the API, then maybe it makes more sense to move language
105 * Maybe it would be great to have a guideline how to evolve the analyzer and
106 follow it, so it can help us to decide in similar situations
110 writers to add modeling of language constructs. So, in my opinion, it is ok to
112 performance this way, since it only needs to be done once, and is done by the
115 **Artem:** These are some great questions, i guess it'd be better to discuss
118 * To me it seems obvious that we need to aim for a checker API that is both
120 necessary while providing a layer of simple ready-made solutions on top of it.
123 extend it when something is lacking, instead of falling back to the complex
129 constraint manager as checkers (though it's probably not worth it to transform
131 the checker overwrites stuff written by the core because it thinks it has a
135 approach, i'd make sure it's good.
142 > but it sounds performance-heavy.
145 object changes, metadata symbols attached to it aren't changing (because symbols
151 (https://lists.llvm.org/pipermail/cfe-dev/2016-May/049000.html), it would have
153 metadata, and the Store would always know about it. This example adds to my
162 but it would allow for transfer functions to get at those regions and it would
167 end element regions for it.
170 actually exist (it is just a library implementation detail where that storage
171 lives) and (2) it is perfectly valid for a pointer into that storage to be
173 (Well, in this case just read since it is allowed to be read-only memory).
178 well at (modeling typestate) and turns it into a hard one that the analyzer is
183 read to or written from in the client program? If so, then it makes sense for
194 > identifiers. This wouldn't specify how the memory is reachable, but it would
195 > allow for transfer functions to get at those regions and it would allow for
200 class for that if we eg. want it typed). The problem is that the relation
204 from its parent object, tomorrow it's not, and maybe something else becomes
207 rely on it to do any actual work. We'd anyway need to rely on the checker to do
212 > beginning and end element regions for it.
214 So maybe in fact for std::initializer_list it may work fine because you cannot
216 essentially immutable. For the future, i feel as if it is a dead end.
238 pointer was unique, it could theoretically have ``.get()``-ed above and the code
239 could of course break the uniqueness invariant (though we'd probably want it).
240 The checker can say that "even if ``*a`` did escape, it was not because it was
263 > actually exist (it is just a library implementation detail where that storage
264 > lives) and (2) it is perfectly valid for a pointer into that storage to be
266 > storage. (Well, in this case just read since it is allowed to be read-only
272 > analyzer does well at (modeling typestate) and turns it into a hard one that
284 or instead relying on the Store to do exactly what it's designed to do.
288 > can be read to or written from in the client program? If so, then it makes
294 As a metaphor, i'd probably compare it to body farms - the difference between
297 pleasant to work with, even if not omnipotent. I think it's fine for a
299 variable doesn't actually exist, even if it cannot be seen from outside the
300 function call. I'm not seeing immediate practical difference between "it does
301 actually exist" and "it doesn't actually exist, just a handy abstraction".
302 Similarly, i think it's fine if we have a ``CXXRecordDecl`` with
304 abstraction (we don't even need to know its name or offset, only that it's there
309 We've discussed it in person with Devin, and he provided more points to think
318 analyzer's core, which would not be able to predict that it needs to take a
319 checker-specific region as this-region, which makes it harder, though it might
323 make super sure that they don't make it into the diagnostic messages.