maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/DataFormatters/FormatCache.cpp

298 lines
6.0 KiB
C++
Raw Normal View History

<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
//===-- FormatCache.cpp ------------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
Fix clang warnings related to python macro redefinition and printf format specifiers. llvm-svn: 175829
2013-02-22 07:55:31 +08:00
#include "lldb/lldb-python.h"
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
// C Includes
// C++ Includes
// Other libraries and framework includes
// Project includes
#include "lldb/DataFormatters/FormatCache.h"
using namespace lldb;
using namespace lldb_private;
FormatCache::Entry::Entry () :
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
m_format_cached(false),
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
m_summary_cached(false),
m_synthetic_cached(false),
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
m_validator_cached(false),
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
m_format_sp(),
Fix build problems with libstdc++ 4.6/4.7 - remove nullptr from initialization of shared_ptrs llvm-svn: 173870
2013-01-30 09:01:11 +08:00
m_summary_sp(),
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
m_synthetic_sp(),
m_validator_sp()
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
{}
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
FormatCache::Entry::Entry (lldb::TypeFormatImplSP format_sp) :
m_summary_cached(false),
m_synthetic_cached(false),
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
m_validator_cached(false),
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
m_summary_sp(),
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
m_synthetic_sp(),
m_validator_sp()
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
{
SetFormat (format_sp);
}
Fix GCC 4.6 build by avoiding delegating ctors Patch by Abid Hafiz! llvm-svn: 174519
2013-02-07 00:46:40 +08:00
FormatCache::Entry::Entry (lldb::TypeSummaryImplSP summary_sp) :
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
m_format_cached(false),
Fix GCC 4.6 build by avoiding delegating ctors Patch by Abid Hafiz! llvm-svn: 174519
2013-02-07 00:46:40 +08:00
m_synthetic_cached(false),
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
m_validator_cached(false),
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
m_format_sp(),
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
m_synthetic_sp(),
m_validator_sp()
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
{
SetSummary (summary_sp);
}
Fix GCC 4.6 build by avoiding delegating ctors Patch by Abid Hafiz! llvm-svn: 174519
2013-02-07 00:46:40 +08:00
FormatCache::Entry::Entry (lldb::SyntheticChildrenSP synthetic_sp) :
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
m_format_cached(false),
Fix GCC 4.6 build by avoiding delegating ctors Patch by Abid Hafiz! llvm-svn: 174519
2013-02-07 00:46:40 +08:00
m_summary_cached(false),
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
m_validator_cached(false),
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
m_format_sp(),
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
m_summary_sp(),
m_validator_sp()
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
{
SetSynthetic (synthetic_sp);
}
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
FormatCache::Entry::Entry (lldb::TypeValidatorImplSP validator_sp) :
m_format_cached(false),
m_summary_cached(false),
m_synthetic_cached(false),
m_format_sp(),
m_summary_sp(),
m_synthetic_sp()
{
SetValidator (validator_sp);
}
FormatCache::Entry::Entry (lldb::TypeFormatImplSP format_sp, lldb::TypeSummaryImplSP summary_sp, lldb::SyntheticChildrenSP synthetic_sp, lldb::TypeValidatorImplSP validator_sp)
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
{
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
SetFormat (format_sp);
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
SetSummary (summary_sp);
SetSynthetic (synthetic_sp);
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
SetValidator (validator_sp);
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
}
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
bool
FormatCache::Entry::IsFormatCached ()
{
return m_format_cached;
}
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
bool
FormatCache::Entry::IsSummaryCached ()
{
return m_summary_cached;
}
bool
FormatCache::Entry::IsSyntheticCached ()
{
return m_synthetic_cached;
}
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
bool
FormatCache::Entry::IsValidatorCached ()
{
return m_validator_cached;
}
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
lldb::TypeFormatImplSP
FormatCache::Entry::GetFormat ()
{
return m_format_sp;
}
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
lldb::TypeSummaryImplSP
FormatCache::Entry::GetSummary ()
{
return m_summary_sp;
}
lldb::SyntheticChildrenSP
FormatCache::Entry::GetSynthetic ()
{
return m_synthetic_sp;
}
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
lldb::TypeValidatorImplSP
FormatCache::Entry::GetValidator ()
{
return m_validator_sp;
}
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
void
FormatCache::Entry::SetFormat (lldb::TypeFormatImplSP format_sp)
{
m_format_cached = true;
m_format_sp = format_sp;
}
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
void
FormatCache::Entry::SetSummary (lldb::TypeSummaryImplSP summary_sp)
{
m_summary_cached = true;
m_summary_sp = summary_sp;
}
void
FormatCache::Entry::SetSynthetic (lldb::SyntheticChildrenSP synthetic_sp)
{
m_synthetic_cached = true;
m_synthetic_sp = synthetic_sp;
}
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
void
FormatCache::Entry::SetValidator (lldb::TypeValidatorImplSP validator_sp)
{
m_validator_cached = true;
m_validator_sp = validator_sp;
}
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
FormatCache::FormatCache () :
m_map(),
m_mutex (Mutex::eMutexTypeRecursive)
#ifdef LLDB_CONFIGURATION_DEBUG
,m_cache_hits(0),m_cache_misses(0)
#endif
{
}
FormatCache::Entry&
FormatCache::GetEntry (const ConstString& type)
{
auto i = m_map.find(type),
e = m_map.end();
if (i != e)
return i->second;
m_map[type] = FormatCache::Entry();
return m_map[type];
}
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
bool
FormatCache::GetFormat (const ConstString& type,lldb::TypeFormatImplSP& format_sp)
{
Mutex::Locker lock(m_mutex);
auto entry = GetEntry(type);
if (entry.IsSummaryCached())
{
#ifdef LLDB_CONFIGURATION_DEBUG
m_cache_hits++;
#endif
format_sp = entry.GetFormat();
return true;
}
#ifdef LLDB_CONFIGURATION_DEBUG
m_cache_misses++;
#endif
format_sp.reset();
return false;
}
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
bool
FormatCache::GetSummary (const ConstString& type,lldb::TypeSummaryImplSP& summary_sp)
{
Mutex::Locker lock(m_mutex);
auto entry = GetEntry(type);
if (entry.IsSummaryCached())
{
#ifdef LLDB_CONFIGURATION_DEBUG
m_cache_hits++;
#endif
summary_sp = entry.GetSummary();
return true;
}
#ifdef LLDB_CONFIGURATION_DEBUG
m_cache_misses++;
#endif
summary_sp.reset();
return false;
}
bool
FormatCache::GetSynthetic (const ConstString& type,lldb::SyntheticChildrenSP& synthetic_sp)
{
Mutex::Locker lock(m_mutex);
auto entry = GetEntry(type);
if (entry.IsSyntheticCached())
{
#ifdef LLDB_CONFIGURATION_DEBUG
m_cache_hits++;
#endif
synthetic_sp = entry.GetSynthetic();
return true;
}
#ifdef LLDB_CONFIGURATION_DEBUG
m_cache_misses++;
#endif
synthetic_sp.reset();
return false;
}
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
bool
FormatCache::GetValidator (const ConstString& type,lldb::TypeValidatorImplSP& validator_sp)
{
Mutex::Locker lock(m_mutex);
auto entry = GetEntry(type);
if (entry.IsValidatorCached())
{
#ifdef LLDB_CONFIGURATION_DEBUG
m_cache_hits++;
#endif
validator_sp = entry.GetValidator();
return true;
}
#ifdef LLDB_CONFIGURATION_DEBUG
m_cache_misses++;
#endif
validator_sp.reset();
return false;
}
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
void
FormatCache::SetFormat (const ConstString& type,lldb::TypeFormatImplSP& format_sp)
{
Mutex::Locker lock(m_mutex);
GetEntry(type).SetFormat(format_sp);
}
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
void
FormatCache::SetSummary (const ConstString& type,lldb::TypeSummaryImplSP& summary_sp)
{
Mutex::Locker lock(m_mutex);
GetEntry(type).SetSummary(summary_sp);
}
void
FormatCache::SetSynthetic (const ConstString& type,lldb::SyntheticChildrenSP& synthetic_sp)
{
Mutex::Locker lock(m_mutex);
GetEntry(type).SetSynthetic(synthetic_sp);
}
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
void
FormatCache::SetValidator (const ConstString& type,lldb::TypeValidatorImplSP& validator_sp)
{
Mutex::Locker lock(m_mutex);
GetEntry(type).SetValidator(validator_sp);
}
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
void
FormatCache::Clear ()
{
Mutex::Locker lock(m_mutex);
m_map.clear();
}