[cfe-commits] [PATCH] Rename

[Zhongxing Xu]

Yeah, it seems a little confusing. But other names are worse:
AbstractVal, too long
AVal, like nonsense.
ProgVal, even farther way.

If ExprVal has to be replaced, I prefer AVal, at least it indicates some
special value: AVal.

On Fri, Oct 17, 2008 at 1:22 PM, Ted Kremenek <kremenek at apple.com> wrote:

>
> On Oct 16, 2008, at 10:15 PM, Zhongxing Xu wrote:
>
>  This is the renaming patch:
>>
>> RVal => ExprVal
>> LVal => Loc
>> NonLVal => NonLoc
>> lval => loc
>> nonlval => nonloc
>> <rename.patch>_______________________________________________
>>
>
> The patch looks great, but I'm a little hesitant about the name "ExprVal."
>  For example, this patch shows "ExprVals" being used with the Store:
>
> +Store BasicStoreManager::SetExprVal(Store store, Loc LV, ExprVal V) {
>   switch (LV.getSubKind()) {
> -    case lval::MemRegionKind: {
> +    case loc::MemRegionKind: {
>       VarRegion* R =
> -        dyn_cast<VarRegion>(cast<lval::MemRegionVal>(LV).getRegion());
> +        dyn_cast<VarRegion>(cast<loc::MemRegionVal>(LV).getRegion());
>
>       if (!R)
>         return store;
> @@ -157,16 +157,16 @@
>         : VBFactory.Add(B, R->getDecl(), V).getRoot();
>     }
>     default:
> -      assert ("SetRVal for given LVal type not yet implemented.");
> +      assert ("SetExprVal for given Loc type not yet implemented.");
>       return store;
>   }
>  }
>
> This just seems confusing.  Why is the store reasoning about "expression
> values"?  It makes sense to those using the system already, but the name
> doesn't capture its purpose well.
>
> What do you think?  AbstractVal?  AVal?  ProgVal?
>
> Otherwise I think the patch looks great.  Changing ExprVal to something
> else is just a couple lines of Perl/sed.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20081017/f2df9c78/attachment.html>