We have a new policy in place making links to private resources
something we try to avoid in source and test files. Normally, we'd
organically switch to the new policy rather than make a sweeping change
across a project. However, Clang is in a somewhat special circumstance
currently: recently, I've had several new contributors run into rdar
links around test code which their patch was changing the behavior of.
This turns out to be a surprisingly bad experience, especially for
newer folks, for a handful of reasons: not understanding what the link
is and feeling intimidated by it, wondering whether their changes are
actually breaking something important to a downstream in some way,
having to hunt down strangers not involved with the patch to impose on
them for help, accidental pressure from asking for potentially private
IP to be made public, etc. Because folks run into these links entirely
by chance (through fixing bugs or working on new features), there's not
really a set of problematic links to focus on -- all of the links have
basically the same potential for causing these problems. As a result,
this is an omnibus patch to remove all such links.
This was not a mechanical change; it was done by manually searching for
rdar, radar, radr, and other variants to find all the various
problematic links. From there, I tried to retain or reword the
surrounding comments so that we would lose as little context as
possible. However, because most links were just a plain link with no
supporting context, the majority of the changes are simple removals.
Differential Review: https://reviews.llvm.org/D158071
Summary:
Previously the TemplateSpecialization instance for 'template_alias', in the example below, returned the type info of the canonical type (int). This ignored the type alias if the template type happen to be aliased.
Before this patch, the assert would trigger with an alignment of 4:
```
typedef int __attribute__(( aligned( 16 ) )) aligned_int;
template < typename >
using template_alias = aligned_int;
static_assert( alignof( template_alias<void>) == 16, "" );
```
This patch checks if the TemplateSpecialization type has an alias, and if so will return the type information for the aliased type, else the canonical type's info is returned (original behavior). I believe that this is the desired behavior.
Reviewers: aaron.ballman, rjmccall
Reviewed By: rjmccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D54048
llvm-svn: 346146
Summary:
- Add `UETT_PreferredAlignOf` to account for the difference between `__alignof` and `alignof`
- `AlignOfType` now returns ABI alignment instead of preferred alignment iff clang-abi-compat > 7, and one uses _Alignof or alignof
Patch by Nicole Mazzuca!
Differential Revision: https://reviews.llvm.org/D53207
llvm-svn: 345419
A dependent alignment attribute (like __attribute__((aligned(...))) or
__declspec(align(...))) on a non-dependent typedef or using declaration
poses a considerable challenge: the type is _not_ dependent, the size
_may_ be dependent if the type is used as an array type, the alignment
_is_ dependent.
It is reasonable for a compiler to be able to query the size and
alignment of a complete type. Let's help that become an invariant.
This fixes PR22042.
Differential Revision: http://reviews.llvm.org/D8693
llvm-svn: 234280
expression of array-of-unknown-bound type, don't try to complete the array
bound, and return the alignment of the element type rather than 1.
llvm-svn: 210608
We were exposing the extra alignment given to large arrays. The new behavior
matches gcc, which is a good thing since this is a gcc extension.
Thanks to Joerg Sonnenberger for noticing it.
While at it, centralize the method description in the .h file.
llvm-svn: 187999
When the decl that we're getting alignment for is a FieldDecl, and the field's
parent record is invalid, skip the actual field alignment calculation (and
return 1-byte alignment in the general case).
Also, assert in in getASTRecordLayout that the decl is valid. This was
inspired by PR16292; see also r184581 and r184751.
llvm-svn: 184883
