Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
1 result
Search by author
  • Any Author
  • Dr. Jorrit Fahlke Dr. Jorrit Fahlke jfahl_01
  • Jan Hönig hoenig
  • Marcel Dominique Koch marckoch
  • Martin Bauer bauermar
  • Michael Haidl m_haid02
  • Prof. Dr. Christian Engwer Prof. Dr. Christian Engwer cengw_01
  • René Heß hessr
  • Vladyslav Kucher kucher
8 authors
  1. Jun 22, 2015
  3. Jun 20, 2015
  5. Jun 19, 2015
  7. Jun 18, 2015
  9. Jun 15, 2015
  11. Jun 13, 2015
    • Rafael Espindola's avatar
      Don't use std::errc. · fdf3e453
      Rafael Espindola authored 
      As noted on Errc.h:

// * std::errc is just marked with is_error_condition_enum. This means that
//   common patters like AnErrorCode == errc::no_such_file_or_directory take
//   4 virtual calls instead of two comparisons.

And on some libstdc++ those virtual functions conclude that

------------------------
int main() {
  std::error_code foo = std::make_error_code(std::errc::no_such_file_or_directory);
  return foo == std::errc::no_such_file_or_directory;
}
-------------------------

should exit with 0.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239684 91177308-0d34-0410-b5e6-96231b3b80d8
      fdf3e453
  13. Jun 10, 2015
  15. Jun 04, 2015
  17. Jun 03, 2015
  19. May 29, 2015
    • Benjamin Kramer's avatar
      Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial types · b7b56528
      Benjamin Kramer authored 
      If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.


Call sites were found with the ASTMatcher + some semi-automated cleanup.

memberCallExpr(
    argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
    on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
    hasArgument(0, bindTemporaryExpr(
                       hasType(recordDecl(hasNonTrivialDestructor())),
                       has(constructExpr()))),
    unless(isInTemplateInstantiation()))

No functional change intended.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238601 91177308-0d34-0410-b5e6-96231b3b80d8
      b7b56528
  21. Apr 17, 2015
  23. Apr 14, 2015
  25. Apr 11, 2015
  27. Apr 10, 2015
  29. Mar 30, 2015
    • Jordan Rose's avatar
      [analyzer] Disable all retain count diagnostics on values that come from ivars. · 08f11c43
      Jordan Rose authored 
      This is imitating a pre-r228174 state where ivars are not considered tracked by
default, but with the addition that even ivars /with/ retain count information
(e.g. "[_ivar retain]; [ivar _release];") are not being tracked as well. This is
to ensure that we don't regress on values accessed through both properties and
ivars, which is what r228174 was trying to fix.

The issue occurs in code like this:

  [_contentView retain];
  [_contentView removeFromSuperview];
  [self addSubview:_contentView]; // invalidates 'self'
  [_contentView release];

In this case, the call to -addSubview: may change the value of self->_contentView,
and so the analyzer can't be sure that we didn't leak the original _contentView.
This is a correct conservative view of the world, but not a useful one. Until we
have a heuristic that allows us to not consider this a leak, not emitting a
diagnostic is our best bet.

This commit disables all of the ivar-related retain count tests, but does not
remove them to ensure that we don't crash trying to evaluate either valid or
erroneous code. The next commit will add a new test for the example above so
that this commit (and the previous one) can be reverted wholesale when a better
solution is implemented.

Rest of rdar://problem/20335433

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233592 91177308-0d34-0410-b5e6-96231b3b80d8
      08f11c43
    • Jordan Rose's avatar
      [analyzer] Don't special-case ivars backing +0 properties. · 9ad2cb71
      Jordan Rose authored 
      Give up this checking in order to continue tracking that these values came from
direct ivar access, which will be important in the next commit.

Part of rdar://problem/20335433

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233591 91177308-0d34-0410-b5e6-96231b3b80d8
      9ad2cb71
  31. Mar 24, 2015
  33. Mar 22, 2015
  35. Mar 20, 2015
  37. Mar 18, 2015
  39. Mar 14, 2015
    • Benjamin Kramer's avatar
      [analyzer] Sort path diagnostics with array_pod_sort. · bf16b27d
      Benjamin Kramer authored 
      They're expensive to compare and we won't sort many of them so std::sort
doesn't give any benefits and causes code bloat. Func fact: clang -O3 didn't
even bother to inline libc++'s std::sort here.

While there validate the predicate a bit harder, the sort is unstable and we
don't want to introduce any non-determinism. I had to spell out the function
pointer type because GCC 4.7 still fails to convert the lambda to a function
pointer :(

No intended functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232263 91177308-0d34-0410-b5e6-96231b3b80d8
      bf16b27d
  41. Mar 11, 2015
  43. Mar 10, 2015
  45. Mar 09, 2015
  47. Mar 07, 2015
  49. Mar 05, 2015
  51. Mar 04, 2015
  53. Mar 03, 2015
  55. Feb 25, 2015
  57. Feb 20, 2015
  59. Feb 19, 2015
    • Anton Yartsev's avatar
      [analyzer] Different handling of alloca(). · 5f432847
      Anton Yartsev authored 
      + separate bug report for "Free alloca()" error to be able to customize checkers responsible for this error.
+ Muted "Free alloca()" error for NewDelete checker that is not responsible for c-allocated memory, turned on for unix.MismatchedDeallocator checker.
+ RefState for alloca() - to be able to detect usage of zero-allocated memory by upcoming ZeroAllocDereference checker.
+ AF_Alloca family to handle alloca() consistently - keep proper family in RefState, handle 'alloca' by getCheckIfTracked() facility, etc.
+ extra tests.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229850 91177308-0d34-0410-b5e6-96231b3b80d8
      5f432847
  61. Feb 18, 2015
  63. Feb 17, 2015