Details
- Reviewers
ilya-biryukov rsmith
Diff Detail
- Repository
- rC Clang
- Build Status
Buildable 23944 Build 23943: arc lint + arc unit
Event Timeline
Can you give a bit more background on what problem you're trying to solve with this patch?
lib/Sema/SemaChecking.cpp | ||
---|---|---|
852 ↗ | (On Diff #167718) | I'm not certain I understand why this code has been removed? |
lib/Sema/SemaDecl.cpp | ||
10772 | Why does this need to return a pair? It seems like the returned TypeSourceInfo* carries all the information needed by the caller, or is there ever a case where the QualType will be different than what is returned by TypeSourceInfo::getType()? |
Sorry for the lack of context, it was about an offline discussion on Sema::DeduceVariableDeclarationType just setting the type and not setting the typesourceinfo, which was resulting in having DeducedType in type but not in typesourceinfo.
We wanted to fix that behavior because it was resulting in getting "auto"s when we look at typesourceinfo(which happens in astprinter). But then it turned out to be there are other parts of clang(including extra tools) that depend on typesourceinfo not having the deduced type, for example include-fixer and refactoring/rename, relied on that information being missing when they were looking for (usage counts/locations) of symbols they were looking for.
So in the middle of the patch we were just trying to figure out whether we are going to break a big assumption that lots of different components relied on but just didn't had any tests for. Maybe @rsmith would have more context about the behavior?
lib/Sema/SemaChecking.cpp | ||
---|---|---|
852 ↗ | (On Diff #167718) | It shouldn't have been, tried rebasing but it didn't go away. I think it was deleted at some point by a different change and somehow ended up showing in here as well. (Tried to revert, got an error stating warn_opencl_generic_address_space_arg doesn't exist) |
lib/Sema/SemaDecl.cpp | ||
10772 | Yes, unfortunately there are cases these two differ. That's exactly the case we are trying to fix with that patch. |
It's worth noting that RecursiveASTVisitor appears to think they are at least somewhat equivalent in that it will only visit one or the other and prefers TypeSourceInfo, if present, via VisitTypeLoc. The fact that the TSI lacks this information makes it pretty awkward to access both the recursively deduced type and the corresponding source location. It seems like the places that expect this information to be absent could be trivially updated to disregard it after this patch, but synthesizing this from the available AST is much more challenging.
Thank you for the context and explanation! I don't feel like I have enough familiarity with this machinery to be an effective reviewer for signing off on anything. I've commented with some nits, but @rsmith should give the sign-off on this one.
include/clang/AST/PrettyPrinter.h | ||
---|---|---|
229 | prints deduced -> prints the deduced | |
230 | Add a whitespace before the left paren. | |
include/clang/Sema/Sema.h | ||
7063–7066 | I'd appreciate some comments as to why this is returning a pair and under what circumstances the type information will be different, because it's not likely to be obvious to anyone reading this header. | |
lib/Frontend/ASTConsumers.cpp | ||
92 | Since -> Because That said, I am not convinced I agree with this being the default. "Prettier" is pretty subjective, and I'd rather our default be for clarity instead of brevity, at least here. | |
lib/Sema/SemaChecking.cpp | ||
852 ↗ | (On Diff #167718) | That's truly strange. I bring it up because these sort of changes make it harder for reviewers to test changes locally by applying the patch themselves. |
lib/Sema/SemaDecl.cpp | ||
10912 | Don't use auto as the type is not spelled out in the initialization. | |
lib/Sema/SemaStmt.cpp | ||
1888 | Formatting is off here (the * should bind to the right). | |
1975 | Formatting. | |
3442–3443 | Same -- you should probably run the patch through clang-format (https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting). | |
lib/Sema/SemaTemplateDeduction.cpp | ||
4464 | Null check? |
A few more comments, mostly marking places of unintentional changes that we need to revert.
Hope it's not going past the point where the number of comments are not useful.
include/clang/Basic/DiagnosticSemaKinds.td | ||
---|---|---|
8616 ↗ | (On Diff #166279) | This looks unintentional. Should we revert? |
lib/Sema/SemaChecking.cpp | ||
852 ↗ | (On Diff #167718) | +1, we definitely need to revert this, happy to help figure out why this happened. |
lib/Sema/SemaTemplateDeduction.cpp | ||
4348–4349 | Maybe remove the intermediate variable? | |
lib/Tooling/Refactoring/Rename/USRLocFinder.cpp | ||
354 ↗ | (On Diff #169885) | Why do we need this change? Are we fixing some particular regressions? |
test/SemaOpenCL/to_addr_builtin.cl | ||
2 ↗ | (On Diff #169885) | Unrelated change. |
48 ↗ | (On Diff #169885) | Unrelated change |
122 ↗ | (On Diff #169885) | Another unrelated change |
We used to update the auto type in both the semantic type of the variable and in the type-as-written. I changed that in r180808; it was a while back, and I didn't do a good job explaining in the commit message, but I think the only reason was consistency. For the case of a deduced return type in a function, we really want to leave the type in the TypeSourceInfo alone, because we need to track the "declared return type" for redeclaration matching:
auto f() { return 0; } int f(); // error auto f(); // OK
As we need to sometimes track the "declared type" of the entity as distinct from the semantic type, and as the TypeSourceInfo is intended to track the type as written, it made sense to consistently not update the auto type in the type source information (so the TSI has the declared type, and getType() returns the semantic type).
That said... I'm definitely sympathetic to the problem. When using an AST matcher, for instance, we want to simultaneously think about matching certain syntactic source constructs (eg, match a TypeLoc) and then ask about the semantic properties of the type (for which you want to know what the deduced type was for an auto type). If we update the TypeSourceInfo for variables but not for functions, is that going to deliver the value you're looking for here, or should we be looking for some way to deal with cases where we want the TSI and type to differ and still want to be able to work out correspondences between them?
prints deduced -> prints the deduced