Skip to content
  1. Jul 07, 2009
  2. Jul 06, 2009
  3. Jul 02, 2009
    • Douglas Gregor's avatar
      Add support for retrieving the Doxygen comment associated with a given · c6d5edd2
      Douglas Gregor authored
      declaration in the AST. 
      
      The new ASTContext::getCommentForDecl function searches for a comment
      that is attached to the given declaration, and returns that comment, 
      which may be composed of several comment blocks.
      
      Comments are always available in an AST. However, to avoid harming
      performance, we don't actually parse the comments. Rather, we keep the
      source ranges of all of the comments within a large, sorted vector,
      then lazily extract comments via a binary search in that vector only
      when needed (which never occurs in a "normal" compile).
      
      Comments are written to a precompiled header/AST file as a blob of
      source ranges. That blob is only lazily loaded when one requests a
      comment for a declaration (this never occurs in a "normal" compile). 
      
      The indexer testbed now supports comment extraction. When the
      -point-at location points to a declaration with a Doxygen-style
      comment, the indexer testbed prints the associated comment
      block(s). See test/Index/comments.c for an example.
      
      Some notes:
        - We don't actually attempt to parse the comment blocks themselves,
        beyond identifying them as Doxygen comment blocks to associate them
        with a declaration.
        - We won't find comment blocks that aren't adjacent to the
        declaration, because we start our search based on the location of
        the declaration.
        - We don't go through the necessary hops to find, for example,
        whether some redeclaration of a declaration has comments when our
        current declaration does not. Similarly, we don't attempt to
        associate a \param Foo marker in a function body comment with the
        parameter named Foo (although that is certainly possible).
        - Verification of my "no performance impact" claims is still "to be
        done".
      
      llvm-svn: 74704
      c6d5edd2
    • Douglas Gregor's avatar
      Fix PR 4489, a PCH crash during de-serialization. · e4d00dd7
      Douglas Gregor authored
      llvm-svn: 74664
      e4d00dd7
    • Owen Anderson's avatar
      ecaeaa81
  4. Jul 01, 2009
  5. Jun 30, 2009
  6. Jun 29, 2009
  7. Jun 28, 2009
  8. Jun 26, 2009
    • Anders Carlsson's avatar
      082acded
    • Nate Begeman's avatar
      OpenCL 1.0 support: attributes · f2758700
      Nate Begeman authored
      llvm-svn: 74280
      f2758700
    • Ted Kremenek's avatar
      Introduce a new concept to the static analyzer: SValuator. · 1642bdaa
      Ted Kremenek authored
      GRTransferFuncs had the conflated role of both constructing SVals (symbolic
      expressions) as well as handling checker-specific logic. Now SValuator has the
      role of constructing SVals from expressions and GRTransferFuncs just handles
      checker-specific logic. The motivation is by separating these two concepts we
      will be able to much more easily create richer constraint-generating logic
      without coupling it to the main checker transfer function logic.
      
      We now have one implementation of SValuator: SimpleSValuator.
      
      SimpleSValuator is essentially the SVal-related logic that was in GRSimpleVals
      (which is removed in this patch). This includes the logic for EvalBinOp,
      EvalCast, etc. Because SValuator has a narrower role than the old
      GRTransferFuncs, the interfaces are much simpler, and so is the implementation
      of SimpleSValuator compared to GRSimpleVals. I also did a line-by-line review of
      SVal-related logic in GRSimpleVals and cleaned it up while moving it over to
      SimpleSValuator.
      
      As a consequence of removing GRSimpleVals, there is no longer a
      '-checker-simple' option. The '-checker-cfref' did everything that option did
      but also ran the retain/release checker. Of course a user may not always wish to
      run the retain/release checker, nor do we wish core analysis logic buried in the
      checker-specific logic. The next step is to refactor the logic in CFRefCount.cpp
      to separate out these pieces into the core analysis engine.
      
      llvm-svn: 74229
      1642bdaa
    • Nate Begeman's avatar
      Write/Read new Language Options · f2911667
      Nate Begeman authored
      llvm-svn: 74221
      f2911667
    • Nate Begeman's avatar
      PCH support for OpenCL language options · 9d90579b
      Nate Begeman authored
      llvm-svn: 74220
      9d90579b
  9. Jun 25, 2009
  10. Jun 24, 2009
  11. Jun 23, 2009
  12. Jun 20, 2009
Loading