This is an archive of the discontinued LLVM Phabricator instance.

[AST][RecoveryAST] Preserve the type by default for recovery expression.
ClosedPublic

Authored by hokein on Jun 26 2020, 7:03 AM.

Details

Summary

Not intend to land it now, but ready for review.

Diff Detail

Event Timeline

hokein created this revision.Jun 26 2020, 7:03 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 26 2020, 7:03 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
hokein edited the summary of this revision. (Show Details)Jul 10 2020, 6:03 AM
hokein added a reviewer: sammccall.
hokein marked an inline comment as done.
hokein added inline comments.
clang/test/CXX/temp/temp.decls/temp.variadic/fixed-expansion.cpp
129 ↗(On Diff #276733)

the secondary diagnostic is technically correct, but I don't quite like it, it is confusing, ok to leave it as-is? or fix that before landing this patch?

As you said, we can't land this before the branch cut, and we shouldn't land this until we've run internal experiments to show it's not horribly crashy.

clang/test/CXX/temp/temp.constr/temp.constr.order/function-templates.cpp
71

this is really nice :-)

clang/test/CXX/temp/temp.decls/temp.variadic/fixed-expansion.cpp
129 ↗(On Diff #276733)

I don't think it's technically correct (the int fallback is an implementation artifact, albeit one that leaks quite often).
This example looks pretty obscure though, it'd be nice to fix it at some point but I don't think it's severe enough to block on the fix.

Fix ideas:

  • the instantiation of f should be invalid, right? Maybe we avoid considering return types for invalid decls when computing recovery type (or always give up in this case).
  • we could eventually try to replace the use of int for these cases
  • we could special-case int, and don't allow RecoveryExprs to have type int, reflecting the fact that it's used for these cases
hokein updated this revision to Diff 284995.Aug 12 2020, 12:51 AM

rebase and adjust more existing diagnostic tests.

As you said, we can't land this before the branch cut, and we shouldn't land this until we've run internal experiments to show it's not horribly crashy.

The internal experiment result is good, I think we're close to land it. After a new rebase, we need to adjust more diagnostics, but all of them look like good secondary-diagnostic improvements.

clang/test/CXX/temp/temp.decls/temp.variadic/fixed-expansion.cpp
129 ↗(On Diff #276733)

Fixed in D85714.

sammccall accepted this revision.Aug 21 2020, 4:15 AM

New diagnostics are really good :-)

clang/test/SemaCXX/abstract.cpp
282

the new diagnostics are correct (nice!) but this is just a bug in the test:
see https://bugs.llvm.org/show_bug.cgi?id=12658 vs https://github.com/llvm/llvm-project/commit/ea03214a5e3413cf95e388f28e4d9b9eeb30210a

To keep the test simple, I'd consider changing C& to const C& here instead.

clang/test/SemaCXX/type-convert-construct.cpp
9

again, arr v3 = arr(); is almost certainly intended

This revision is now accepted and ready to land.Aug 21 2020, 4:15 AM
hokein updated this revision to Diff 287029.Aug 21 2020, 7:22 AM
hokein marked 2 inline comments as done.

update

hokein updated this revision to Diff 287030.Aug 21 2020, 7:23 AM

update a comment.

clang/test/SemaCXX/abstract.cpp
282

I'd prefer to keep these as these are secondary-diagnostic improvements (so that we will not regress them in the future).

I fixed these tests, and created two in recovery-ast-type.cpp.

Hi @hokein,

sorry, but looks like your changes break one of libc++ tests on ARM cross toolchain build on Windows: libc++::function_type_default_deleter.fail.cpp
Here is the first failed build: http://lab.llvm.org:8011/builders/llvm-clang-win-x-armv7l/builds/945

I didn't get how these changes affects the failing test, but reverting of your commit fixes the problem.

Would you take a look and fix the problem? or revert the changes if it is going to take a lot of time to resolve?

Here is the command line to build the test:

C:/buildbot/temp/build/./bin/clang++.exe C:/buildbot/temp/llvm-project/libcxx/test/libcxx/utilities/memory/util.smartptr/util.smartptr.shared/function_type_default_deleter.fail.cpp -v --sysroot=C:/buildbot/.arm-ubuntu --target=armv7-linux-gnueabihf -include C:/buildbot/temp/build/runtimes/runtimes-bins/libcxx\__config_site -include C:/buildbot/temp/llvm-project/libcxx\test\support\nasty_macros.h -nostdinc++ -IC:/buildbot/temp/llvm-project/libcxx\include -IC:/buildbot/temp/build/runtimes/runtimes-bins/libcxx\include\c++build -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -IC:/buildbot/temp/llvm-project/libcxx\test/support -Werror -Wall -Wextra -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -Wshadow -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type -Wno-atomic-alignment -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-unused-local-typedef -std=c++2a -fcoroutines-ts -Werror=thread-safety -Wuser-defined-warnings -fsyntax-only -Wno-error -Xclang -verify -Xclang -verify-ignore-unexpected=note -ferror-limit=0

Here is the result output:

clang -cc1 version 12.0.0 based upon LLVM 12.0.0git default target armv7-linux-gnueabihf
ignoring nonexistent directory "C:/buildbot/.arm-ubuntu/usr/local/include"
ignoring nonexistent directory "C:/buildbot/.arm-ubuntu/include"
#include "..." search starts here:
#include <...> search starts here:
 C:/buildbot/temp/llvm-project/libcxx\include
 C:/buildbot/temp/build/runtimes/runtimes-bins/libcxx\include\c++build
 C:/buildbot/temp/llvm-project/libcxx\test/support
 C:\buildbot\temp\build\lib\clang\12.0.0\include
 C:/buildbot/.arm-ubuntu/usr/include/arm-linux-gnueabihf
 C:/buildbot/.arm-ubuntu/usr/include
End of search list.
error: 'error' diagnostics seen but not expected:
  File C:/buildbot/temp/llvm-project/libcxx\include\memory Line 2033: no member named 'value' in 'std::__1::is_empty<std::__1::__compressed_pair<void
(*)(Tag<5>), std::__1::default_delete<void (Tag<5>)>>>'
1 error generated.

Hi @hokein,

sorry, but looks like your changes break one of libc++ tests on ARM cross toolchain build on Windows: libc++::function_type_default_deleter.fail.cpp
Here is the first failed build: http://lab.llvm.org:8011/builders/llvm-clang-win-x-armv7l/builds/945

I didn't get how these changes affects the failing test, but reverting of your commit fixes the problem.

Would you take a look and fix the problem? or revert the changes if it is going to take a lot of time to resolve?

Here is the command line to build the test:

C:/buildbot/temp/build/./bin/clang++.exe C:/buildbot/temp/llvm-project/libcxx/test/libcxx/utilities/memory/util.smartptr/util.smartptr.shared/function_type_default_deleter.fail.cpp -v --sysroot=C:/buildbot/.arm-ubuntu --target=armv7-linux-gnueabihf -include C:/buildbot/temp/build/runtimes/runtimes-bins/libcxx\__config_site -include C:/buildbot/temp/llvm-project/libcxx\test\support\nasty_macros.h -nostdinc++ -IC:/buildbot/temp/llvm-project/libcxx\include -IC:/buildbot/temp/build/runtimes/runtimes-bins/libcxx\include\c++build -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -IC:/buildbot/temp/llvm-project/libcxx\test/support -Werror -Wall -Wextra -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -Wshadow -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type -Wno-atomic-alignment -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-unused-local-typedef -std=c++2a -fcoroutines-ts -Werror=thread-safety -Wuser-defined-warnings -fsyntax-only -Wno-error -Xclang -verify -Xclang -verify-ignore-unexpected=note -ferror-limit=0

Here is the result output:

clang -cc1 version 12.0.0 based upon LLVM 12.0.0git default target armv7-linux-gnueabihf
ignoring nonexistent directory "C:/buildbot/.arm-ubuntu/usr/local/include"
ignoring nonexistent directory "C:/buildbot/.arm-ubuntu/include"
#include "..." search starts here:
#include <...> search starts here:
 C:/buildbot/temp/llvm-project/libcxx\include
 C:/buildbot/temp/build/runtimes/runtimes-bins/libcxx\include\c++build
 C:/buildbot/temp/llvm-project/libcxx\test/support
 C:\buildbot\temp\build\lib\clang\12.0.0\include
 C:/buildbot/.arm-ubuntu/usr/include/arm-linux-gnueabihf
 C:/buildbot/.arm-ubuntu/usr/include
End of search list.
error: 'error' diagnostics seen but not expected:
  File C:/buildbot/temp/llvm-project/libcxx\include\memory Line 2033: no member named 'value' in 'std::__1::is_empty<std::__1::__compressed_pair<void
(*)(Tag<5>), std::__1::default_delete<void (Tag<5>)>>>'
1 error generated.

thanks! I have a proposal fix in D86685.

Hi @hokein , I encounter a bug when clang parses enum and I have been recorded in https://bugs.llvm.org/show_bug.cgi?id=51554.
The source code like the following:

enum E { e = E() };
int main() {
  return 0;
}

Some error message are expected like the following:

test.cpp:1:14: error: invalid use of incomplete type 'E'
enum E { e = E() };
             ^~~
test.cpp:1:6: note: definition of 'E' is not complete until the closing '}'
enum E { e = E() };

Also, I have made some analyses like the following:

In ParseDecl.cpp:
1. llvm-10: 
   AssignedVal.get(): NULL
   
2. llvm-12(Context.getLangOpts().RecoveryASTType: default false)(early-version):
   AssignedVal.get(): RecoveryExpr 0xaaaaba19df20 '<dependent type>' contains-errors lvalue
   
3. llvm-12(Context.getLangOpts().RecoveryASTType: default true) (latest-version, Finally crashed):
   AssignedVal.get()->dump(): RecoveryExpr 0xaaaabb4d9500 'enum E' contains-errors
   
In CheckEnumConstant(), EltTy(type: QualType, value: EnumType 0xaaaabb517dd0 'enum E') cannot use getIntWidth(), so crashed. But the code doesn't seem to be wrong around here.

Could you please have a look at this issue? Thanks a lot.

Hi @hokein , I encounter a bug when clang parses enum and I have been recorded in https://bugs.llvm.org/show_bug.cgi?id=51554.

I added a comment on the bug and sent https://reviews.llvm.org/D108451

This is a "rough edge" between erroneous and well-formed code and I'm not totally sure it's the perfect fix, but it does seem to be robust against crashes which is definitely he biggest thing.

Hi @hokein , I encounter a bug when clang parses enum and I have been recorded in https://bugs.llvm.org/show_bug.cgi?id=51554.

I added a comment on the bug and sent https://reviews.llvm.org/D108451

This is a "rough edge" between erroneous and well-formed code and I'm not totally sure it's the perfect fix, but it does seem to be robust against crashes which is definitely he biggest thing.

Yes, that's great, thanks a lot.