Linux build errors

I’m running into build errors at current top of tree (r193132). Anyone else seeing these?

/home/mikesart/data/src/llvm.git/llvm/tools/lldb/source/Expression/IRForTarget.cpp:364:33: error: expected a class or namespace

if (fun->hasFnAttribute(Attribute::NoBuiltin)) {
^
/home/mikesart/data/src/llvm.git/llvm/tools/lldb/source/Expression/IRForTarget.cpp:364:33: error: reference to ‘Attribute’ is ambiguous
if (fun->hasFnAttribute(Attribute::NoBuiltin)) {
^
/home/mikesart/data/src/llvm.git/llvm/include/llvm/Support/Dwarf.h:144:6: note: candidate found by name lookup is ‘llvm::dwarf::Attribute’
enum Attribute LLVM_ENUM_INT_TYPE(uint16_t) {
^
/home/mikesart/data/src/llvm.git/llvm/include/llvm/IR/Attributes.h:45:7: note: candidate found by name lookup is ‘llvm::Attribute’
class Attribute {
^
/home/mikesart/data/src/llvm.git/llvm/tools/lldb/source/Expression/IRForTarget.cpp:365:13: error: reference to ‘Attribute’ is ambiguous
Attribute builtin = Attribute::get(fun->getContext(), Attribute::Builtin);
^
/home/mikesart/data/src/llvm.git/llvm/include/llvm/Support/Dwarf.h:144:6: note: candidate found by name lookup is ‘llvm::dwarf::Attribute’
enum Attribute LLVM_ENUM_INT_TYPE(uint16_t) {
^
/home/mikesart/data/src/llvm.git/llvm/include/llvm/IR/Attributes.h:45:7: note: candidate found by name lookup is ‘llvm::Attribute’
class Attribute {
^
/home/mikesart/data/src/llvm.git/llvm/tools/lldb/source/Expression/IRForTarget.cpp:369:72: error: use of undeclared identifier ‘builtin’
call->removeAttribute(AttributeSet::FunctionIndex, builtin);
^
4 errors generated.

I can fix the errors by explicitly using the llvm namespace on Attribute. Ie:

diff --git a/source/Expression/IRForTarget.cpp b/source/Expression/IRForTarget.cpp
index cac3fdf…4d14ebd 100644
— a/source/Expression/IRForTarget.cpp
+++ b/source/Expression/IRForTarget.cpp
@@ -361,8 +361,8 @@ IRForTarget::ResolveFunctionPointers(llvm::Module &llvm_module)
// be called with the builtin attribute on call sites. Remove any such
// attributes since it’s illegal to have a builtin call to something
// other than a nobuiltin function.

  • if (fun->hasFnAttribute(Attribute::NoBuiltin)) {
  • Attribute builtin = Attribute::get(fun->getContext(), Attribute::Builtin);
  • if (fun->hasFnAttribute(llvm::Attribute::NoBuiltin)) {
  • llvm::Attribute builtin = llvm::Attribute::get(fun->getContext(), llvm::Attribute::Builtin);

for (auto u = fun->use_begin(), e = fun->use_end(); u != e; ++u) {
if (auto call = dyn_cast(*u)) {

My compiler version:

mikesart@mikesart-rad:~/data/src/llvm.git/build$ g++ --version
clang version 3.3 (tags/RELEASE_33/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix

Thanks.
-Mike

Yes, after updating llvm from 193083 to 193137 I see this when
building lldb as well. It looks like it's r193091.

It builds for me with this change:

diff --git a/source/Expression/IRForTarget.cpp
b/source/Expression/IRForTarget.cpp
index cac3fdf..4d14ebd 100644
--- a/source/Expression/IRForTarget.cpp
+++ b/source/Expression/IRForTarget.cpp
@@ -361,8 +361,8 @@ IRForTarget::ResolveFunctionPointers(llvm::Module
&llvm_module)
         // be called with the builtin attribute on call sites. Remove any such
         // attributes since it's illegal to have a builtin call to something
         // other than a nobuiltin function.
- if (fun->hasFnAttribute(Attribute::NoBuiltin)) {
- Attribute builtin = Attribute::get(fun->getContext(),
Attribute::Builtin);
+ if (fun->hasFnAttribute(llvm::Attribute::NoBuiltin)) {
+ llvm::Attribute builtin =
llvm::Attribute::get(fun->getContext(), llvm::Attribute::Builtin);

             for (auto u = fun->use_begin(), e = fun->use_end(); u != e; ++u) {
                 if (auto call = dyn_cast<CallInst>(*u)) {

Ah - sorry for the breakage (didn’t see this on any bots). Most/all of the LLVM debug code never brings in the ‘dwarf’ namespace, I guess you’ve got some code that does. Probably better to remove the ‘using namespace dwarf’ and add a few ‘dwarf::’ around the place, rather than adding ‘llvm::’, but whichever way suits your coding conventions/styles should address the issue.

Thanks David, Ed, Michael. I committed the simple fix for now - it's probably best for Sean to decide about not using the dwarf namespace in this file.