Skip to content
  1. Dec 20, 2011
    • Richard Smith's avatar
      Unlike in C++03, a constant-expression is not an unevaluated operand in C++11. · 764d2fe6
      Richard Smith authored
      Split out a new ExpressionEvaluationContext flag for this case, and don't treat
      it as unevaluated in C++11. This fixes some crash-on-invalids where we would
      allow references to class members in potentially-evaluated constant expressions
      in static member functions, and also fixes half of PR10177.
      
      The fix to PR10177 exposed a case where template instantiation failed to provide
      a source location for a diagnostic, so TreeTransform has been tweaked to supply
      source locations when transforming a type. The source location is still not very
      good, but MarkDeclarationsReferencedInType would need to operate on a TypeLoc to
      improve it further.
      
      Also fix MarkDeclarationReferenced in C++98 mode to trigger instantiation for
      static data members of class templates which are used in constant expressions.
      This fixes a link-time problem, but we still incorrectly treat the member as
      non-constant. The rest of the fix for that issue is blocked on PCH support for
      early-instantiated static data members, which will be added in a subsequent
      patch.
      
      llvm-svn: 146955
      764d2fe6
  2. Dec 19, 2011
    • Richard Smith's avatar
      constexpr handling improvements. Produce detailed diagnostics when a 'constexpr' · d0b4dd65
      Richard Smith authored
      variable is initialized by a non-constant expression, and pass in the variable
      being declared so that earlier-initialized fields' values can be used.
      
      Rearrange VarDecl init evaluation to make this possible, and in so doing fix a
      long-standing issue in our C++ constant expression handling, where we would
      mishandle cases like:
      
        extern const int a;
        const int n = a;
        const int a = 5;
        int arr[n];
      
      Here, n is not initialized by a constant expression, so can't be used in an ICE,
      even though the initialization expression would be an ICE if it appeared later
      in the TU. This requires computing whether the initializer is an ICE eagerly,
      and saving that information in PCH files.
      
      llvm-svn: 146856
      d0b4dd65
  3. Dec 18, 2011
    • Benjamin Kramer's avatar
      Silence gcc warnings. · 198e0836
      Benjamin Kramer authored
      llvm-svn: 146847
      198e0836
    • Douglas Gregor's avatar
      Completely re-implement (de-)serialization of declaration · 05f10357
      Douglas Gregor authored
      chains. The previous implementation relied heavily on the declaration
      chain being stored as a (circular) linked list on disk, as it is in
      memory. However, when deserializing from multiple modules, the
      different chains could get mixed up, leading to broken declaration chains.
      
      The new solution keeps track of the first and last declarations in the
      chain for each module file. When we load a declaration, we search all
      of the module files for redeclarations of that declaration, then
      splice together all of the lists into a coherent whole (along with any
      redeclarations that were actually parsed). 
      
      As a drive-by fix, (de-)serialize the redeclaration chains of
      TypedefNameDecls, which had somehow gotten missed previously. Add a
      test of this serialization.
      
      This new scheme creates a redeclaration table that is fairly large in
      the PCH file (on the order of 400k for Cocoa.h's 12MB PCH file). The
      table is mmap'd in and searched via a binary search, but it's still
      quite large. A future tweak will eliminate entries for declarations
      that have no redeclarations anywhere, and should
      drastically reduce the size of this table.
      
      llvm-svn: 146841
      05f10357
  4. Dec 17, 2011
  5. Dec 16, 2011
  6. Dec 15, 2011
  7. Dec 14, 2011
  8. Dec 13, 2011
  9. Dec 12, 2011
  10. Dec 10, 2011
  11. Dec 09, 2011
    • Richard Smith's avatar
      C++11 constant expressions: Don't use CheckICE in C++11; instead, determine · f57d8cb1
      Richard Smith authored
      whether an expression is a (core) constant expression as a side-effect of
      evaluation. This takes us from accepting far too few expressions as ICEs to
      accepting slightly too many -- fixes for the remaining cases are coming next.
      
      The diagnostics produced when an expression is found to be non-constant are
      currently quite poor (with generic wording but reasonable source locations),
      and will be improved in subsequent commits.
      
      llvm-svn: 146289
      f57d8cb1
Loading