Skip to content

NeonEmitter.cpp:249: error: ‘TGError’ was not declared in this scope #6188

Closed
Closed
NeonEmitter.cpp:249: error: ‘TGError’ was not declared in this scope#6188

Description

@bdaehlie
bdaehlie
opened on May 2, 2013

When building servo's copy of rust (pretty recent merge) on OS X 10.8:

llvm[5]: Compiling NeonEmitter.cpp for Release+Asserts build
/Users/josh/src/mozilla/bdaehlie-servo/src/rust/src/llvm/tools/clang/utils/TableGen/NeonEmitter.cpp: In function ‘void ParseTypes(llvm::Record_, std::string&, llvm::SmallVectorImplllvm::StringRef&)’:
/Users/josh/src/mozilla/bdaehlie-servo/src/rust/src/llvm/tools/clang/utils/TableGen/NeonEmitter.cpp:249: error: ‘TGError’ was not declared in this scope
/Users/josh/src/mozilla/bdaehlie-servo/src/rust/src/llvm/tools/clang/utils/TableGen/NeonEmitter.cpp: In member function ‘void::NeonEmitter::emitIntrinsic(llvm::raw_ostream&, llvm::Record_)’:
/Users/josh/src/mozilla/bdaehlie-servo/src/rust/src/llvm/tools/clang/utils/TableGen/NeonEmitter.cpp:1384: error: ‘TGError’ was not declared in this scope
/Users/josh/src/mozilla/bdaehlie-servo/src/rust/src/llvm/tools/clang/utils/TableGen/NeonEmitter.cpp: In member function ‘void::NeonEmitter::runHeader(llvm::raw_ostream&)’:
/Users/josh/src/mozilla/bdaehlie-servo/src/rust/src/llvm/tools/clang/utils/TableGen/NeonEmitter.cpp:1459: error: ‘TGError’ was not declared in this scope
/Users/josh/src/mozilla/bdaehlie-servo/src/rust/src/llvm/tools/clang/utils/TableGen/NeonEmitter.cpp:1504: error: ‘TGError’ was not declared in this scope
/Users/josh/src/mozilla/bdaehlie-servo/src/rust/src/llvm/tools/clang/utils/TableGen/NeonEmitter.cpp:1603: error: ‘TGError’ was not declared in this scope
make[5]: *** [/Users/josh/src/mozilla/bdaehlie-servo/build/src/rust/llvm/x86_64-apple-darwin/tools/clang/utils/TableGen/Release+Asserts/NeonEmitter.o] Error 1

Activity

  1. bdaehlie commented on May 2, 2013

    @bdaehlie
    bdaehlie
    on May 2, 2013
    Author

    Seems like TGError was supposed to be in the included file "llvm/TableGen/Record.h", but it's not there.

  2. catamorphism commented on May 2, 2013

    @catamorphism
    catamorphism
    on May 2, 2013
    Contributor

    I've noticed that if I just type make check again after getting this error, the build system happily goes on to build Rust. It should still be fixed, though!

  3. utkarshkukreti commented on May 7, 2013

    @utkarshkukreti
    utkarshkukreti
    on May 7, 2013
    Contributor

    👍 I was getting the same error, and @catamorphism's solution worked for me too.

  4. catamorphism commented on May 27, 2013

    @catamorphism
    catamorphism
    on May 27, 2013
    Contributor

    This is still happening, and should be fixed. Nominating for milestone 5, production-ready. (Though hopefully it'll get fixed sooner!)

  5. acertain commented on Jun 13, 2013

    @acertain
    acertain
    on Jun 13, 2013

    make check doesn't fix it for me.

  6. acertain commented on Jun 18, 2013

    @acertain
    acertain
    on Jun 18, 2013

    Now make check seems to have fixed it...

  7. catamorphism commented on Jul 1, 2013

    @catamorphism
    catamorphism
    on Jul 1, 2013
    Contributor

    Still happening, 040ac2a

  8. catamorphism commented on Aug 16, 2013

    @catamorphism
    catamorphism
    on Aug 16, 2013
    Contributor

    Still an issue as of 680eb71

  9. pkgw commented on Aug 21, 2013

    @pkgw
    pkgw
    on Aug 21, 2013
    Contributor

    Turns out this is due to having stale submodules in a build tree -- fresh checkouts don't even include clang anymore.

    cd ${srcdir}
rm -rf src/llvm/tools/clang
rm -rf src/llvm/projects/compiler-rt # also extraneous, also likely to be present
rm -rf .git/modules/src/llvm/modules
cd ${builddir}
rm -rf llvm/*/tools/clang
rm -rf llvm/*/projects/compiler-rt

    That fixes things up for me.

  10. graydon commented on Aug 22, 2013

    @graydon
    graydon
    on Aug 22, 2013
    Contributor

    just a bug, removing milestone/nomination.

  11. emberian commented on Jan 6, 2014

    @emberian
    emberian
    on Jan 6, 2014
    Contributor

    This still happens sometimes. It's a race in one of the build systems, somewhere.

  12. emberian commented on Jan 6, 2014

    @emberian
    emberian
    on Jan 6, 2014
    Contributor

    Can usually be fixed by rerunning make.

  13. alexcrichton commented on Apr 10, 2014

    @alexcrichton
    alexcrichton
    on Apr 10, 2014
    Member

    Closing, I think that LLVM has long since fixed this, or long since changed. I haven't seen this recently.

  14. alexcrichton
    closed this as completedon Apr 10, 2014
  15. flip1995
    added a commit that references this issue on Dec 20, 2020

    Auto merge of rust-lang#6188 - ebroto:primary_package, r=flip1995

    a2d9925
  16. U007D
    added a commit that references this issue on Aug 21, 2026

    Merge rust-lang#6188

    cde189c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions