- User Since
- Mar 5 2015, 8:05 AM (265 w, 5 d)
Thu, Mar 26
Wed, Mar 25
Sorry for the delayed comments. It would be good to address those in a separate commit if possible.
Mon, Mar 23
Thu, Mar 12
Tue, Mar 10
Mar 4 2020
Mar 3 2020
Feb 27 2020
I would say if we are not aware of any test that this change breaks, let's go ahead and commit this?
Thanks for writing notes! Go ahead and push directly to the branch when you're ready.
@hans, what is the current process for committing to the release branch? Would you be able to commit this or would you prefer that I commit myself?
Feb 26 2020
Addressed comments from Hans and Sven.
Feb 25 2020
Feb 20 2020
- Always set isInvalid for all error cases.
- Hoist setting isInvalid together with an error diagnostic.
- Updated more tests.
Feb 19 2020
Feb 18 2020
- Updated expected diagnostics for function pointer tests
- Make DiagnoseAsignmentResult return true for all incompatible cases in C++
Feb 17 2020
Feb 14 2020
It looks like there's already some type analysis in DiagnoseAssignmentResult to get a specialized diagnostic for certain cases of function-pointer assignment. That could probably be easily moved into CheckAssignmentConstraints by just adding a few more cases to AssignConvertResult.
One interesting effect I get after modifying this that some extra tests in C mode started to report function pointer instead of generic pointer warning. I feel this is because in checkPointerTypesForAssignment we use canonical types and in DiagnoseAssignmentResult we don't.
- Switched to using CheckAssignmentConstraints
- Duplicated all extensions and warnings as errors for C++ mode
- Added IncompatibleFunctionPointer
Feb 12 2020
If I reuse the helper checkPointerTypesForAssignment I end up with lots of error turned into warnings, see example in
Feb 7 2020
Feb 6 2020
Feb 5 2020
Feb 4 2020
Add warning into IncompatiblePointerTypesDiscardsQualifiers group.
Jan 31 2020
Jan 30 2020
Jan 28 2020
Adding @svenvh mainly to check if any fix is needed for the TableGen BIFs too?
Jan 24 2020
Jan 3 2020
Jan 2 2020
Recovered lost bit of information.
Dec 27 2019
It looks good, I was just thinking whether it would be possible to share more common infrastructure. There is Sema::CheckVectorOperands that corresponding OpenCL methods are using internally. Do you think it is possible to share the code more?
Dec 16 2019
Dec 13 2019
Dec 12 2019
- Moved "address space" printing into diagnostic engine
- Moved LangAS::Default into switch/case statement.
Dec 11 2019
- Allow sending address spaces into diagnostics
- Change wording of diagnostics for address spaces in overloading
Dec 10 2019
Dec 6 2019
Dec 5 2019
I presume OpenCL addr space logic won't apply in all cases in non-OpenCL compilations i.e. for example C++ because we enclose some of the logic under LangOpts checks.
Dec 4 2019
LGTM! Thanks! Please address the comment in your final commit.
Dec 3 2019
Nov 28 2019
Switched to using getAddrSpaceQualType in the entire code base.
Sorry, I don't have capacity currently to review this and I don't want to be blocking it either.
Nov 27 2019
Added getDefaultCXXMethodAddrSpace helper to Sema
Nov 26 2019
Nov 25 2019
Nov 22 2019
I think we should use -fpermissive rather than adding similar flag to Clang. At the end we might end up with other cases where we need similar mechanism it doesn't make sense to add a flag for each case.
Nov 21 2019
Nov 19 2019
- Added FIXME to enhance testing.
Nov 15 2019
Nov 14 2019
- Added pointer to lambda test case.
Nov 12 2019
- Added missing handling of lambda w/o param list.
Nov 11 2019
Nov 7 2019
Stop emitting the denorms-are-zero attribute for the OpenCL flag. It
has no in-tree users. The meaning would also be target dependent, such
as the AMDGPU choice to treat this as only meaning allow flushing of
f32 and not f16 or f64. The naming is also potentially confusing,
since DAZ in other contexts refers to instructions implicitly treating
input denormals as zero, not necessarily flushing output denormals to