This is an archive of the discontinued LLVM Phabricator instance.

[Sema] Propagate nullability when deducing type of auto
AbandonedPublic

Authored by ahatanak on Jul 25 2016, 6:59 PM.

Details

Reviewers
doug.gregor
Summary

This patch fixes Sema to propagate the nullability of the initializer expression of a variable declared with auto or __auto_type to the deduced type. The patch consists of two parts:

  • Define function QualType::setNullability, which is used to return a QualType with the specified nullability, and use it in computeConditionalNullability.
  • Propagate nullability when type of auto is being deduced.

rdar://problem/27062504

Diff Detail

Event Timeline

ahatanak updated this revision to Diff 65460.Jul 25 2016, 6:59 PM
ahatanak retitled this revision from to [Sema] Propagate nullability when deducing type of auto.
ahatanak updated this object.
ahatanak added a reviewer: doug.gregor.
ahatanak added a subscriber: cfe-commits.
manmanren added inline comments.
lib/Sema/SemaDecl.cpp
9739

Do we propagate other attributes for deduced types?

rsmith added a subscriber: rsmith.Aug 15 2016, 5:33 PM

Is this really a good idea? If I write:

int *_Nullable f();
int n;
int *_Nonnull g() {
  auto *p = f();
  if (!p) p = &n;
  return p;
}

... it would be wrong to produce a warning that I'm converting from a nullable pointer to a non-nullable pointer.

I didn't think of this case, but no, it isn't a good idea. We shouldn't issue a warning unless we know the returned pointer is nullable.

lib/Sema/SemaDecl.cpp
9739

QualType::setNullability can drop attributes on typedefs because it desugars the type until all nullability specifiers are stripped. I didn't try very hard to make sure QualType::setNullability preserve all the attributes because I couldn't come up with a case where dropping an attribute attached to a typedef for a pointer type would cause clang to mis-compile or issue a wrong diagnostic, so I thought it was safe.

ahatanak abandoned this revision.Aug 25 2016, 4:52 PM

Abandoning this revision.

It looks like we cannot correctly implement this warning without introducing a lot of complexity to clang. Users can use the static analyzer instead as it already warns about this case.