[PATCH] D102277: [llvm-objcopy][NFC] Refactor CopyConfig structure - categorize options.
Alexey Lapshin via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri May 14 04:29:15 PDT 2021
avl added inline comments.
================
Comment at: llvm/tools/llvm-objcopy/ConfigManager.cpp:561
const uint8_t Invalid = 0xff;
- ResConfig.NewSymbolVisibility =
+ const_cast<ConfigManager *>(this)->ELF.NewSymbolVisibility =
StringSwitch<uint8_t>(*NewSymbolVisibility)
----------------
jhenderson wrote:
> `const_cast` is always a bit scary to me. Would it make more sense to make `NewSymbolVisibility` and `SymbolsToAdd` mutable in the ELFConfig?
using mutable inside ELFConfig will allow to change the fields by consumer:
```
struct ELFConfig {
mutable uint8_t NewSymbolVisibility;
};
void consumer (const ELFConfig& ELFConfig ) {
ELFConfig.NewSymbolVisibility = STV_HIDDEN; // <<<<< incorrect usage
}
```
That would be not proper usage. The ConfigManager::getELFConfig() uses lazy initialization pattern. It is usually OK to use const_cast for lazy initialization. it is used in other places too:
llvm/CodeGen/ScheduleDAG.h
```
unsigned getDepth() const {
if (!isDepthCurrent)
const_cast<SUnit *>(this)->ComputeDepth();
return Depth;
}
```
So I think it is better to not use mutable inside ELFConfig.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D102277/new/
https://reviews.llvm.org/D102277
More information about the llvm-commits
mailing list