Remove tautological #ifdefs

[aprantl]

Summary

These conditions appear to always be true.

@clayborg do you remember the reason why these exist?

[clayborg]

LLDB_CONFIGURATION_BUILD_AND_INTEGRATION doesn't have them. So you can change these to

#if !defined(LLDB_CONFIGURATION_BUILD_AND_INTEGRATION)

[clayborg]

So it affects Apple directly!

[clayborg]

I think we mostly wanted to catch these in the test suite. Probably best to convert to lldbassert

[aprantl]

But I'm sure that LLDB_CONFIGURATION_BUILD_AND_INTEGRATION also defines NDEBUG so the assert should be a noop, right?

[aprantl]

This doesn't apply to DieStack since it isn't an assert, but DieStack is dead code anyway...

[zturner]

Yea it would be nice if we could remove all of the LLDB_CONFIGURATION_xxx macros and just use either the LLVM ones or standard ones such as NDEBUG

[aprantl]

In D58838#1415637, @zturner wrote:

Yea it would be nice if we could remove all of the LLDB_CONFIGURATION_xxx macros and just use either the LLVM ones or standard ones such as NDEBUG

I generally agree with this, but we need to decide what to do on a case-by-case basis. So far I found four categories of LLDB_CONFIGURATION_DEBUG

1. assertions that should just be "assert"
2. expensive checks that should be guarded by LLVM_ENABLE_EXPENSIVE_CHECKS instead
3. Consistency checks that assume that the debug info is 100% accurate/complete and that may fail in the real world
4. additional logging

there may be other cases that I haven't found yet.

[aprantl]

Also I should note that we can only use LLVM defines that are provided by the Xcode project until we reach the point where Apple builds LLDB with CMake and the CMake-generated Xcode file is good enough to replace the hand-written one. This is a transitional restriction, but it's a longer project...

[jingham]

In D58838#1415646, @aprantl wrote:

In D58838#1415637, @zturner wrote:

Yea it would be nice if we could remove all of the LLDB_CONFIGURATION_xxx macros and just use either the LLVM ones or standard ones such as NDEBUG

I generally agree with this, but we need to decide what to do on a case-by-case basis. So far I found four categories of LLDB_CONFIGURATION_DEBUG

1. assertions that should just be "assert"
2. expensive checks that should be guarded by LLVM_ENABLE_EXPENSIVE_CHECKS instead
3. Consistency checks that assume that the debug info is 100% accurate/complete and that may fail in the real world
4. additional logging

there may be other cases that I haven't found yet.

Additional logging should really go through the Verbose version of whatever log channel is appropriate. The additional code won't get run in the normal logging case, so there's no reason to throw it away.

[aprantl]

Removed DIEStack from this patch it distracts.

[aprantl]

Ping. As far as I can tell, now this patch should be entirely NFC.

[davide]

LGTM.

lldb/trunk/source/Target/ExecutionContext.cpp

ExecutionContextScope *ExecutionContext::GetBestExecutionContextScope() const {
   if (m_thread_sp)
     return m_thread_sp.get();
   if (m_process_sp)
     return m_process_sp.get();
   return m_target_sp.get();
 }
 
 Target &ExecutionContext::GetTargetRef() const {
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
   assert(m_target_sp);
-#endif
   return *m_target_sp;
 }
 
 Process &ExecutionContext::GetProcessRef() const {
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
   assert(m_process_sp);
-#endif
   return *m_process_sp;
 }
 
 Thread &ExecutionContext::GetThreadRef() const {
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
   assert(m_thread_sp);
-#endif
   return *m_thread_sp;
 }
 
 StackFrame &ExecutionContext::GetFrameRef() const {
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
   assert(m_frame_sp);
-#endif
   return *m_frame_sp;
 }
 
 void ExecutionContext::SetTargetSP(const lldb::TargetSP &target_sp) {
   m_target_sp = target_sp;
 }
 
 void ExecutionContext::SetProcessSP(const lldb::ProcessSP &process_sp) {