Upon reflection, I don't think this is the right approach.
Desugaring any AttributedType in the return type seems like a really, really big hammer and could be an unexpected surprise for future attributed types where this is not the right behavior. I think a better approach for the nullability issue would be to update lookThroughImplicitCasts() in NullabilityChecker.cpp to look though ExprWithCleanups expressions just like it currently does for implicit casts.
What do you think?
Oct 4 2016
Sep 28 2016
I tried to commit by using arc, though it didn't work as I was prompted to login into the subversion-repository, which I can't. At this point I'm not sure if this should have worked or not, but I assumed that arc + phabricator would handle it in a way that i wouldn't need write-access to the repository itself.
So, yes, it would be nice when someone can actually commit it for me.
Sep 24 2016
Uhm, is there something missing from my side that i have overseen to go forward with this patch?
Aug 23 2016
If this patch is applied, does clang issue a warning if a method marked "nonnull" returns a null value? I see a warning is issued for conditional expressions in the test case you've added, but I don't see a test case for a function returning just nil or 0.
I was wondering whether the change made in this patch contradicts what's stated in r240146's commit log:
"Note that we don't warn about nil returns from Objective-C methods,because it's common for Objective-C methods to mimic the nil-swallowing behavior of the receiver by checking ostensibly non-null parameters and returning nil from otherwise non-null methods in that case."
Aug 6 2016
Nov 25 2014
Oh, great! Thanks for adapting it that it will (hopefully) don't cause any more problems on windows!
Nov 22 2014
So, what's the status? Anything wrong with it / anything I can do?
Nov 4 2014
Glad that my patch got accepted, thanks!
Well, as I have no commit access I thought that someone might apply that patch by himself - or that there is a magic mechanism that would have allowed me to commit the patch by using arcanist. Apparently, both assumptions seem to be wrong - may somebody apply that patch to the tree?
Oct 31 2014
- Reverted the changes in PreprocessorOptions.h
- Updated the descriptions of the added matchers (added the dots and updated the matcher-names in their descriptions, which i forgot before)
- Renamed isInSystemHeader to isExpansionInSystemHeader
Oct 26 2014
isExpansionInMainFile and isExpansionInFileMatching - sounds reasonable :)
I'm going with FileContentMappings for now, but feel free to change anytime - I'm not enthusiastic about names.
I included Tooling.h in PreprocessorOptions.h to have access to the new typedef FileContentMappings. It feels kinda heavy to add that include for one typedef only. Furthermore, I'm unsure how to update the description of the RemappedFiles, as it directly relates to the std::pair that is now no longer visible in the typename. In my eyes, the usage of std::pair now becomes to an implementation-detail that should not be exposed in the comment, so i removed these mentions.
Oct 18 2014
I updated it accordingly to the comments (thanks!).
One of the changes is the replacement of an initializer list through an explicit call to the default-constructor of std::vector<std::pair<std::string, std::string>>, to initialize the new introduced VirtualMappedFiles-parameter of the functions runToolOnCodeWithArgs and matchesConditionally. Due to the repeated usage of the type-declaration, it would be nice to declare a typedef for std::vector<std::pair<std::string, std::string>>, that could also be used for the RemappedFiles-instance-variable of the class PreprocessorOptions.
If it is appropriate to add the typedef, where should I add it and how should I name it?