https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/71039
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/71039
>From 8f16d3000a91df33d416dd09381175ddeb7e5ed3 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Sat, 4 Nov 2023 15:25:42 +0100
Subject: [PATCH] [analyzer][NFC] Rework SVal kind representation
The goal of this
https://github.com/Xazax-hun approved this pull request.
https://github.com/llvm/llvm-project/pull/71039
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Endilll wrote:
> What other ways are to make a const void * debugger-friendly - other than
> llvm::PointerUnion?
I'm not aware of any that wouldn't require writing a custom formatter.
Ultimately it boils to how can I extract type information. For
`llvm::PointerUnion` I'm matching discriminato
steakhal wrote:
> But I have to point out that this patch doesn't address the fact that `const
> void* Data` is not friendly to debuggers, especially with type information
> encoded in another member. So even with this patch applied, someone would
> still have to write (and maintain) a custom
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/71039
>From 3bc43ab005aa76a43644d4d93286215b490cc8fa Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Thu, 2 Nov 2023 10:21:03 +0100
Subject: [PATCH 1/2] [analyzer][NFC] Rework SVal kind representation
The goal of
https://github.com/Endilll approved this pull request.
https://github.com/llvm/llvm-project/pull/71039
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Endilll wrote:
> I've considered this but I found the number of alternatives too large to make
> it feasible. Consider that we have 11 possible SValKinds, which would require
> 4 bits to encode. Requiring all Data pointers to be aligned as such seems
> rough - although not impossible.
Sorry,
steakhal wrote:
> But I have to point out that this patch doesn't address the fact that `const
> void* Data` is not friendly to debuggers, especially with type information
> encoded in another member. So even with this patch applied, someone would
> still have to write (and maintain) a custom
@@ -105,38 +86,25 @@ class SVal {
return llvm::dyn_cast(*this);
}
- unsigned getRawKind() const { return Kind; }
- BaseKind getBaseKind() const { return (BaseKind) (Kind & BaseMask); }
- unsigned getSubKind() const { return Kind >> BaseBits; }
+ SValKind getKind() co
https://github.com/Endilll commented:
Converting packed `unsigned Kind` into non-packed `SValKind Kind` is definitely
going to help debuggers to display the value correctly.
But I have to point out that this patch doesn't address the fact that `const
void* Data` is not friendly to debuggers, e
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/71039
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
This PR relates to #69835
([comment](https://github.com/llvm/llvm-project/issues/69835#issuecomment-1775533393)).
https://github.com/llvm/llvm-project/pull/71039
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llv
llvmbot wrote:
@llvm/pr-subscribers-clang-static-analyzer-1
Author: Balazs Benics (steakhal)
Changes
The goal of this patch is to refine how the `SVal` base and sub-kinds are
represented by forming one unified enum describing the possible SVals. This
means that the `unsigned SVal::Kind`
https://github.com/steakhal created
https://github.com/llvm/llvm-project/pull/71039
The goal of this patch is to refine how the `SVal` base and sub-kinds are
represented by forming one unified enum describing the possible SVals. This
means that the `unsigned SVal::Kind` and the attached bit-pa
15 matches
Mail list logo
