Page MenuHomePhabricator

xazax.hun (Gábor Horváth)
User

Projects

User does not belong to any projects.

User Details

User Since
Sep 17 2012, 3:16 AM (382 w, 5 d)

Recent Activity

Yesterday

xazax.hun updated subscribers of D69825: [Clang][Driver] Re-use the calling process instead of creating a new process for the cc1 invocation.

This patch breaks scan-build-py which parses the output of "-###" to get -cc1 command. There might be other tools with the same problems. Could we either remove (in-process) from CC1Command::Print or add a line break?

Fri, Jan 17, 4:37 PM · Restricted Project, Restricted Project
xazax.hun committed rG05c7dc664809: [DataFlow] Factor two worklist implementations out (authored by xazax.hun).
[DataFlow] Factor two worklist implementations out
Fri, Jan 17, 8:16 AM
xazax.hun closed D72380: [DataFlow] Factor two worklist implementations out.
Fri, Jan 17, 8:15 AM · Restricted Project

Thu, Jan 16

xazax.hun updated the diff for D72380: [DataFlow] Factor two worklist implementations out.
  • Fix typo.
Thu, Jan 16, 1:16 PM · Restricted Project

Wed, Jan 15

xazax.hun added a comment to D72380: [DataFlow] Factor two worklist implementations out.

Here is an example:

void f() {
  int i;
  while (i < 42 && i) {
    if (i)
      &i;
  }
}
Wed, Jan 15, 3:53 PM · Restricted Project
xazax.hun added a comment to D72380: [DataFlow] Factor two worklist implementations out.
In D72380#1822927, @NoQ wrote:

The change in uninitialized values analysis gives me a bit of anxiety. Could you explain what exactly has changed that caused the change in the stats and why you think it doesn't make a difference, maybe give an example? (an example could be obtained by creduce-ing over "the stats have changed" criterion)

We will process it multiple times with the original implementation, we traverse the CFG both using DFS and using reverse post order.

Wed, Jan 15, 3:34 PM · Restricted Project
xazax.hun added a comment to D72380: [DataFlow] Factor two worklist implementations out.
In D72380#1822927, @NoQ wrote:

The change in uninitialized values analysis gives me a bit of anxiety. Could you explain what exactly has changed that caused the change in the stats and why you think it doesn't make a difference, maybe give an example? (an example could be obtained by creduce-ing over "the stats have changed" criterion)

Wed, Jan 15, 3:20 PM · Restricted Project
xazax.hun created D72810: [LifetimeAnalysis] Add support for lifetime annotations on functions.
Wed, Jan 15, 2:15 PM · Restricted Project
xazax.hun added a comment to D72380: [DataFlow] Factor two worklist implementations out.

Ping for the other reviewers :)

Wed, Jan 15, 10:03 AM · Restricted Project

Thu, Jan 9

xazax.hun accepted D71612: [analyzer] Add PlacementNewChecker.
Thu, Jan 9, 9:45 AM · Restricted Project
xazax.hun added inline comments to D71612: [analyzer] Add PlacementNewChecker.
Thu, Jan 9, 8:49 AM · Restricted Project

Wed, Jan 8

xazax.hun committed rGb2fb6a7ba118: [NFC] Whitespace fixes (authored by xazax.hun).
[NFC] Whitespace fixes
Wed, Jan 8, 4:42 PM
xazax.hun updated the diff for D72380: [DataFlow] Factor two worklist implementations out.
  • Added doxygen comments and unit tests.
Wed, Jan 8, 12:32 PM · Restricted Project
xazax.hun added inline comments to D72380: [DataFlow] Factor two worklist implementations out.
Wed, Jan 8, 12:32 PM · Restricted Project
xazax.hun added inline comments to D72380: [DataFlow] Factor two worklist implementations out.
Wed, Jan 8, 11:55 AM · Restricted Project
xazax.hun updated the summary of D72380: [DataFlow] Factor two worklist implementations out.
Wed, Jan 8, 11:55 AM · Restricted Project
xazax.hun added a comment to D72380: [DataFlow] Factor two worklist implementations out.

Fortunately, UninitializedValues has some statistics. So I printed it for a big translation unit (SemaExpr.cpp) before and after this change.

Wed, Jan 8, 11:45 AM · Restricted Project
xazax.hun updated the diff for D72380: [DataFlow] Factor two worklist implementations out.
  • Prepopulating the worklist for UninitializedValues seems to be redundant.
Wed, Jan 8, 11:36 AM · Restricted Project

Tue, Jan 7

xazax.hun added a reviewer for D72380: [DataFlow] Factor two worklist implementations out: mgehre.
Tue, Jan 7, 6:19 PM · Restricted Project
xazax.hun updated the diff for D72380: [DataFlow] Factor two worklist implementations out.
  • Add missing new line at the end of file.
  • Populate the initial worklist in UninitializedValues more efficiently.
Tue, Jan 7, 6:10 PM · Restricted Project
xazax.hun created D72380: [DataFlow] Factor two worklist implementations out.
Tue, Jan 7, 5:59 PM · Restricted Project
xazax.hun committed rG46ac6a4dcd9b: [analyzer] Update help text to reflect sarif support (authored by xazax.hun).
[analyzer] Update help text to reflect sarif support
Tue, Jan 7, 8:40 AM
xazax.hun closed D72289: [analyzer] Update help text to reflect sarif support.
Tue, Jan 7, 8:40 AM · Restricted Project
xazax.hun committed rG247a6032549e: [LifetimeAnalysis] Do not forbid void deref type in gsl::Pointer/gsl::Owner… (authored by xazax.hun).
[LifetimeAnalysis] Do not forbid void deref type in gsl::Pointer/gsl::Owner…
Tue, Jan 7, 8:40 AM
xazax.hun closed D72097: [LifetimeAnalysis] Do not forbid void deref type in gsl::Pointer/gsl::Owner annotations.
Tue, Jan 7, 8:40 AM · Restricted Project

Mon, Jan 6

xazax.hun created D72289: [analyzer] Update help text to reflect sarif support.
Mon, Jan 6, 10:16 AM · Restricted Project

Fri, Jan 3

xazax.hun added inline comments to D72097: [LifetimeAnalysis] Do not forbid void deref type in gsl::Pointer/gsl::Owner annotations.
Fri, Jan 3, 4:37 PM · Restricted Project
xazax.hun updated the diff for D72097: [LifetimeAnalysis] Do not forbid void deref type in gsl::Pointer/gsl::Owner annotations.
  • Fix typo.
Fri, Jan 3, 4:37 PM · Restricted Project
xazax.hun updated the diff for D72097: [LifetimeAnalysis] Do not forbid void deref type in gsl::Pointer/gsl::Owner annotations.
  • Update the documentation.
Fri, Jan 3, 4:18 PM · Restricted Project
xazax.hun committed rG0458e63d28a6: [fuchsia] Enable Clang Static Analyzer (authored by xazax.hun).
[fuchsia] Enable Clang Static Analyzer
Fri, Jan 3, 3:51 PM
xazax.hun closed D72188: [fuchsia] Enable Clang Static Analyzer.
Fri, Jan 3, 3:51 PM · Restricted Project
xazax.hun created D72188: [fuchsia] Enable Clang Static Analyzer.
Fri, Jan 3, 3:48 PM · Restricted Project
xazax.hun added a comment to D72018: [attributes] [analyzer] Add an attribute to prevent checkers from modeling a function.
In D72018#1802636, @NoQ wrote:

Would changing the literal in the attribute have the same effect? I.e., acquire_handle("Fuchsia_But_Please_Ignore_Me").

It should, but doesn't currently because we don't have any checking that the string literal matches a name in the static analyzer or clang-tidy for that attribute.

Fri, Jan 3, 8:59 AM · Restricted Project

Thu, Jan 2

xazax.hun accepted D72113: [CMake] clang-scan-deps in Fuchsia distribution.

LG, thanks!

Thu, Jan 2, 2:59 PM · Restricted Project
xazax.hun added a comment to D72097: [LifetimeAnalysis] Do not forbid void deref type in gsl::Pointer/gsl::Owner annotations.

Could you provide a more fleshed out example of a case where it is useful?

Thu, Jan 2, 12:40 PM · Restricted Project
xazax.hun created D72097: [LifetimeAnalysis] Do not forbid void deref type in gsl::Pointer/gsl::Owner annotations.
Thu, Jan 2, 12:03 PM · Restricted Project
xazax.hun added a comment to D72018: [attributes] [analyzer] Add an attribute to prevent checkers from modeling a function.

Thank you for the explanation, that makes sense, but I'm still a bit uncomfortable. In this case, it seems like the author of the API needs to 1) know that users will be analyzing the code with clang's static analyzer, 2) and that a particular function will cause problems for a specific check. It seems like the API author won't be in a position to add the attribute to the correct APIs, and what we really need is something for a *user* to write on an existing declaration they may not control or have the ability to modify the declaration of. I am not certain how much I like this idea, but perhaps we could allow the attribute to be written on a redeclaration and apply it to the canonical declaration so that users could add the attribute instead of relying on the library author to do it for them?

Thu, Jan 2, 11:43 AM · Restricted Project
xazax.hun added a comment to D72018: [attributes] [analyzer] Add an attribute to prevent checkers from modeling a function.

This seems like a very specialized attribute for the static analyzer and I'm not certain how much utility it adds, but that may be because I don't understand the analyzer requirements sufficiently yet. It seems as though this attribute is intended to suppress diagnostics within a certain function for a certain check, much like gsl::suppress does for the C++ Core Guidelines. Is that correct? If so, perhaps we should just reuse that attribute (but with a different spelling)?

Thu, Jan 2, 9:19 AM · Restricted Project

Mon, Dec 30

xazax.hun added inline comments to D71980: [clang-tidy] Disable Checks on If constexpr statements in template Instantiations for BugproneBranchClone and ReadabilityBracesAroundStatements.
Mon, Dec 30, 10:04 PM · Restricted Project, Restricted Project
xazax.hun accepted D71980: [clang-tidy] Disable Checks on If constexpr statements in template Instantiations for BugproneBranchClone and ReadabilityBracesAroundStatements.

Please add new lines to the end of the test files. Also please add a test similar to the godbolt link you gave me to show that if consexpr (false) outside of templates work as expected. Otherwise LGTM!

Mon, Dec 30, 10:04 PM · Restricted Project, Restricted Project
xazax.hun added inline comments to D71980: [clang-tidy] Disable Checks on If constexpr statements in template Instantiations for BugproneBranchClone and ReadabilityBracesAroundStatements.
Mon, Dec 30, 8:05 PM · Restricted Project, Restricted Project
xazax.hun added a comment to D71980: [clang-tidy] Disable Checks on If constexpr statements in template Instantiations for BugproneBranchClone and ReadabilityBracesAroundStatements.

Thanks for working on this, please see one of my concerns inline.

Mon, Dec 30, 2:57 PM · Restricted Project, Restricted Project
xazax.hun created D72018: [attributes] [analyzer] Add an attribute to prevent checkers from modeling a function.
Mon, Dec 30, 2:52 PM · Restricted Project

Mon, Dec 23

xazax.hun committed rG379613d7c7fa: [CFG] Fix an assertion failure with static initializers (authored by xazax.hun).
[CFG] Fix an assertion failure with static initializers
Mon, Dec 23, 4:41 PM
xazax.hun closed D71791: [CFG] Fix an assertion failure with static initializers.
Mon, Dec 23, 4:41 PM · Restricted Project
xazax.hun updated the diff for D71791: [CFG] Fix an assertion failure with static initializers.

I decided to fix the unittests. Having CFGs full of dangling pointers to the AST does not look fun at all, so I think this change was long overdue.

Mon, Dec 23, 10:01 AM · Restricted Project

Fri, Dec 20

xazax.hun created D71791: [CFG] Fix an assertion failure with static initializers.
Fri, Dec 20, 5:34 PM · Restricted Project
xazax.hun committed rG59878ec8092b: [analyzer] Add path notes to FuchsiaHandleCheck. (authored by xazax.hun).
[analyzer] Add path notes to FuchsiaHandleCheck.
Fri, Dec 20, 12:50 PM
xazax.hun closed D70725: [analyzer] Add path notes to FuchsiaHandleCheck.
Fri, Dec 20, 12:50 PM · Restricted Project
xazax.hun added a comment to D70725: [analyzer] Add path notes to FuchsiaHandleCheck.

Thanks for the reviews!

Fri, Dec 20, 12:49 PM · Restricted Project
xazax.hun added a comment to D70470: [analyzer] Add FuchsiaHandleCheck to catch handle leaks, use after frees and double frees.

Thanks for the reviews!

Fri, Dec 20, 12:49 PM · Restricted Project
xazax.hun committed rG82923c71efa5: [analyzer] Add Fuchsia Handle checker (authored by xazax.hun).
[analyzer] Add Fuchsia Handle checker
Fri, Dec 20, 12:36 PM
xazax.hun closed D70470: [analyzer] Add FuchsiaHandleCheck to catch handle leaks, use after frees and double frees.
Fri, Dec 20, 12:36 PM · Restricted Project
xazax.hun committed rGfe17b30a7957: [attributes][analyzer] Add annotations for handles. (authored by xazax.hun).
[attributes][analyzer] Add annotations for handles.
Fri, Dec 20, 11:51 AM
xazax.hun closed D70469: [attributes] [analyzer] Add handle related attributes.
Fri, Dec 20, 11:51 AM · Restricted Project
xazax.hun added a comment to D70469: [attributes] [analyzer] Add handle related attributes.

Thanks for the review! :)

Fri, Dec 20, 11:51 AM · Restricted Project
xazax.hun added inline comments to D71612: [analyzer] Add PlacementNewChecker.
Fri, Dec 20, 8:39 AM · Restricted Project

Dec 17 2019

xazax.hun added a comment to D70836: [analysis] Fix value tracking for pointers to qualified types.

Great! I have one question though. Will this also work as intended with sugared types? (e.g. typedefs)
I believe this might be one of the main reason why the original author used canonical types in the first place.

Dec 17 2019, 6:07 PM · Restricted Project
xazax.hun committed rGea93d7d64216: [CFG] Add an option to expand CXXDefaultInitExpr into aggregate initialization (authored by xazax.hun).
[CFG] Add an option to expand CXXDefaultInitExpr into aggregate initialization
Dec 17 2019, 5:58 PM
xazax.hun closed D71642: [CFG] Add an option to inline CXXDefaultInitExpr into aggregate initialization.
Dec 17 2019, 5:58 PM · Restricted Project
xazax.hun updated the diff for D71642: [CFG] Add an option to inline CXXDefaultInitExpr into aggregate initialization.
  • Use range based for.
Dec 17 2019, 5:58 PM · Restricted Project
xazax.hun updated the diff for D71642: [CFG] Add an option to inline CXXDefaultInitExpr into aggregate initialization.
  • Remove accidentally added files.
Dec 17 2019, 5:38 PM · Restricted Project
xazax.hun updated the diff for D71642: [CFG] Add an option to inline CXXDefaultInitExpr into aggregate initialization.
  • Fix review comments.
Dec 17 2019, 5:38 PM · Restricted Project
xazax.hun updated the diff for D71642: [CFG] Add an option to inline CXXDefaultInitExpr into aggregate initialization.
  • Add missing tests.
Dec 17 2019, 5:29 PM · Restricted Project
xazax.hun retitled D71642: [CFG] Add an option to inline CXXDefaultInitExpr into aggregate initialization from [CFG] Add on option to inline CXXDefaultInitExpr into aggregate initialization to [CFG] Add an option to inline CXXDefaultInitExpr into aggregate initialization.
Dec 17 2019, 5:29 PM · Restricted Project
xazax.hun created D71642: [CFG] Add an option to inline CXXDefaultInitExpr into aggregate initialization.
Dec 17 2019, 5:20 PM · Restricted Project
xazax.hun added inline comments to D71612: [analyzer] Add PlacementNewChecker.
Dec 17 2019, 11:46 AM · Restricted Project
xazax.hun updated the diff for D70469: [attributes] [analyzer] Add handle related attributes.
  • Added string argument to specify the handle type.
  • Only AcquireHandleAttr can be a type attribute and it can only be applied to function types.
Dec 17 2019, 10:56 AM · Restricted Project

Dec 16 2019

xazax.hun added inline comments to D70469: [attributes] [analyzer] Add handle related attributes.
Dec 16 2019, 9:39 AM · Restricted Project

Dec 12 2019

xazax.hun updated the diff for D70470: [analyzer] Add FuchsiaHandleCheck to catch handle leaks, use after frees and double frees.
  • Fix some problems discovered during some real world stress test
  • Add more tests
  • The ASCII art is not updated yet, but will do so at some point.
Dec 12 2019, 3:43 PM · Restricted Project

Dec 11 2019

xazax.hun committed rG9fdcae7c81f5: [analyzer] Do not cache out on some shared implicit AST nodes (authored by xazax.hun).
[analyzer] Do not cache out on some shared implicit AST nodes
Dec 11 2019, 5:16 PM
xazax.hun closed D71371: [analyzer] Do not cache out on some shared implicit AST nodes..
Dec 11 2019, 5:16 PM · Restricted Project
xazax.hun updated the diff for D71371: [analyzer] Do not cache out on some shared implicit AST nodes..
  • Removed leftover code from previous approach.
Dec 11 2019, 4:19 PM · Restricted Project
xazax.hun updated the diff for D71371: [analyzer] Do not cache out on some shared implicit AST nodes..
  • Omit nodes from CFG instead of trying to make the states distinct.
Dec 11 2019, 4:09 PM · Restricted Project
xazax.hun added a comment to D71371: [analyzer] Do not cache out on some shared implicit AST nodes..

Hmm loops. Right. So this solution is insufficient because it can prevent legitimate caching out in loops.

Dec 11 2019, 1:23 PM · Restricted Project
xazax.hun committed rG5882e6f36fd9: [analyzer] Escape symbols conjured into specific regions during a conservative… (authored by xazax.hun).
[analyzer] Escape symbols conjured into specific regions during a conservative…
Dec 11 2019, 11:59 AM
xazax.hun closed D71224: [analyzer] Escape symbols stored into specific region after a conservative evalcall. .
Dec 11 2019, 11:57 AM · Restricted Project
xazax.hun created D71371: [analyzer] Do not cache out on some shared implicit AST nodes..
Dec 11 2019, 11:28 AM · Restricted Project
xazax.hun added inline comments to D70469: [attributes] [analyzer] Add handle related attributes.
Dec 11 2019, 8:43 AM · Restricted Project
xazax.hun added a comment to D70469: [attributes] [analyzer] Add handle related attributes.
In D70469#1778609, @NoQ wrote:

What about __attribute__((acquire_handle("fuchsia")))

Dec 11 2019, 8:34 AM · Restricted Project
xazax.hun accepted D71322: [analyzer] CStringChecker: Fix overly eager assumption that memcmp arguments overlap..

Less state split, yay!

Dec 11 2019, 8:30 AM · Restricted Project
xazax.hun accepted D71321: [analyzer] CStringChecker: Warning text fixes..

Cool! :)

Dec 11 2019, 8:27 AM · Restricted Project

Dec 10 2019

xazax.hun updated the diff for D71224: [analyzer] Escape symbols stored into specific region after a conservative evalcall. .
  • Rebasing after reverting the pre-escaping.
Dec 10 2019, 5:05 PM · Restricted Project
xazax.hun committed rG8434fbbee62e: Revert "[analyzer] Keep track of escaped locals" (authored by xazax.hun).
Revert "[analyzer] Keep track of escaped locals"
Dec 10 2019, 4:46 PM
xazax.hun added a reverting change for rGf3a28202ef58: [analyzer] Keep track of escaped locals: rG8434fbbee62e: Revert "[analyzer] Keep track of escaped locals".
Dec 10 2019, 4:46 PM
xazax.hun added a comment to D71152: [analyzer] Keep track of escaped locals..

Whoops, this one was updated accidentally. Wrong tab :(

Dec 10 2019, 3:05 PM · Restricted Project
xazax.hun updated the diff for D71224: [analyzer] Escape symbols stored into specific region after a conservative evalcall. .
  • First take on trying to reuse processPointerEscapedOnBind.
Dec 10 2019, 3:05 PM · Restricted Project
xazax.hun updated the diff for D71152: [analyzer] Keep track of escaped locals..
  • A first take on trying to reuse processPointerEscapedOnBind.
Dec 10 2019, 2:59 PM · Restricted Project
xazax.hun added a comment to D71224: [analyzer] Escape symbols stored into specific region after a conservative evalcall. .

I think I found the main problem with the current model, at least for the FuchsiaHandleCheck.

Dec 10 2019, 2:37 PM · Restricted Project
xazax.hun added a comment to D71224: [analyzer] Escape symbols stored into specific region after a conservative evalcall. .
In D71224#1778303, @NoQ wrote:

So I was wondering if we got the default right. Maybe a checker should do more work to get the escaping rather than more work preventing it?

But that's exactly how it works right now(?) If you don't define checkPointerEscape you get no escaping, if you do extra work of defining it you get the exact amount of escaping that you want.

Dec 10 2019, 2:18 PM · Restricted Project
xazax.hun added a comment to D71224: [analyzer] Escape symbols stored into specific region after a conservative evalcall. .
In D71224#1778231, @NoQ wrote:

I don't think this is a good enough model currently. The problem is that, it does not play well with annotations. E.g. the checker can see a symbol escaping, but it does not have a whole lot of information how. For example, currently, there is no way to check if the output parameter through which the escape happened was annotated somehow.

Hmm. If the function is annotated, it is hopefully "fully" annotated, or at least the programmer doesn't mind adding more annotations to it. Given that you have your CallEvent structure in checkPointerEscape, i hope you can easily see if there are any annotations at all on the function, and if so, suppress the current escape entirely. Or at least scan the annotated parameters and suppress the escape for them.

I guess it's still a problem if the *same* handle is also passed through a parameter that *cannot* be annotated (eg., as part of a structure passed into the call) and then actually getting released inside the call, but is it a real problem for you?

Dec 10 2019, 2:00 PM · Restricted Project
xazax.hun added a comment to D71224: [analyzer] Escape symbols stored into specific region after a conservative evalcall. .
In D71224#1778179, @NoQ wrote:

In any case, every checker is allowed to make their own decisions about escaping. Escape on its own is not material, it's all about how the checker reacts to escapes. Say, it's up to MallocChecker to decide whether the function may or may not release memory that escapes on call.

I think a valid approach would be to simply look up the function in your CallDescriptionMap and then abort the checkPointerEscape callback when it's found.

Yet, it annoys me a bit that we didn't make everything magically work in an "out of the box" manner. Can we eliminate the first pointer escape (that happens before PostCall) but only keep the secondary escape?

Dec 10 2019, 1:33 PM · Restricted Project
xazax.hun added inline comments to D71224: [analyzer] Escape symbols stored into specific region after a conservative evalcall. .
Dec 10 2019, 12:19 PM · Restricted Project
xazax.hun added inline comments to D71224: [analyzer] Escape symbols stored into specific region after a conservative evalcall. .
Dec 10 2019, 11:51 AM · Restricted Project
xazax.hun added inline comments to D71224: [analyzer] Escape symbols stored into specific region after a conservative evalcall. .
Dec 10 2019, 11:32 AM · Restricted Project
xazax.hun added a comment to D70469: [attributes] [analyzer] Add handle related attributes.
In D70469#1776523, @NoQ wrote:

It still mildly worries me that the attributes aren't truly reusable, as the exact meaning of the attribute depends on the domain. In particular, every domain is expected to have different approaches to error handling, i.e. a function that creates or destroys a handle may fail to, respectively, create or destroy the handle, but instead indicate the failure in a domain-specific manner, eg. through magical return values or null handle or errno or whatever.

@aaron.ballman, do you think this is a problem? Should we rather go for an attribute name that's obviously domain-specific (eg., __attribute__((fuchsia_acquire_handle))), or is it ok to re-use attributes without re-using their exact meaning?

That may be part of why I keep pushing back on this addition -- it seems like these are general purpose attributes that can be used to identify what a handle is and where a handle is obtained/released. Or these could be specific to a particular coding guideline's definition of a handle and associated semantics. If the goal is to only support a limited set of use cases, then I think something like [[clang::fucschia_acquire_handle]] makes more sense. If the goal is to provided general utilities for the static analyzer to reason about handles, then I think we want the more generalized names.

Dec 10 2019, 10:55 AM · Restricted Project
xazax.hun committed rGf3a28202ef58: [analyzer] Keep track of escaped locals (authored by xazax.hun).
[analyzer] Keep track of escaped locals
Dec 10 2019, 8:53 AM
xazax.hun closed D71152: [analyzer] Keep track of escaped locals..
Dec 10 2019, 8:53 AM · Restricted Project

Dec 9 2019

xazax.hun updated the diff for D71224: [analyzer] Escape symbols stored into specific region after a conservative evalcall. .
  • Reuse ExprEngine::escapeValue.
Dec 9 2019, 6:31 PM · Restricted Project
xazax.hun added inline comments to D71224: [analyzer] Escape symbols stored into specific region after a conservative evalcall. .
Dec 9 2019, 5:45 PM · Restricted Project