Reduce space in empty constructors and between data members and first public section.
Fix some Include What You Use warnings.
Differential revision: http://reviews.llvm.org/D20213
llvm-svn: 269371
Bitsets, and the compiler features they rely on (vtable opt, CFI),
only have visibility within the LTO'd part of the linkage unit. Therefore,
only enable these features for classes with hidden LTO visibility. This
notion is based on object file visibility or (on Windows)
dllimport/dllexport attributes.
We provide the [[clang::lto_visibility_public]] attribute to override the
compiler's LTO visibility inference in cases where the class is defined
in the non-LTO'd part of the linkage unit, or where the ABI supports
calling classes derived from abstract base classes with hidden visibility
in other linkage units (e.g. COM on Windows).
If the cross-DSO CFI mode is enabled, bitset checks are emitted even for
classes with public LTO visibility, as that mode uses a separate mechanism
to cause bitsets to be exported.
This mechanism replaces the whole-program-vtables blacklist, so remove the
-fwhole-program-vtables-blacklist flag.
Because __declspec(uuid()) now implies [[clang::lto_visibility_public]], the
support for the special attr:uuid blacklist entry is removed.
Differential Revision: http://reviews.llvm.org/D18635
llvm-svn: 267784
At the moment almost every lit.site.cfg.in contains two lines comment:
## Autogenerated by LLVM/Clang configuration.
# Do not edit!
The patch adds variable LIT_SITE_CFG_IN_HEADER, that is replaced from
configure_lit_site_cfg with the note and some useful information.
llvm-svn: 266516
Dtrace is implemented to try and minimize performance impact on the process being traced. This results in dtrace dropping samples if it is taking too many CPU resources. Multi-threading dtrace increases the sample drop rate dramatically.
llvm-svn: 266213
This is re-landing r260742. I've reworked the conditionals so that it only hits when targeting Apple platforms with ld64.
Original Summary:
With this change generating clang order files using dtrace uses the following workflow:
cmake <whatever options you want>
ninja generate-order-file
ninja clang
This patch works by setting a default path to the order file (which can be overridden by the user). If the order file doesn't exist during configuration CMake will create an empty one.
CMake then ties up the dependencies between the clang link job and the order file, and generate-order-file overwrites CLANG_ORDER_FILE with the new order file.
llvm-svn: 265864
Displays a template specialization as, say, A<int, double>. Does not
yet handle UncommonTemplateNameStorage, QualifiedTemplateName, or
DependentTemplateName, but still more than worthwhile
llvm-svn: 265104
This is the clang equivalent to llvm commit 264601. When using Visual Studio 2015, cmake now puts the native visualizers in llvm.sln, so the developer automatically sees custom visualizations.
Much thanks to ariccio who provided extensive help on this change. (manual installation still needed on VS2013).
llvm-svn: 264603
When LIT parallelizes the profraw file generation we need to generate unique temp filenames then clean them up after the driver executes.
llvm-svn: 264021
With this change, the class
struct A {
A(int _i);
~A();
int foo(double d);
double bar(A *a) { return 1.3; }
};
appears in the VS2015 Locals Window as
D 0x02dbb378 struct A
|- DeclKind CXXRecord
|- Members
|- [0] implicit struct A
|- [1] Constructor {A(int _i)}
|- [2] Destructor {~A()}
|- [3] Method {int foo(double d)}
|- [4] Method {double bar(struct A *)}
|- [Raw View] /* Other stuff */
Note that these changes only benefit VS2015 as
VS2013 does not have views and only displays the
struct name "A", but the change does no apparent
harm in VS2013, so is still a win.
llvm-svn: 264020
This patch adds a new set of substitutions to the lit run lines for order files and PGO generation which run the clang driver to get the cc1 command, then execute the cc1 command directly. This allows the scripts to bypass profiling the clang driver over and over again.
The approach in this patch was discussed via IRC with Sean Silvas.
Special thanks to Daniel Dunbar whose out-of-tree code I liberally plagiarized.
llvm-svn: 263997
This change shows members of DeclContext objects in the Visual Studio debugger. It will also cast a TagType like a class or a struct to a DeclContext, so its methods and fields are visualized.
llvm-svn: 263794
Created visualizer for PointerType, LValueReferenceType, RValueReferenceType, and TemplateParmType.
In addition, cleaned up the display of existing types to be more C++-like. For example, instead of
SubstTemplateTypeParmType: {Identifier (("T"))} => Record (25), {Identifier (("A"))}
it now displays more readably as
SubstTemplateTypeParmType: {typename T <= struct A}
The <expand> sections still can be used for all the gory details if necessary.
llvm-svn: 263638
This is one of a series of changes to improve the MSVC visualization of Clang types.
This one focuses on Record and SubstTemplateTypeParmType meaning that, for example,
a TemplateArgumentLoc no longer displays incomprehensibly in the locals window as
{Argument={DeclArg={Kind=1 QT=0x033acb00 D=0xcccccccc {DeclType=???}}...
but instead much more usefully as
Type template parameter: SubstTemplateTypeParm: {Identifier (("T"))} => Record, {Identifier (("A"))}
Additional types and improvements will be made in subsequent commits
llvm-svn: 262933
exactly the same as clang's existing [[clang::fallthrough]] attribute, which
has been updated to have the same semantics. The one significant difference
is that [[fallthrough]] is ill-formed if it's not used immediately before a
switch label (even when -Wimplicit-fallthrough is disabled). To support that,
we now build a CFG of any function that uses a '[[fallthrough]];' statement
to check.
In passing, fix some bugs with our support for statement attributes -- in
particular, diagnose their use on declarations, rather than asserting.
llvm-svn: 262881
This appears to be passing '-Wl,-order_file' to Linux link commands,
which then causes the linker to silently, behind the scenes, write the
output to 'rder_file' instead of somewhere else. Will work with Chris to
figure out the proper support for this, but so far there are numerous
people who can't get Clang to update when they build because of this.
llvm-svn: 261054
Storing std::strings in attributes simply doesn't work, we never call
the destructor. Use an array of StringRefs instead of std::strings and
copy the data into memory taken from the ASTContext.
llvm-svn: 260831
Summary:
This commit re-lands r259862. The underlying cause of the build breakage was an incorrectly written capabilities test. In tools/Driver/CMakeLists.txt I was attempting to check if a linker flag worked, the test was passing it to the compiler, not the linker. CMake doesn't have a linker test, so we have a hand-rolled one.
Original Patch Review: http://reviews.llvm.org/D16896
Original Summary:
With this change generating clang order files using dtrace uses the following workflow:
cmake <whatever options you want>
ninja generate-order-file
ninja clang
This patch works by setting a default path to the order file (which can be overridden by the user). If the order file doesn't exist during configuration CMake will create an empty one.
CMake then ties up the dependencies between the clang link job and the order file, and generate-order-file overwrites CLANG_ORDER_FILE with the new order file.
Reviewers: bogner
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16999
llvm-svn: 260742
This reverts commit r259862, and attempts to fix builder CMakeCaches.
Will try this again some other time...
Conflicts:
CMakeLists.txt
tools/driver/CMakeLists.txt
llvm-svn: 259872
Summary:
With this change generating clang order files using dtrace uses the following workflow:
cmake <whatever options you want>
ninja generate-order-file
ninja clang
This patch works by setting a default path to the order file (which can be overridden by the user). If the order file doesn't exist during configuration CMake will create an empty one.
CMake then ties up the dependencies between the clang link job and the order file, and generate-order-file overwrites CLANG_ORDER_FILE with the new order file.
Reviewers: bogner
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16896
llvm-svn: 259862
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"This is the way [autoconf] ends
Not with a bang but a whimper."
-T.S. Eliot
Reviewers: chandlerc, grosbach, bob.wilson, echristo
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D16472
llvm-svn: 258862
The html reports are huge -- every issue in a given file results in a separate
copy of the source code, in HTML form, for the file. This gets very large
quickly and it doesn't make sense to check this into a reference repository.
Also remove the log when generating reference results because it can leak
absolute path names. We still keep both the html and the log around when
producing non-reference results.
llvm-svn: 258594
Summary:
This patch extends the lit-based perf-training tooling supplied for PGO data generation to also generate linker order files using dtrace.
This patch should work on any system that has dtrace. If CMake can find the dtrace tool it will generate a target 'generate-order-file' which will run the per-training tests wrapped by dtrace to capture function entries. There are several algorithms implemented for sorting the order files which can be experimented with for best performance. The dtrace wrapper also supports bot oneshot and pid probes.
The perf-helper.py changes to support order file construction are ported from internal changes by ddunbar; he gets all the credit for the hard work here, I just copy and pasted.
Note: I've tested these patches on FreeBSD and OS X 10.10.
Reviewers: ddunbar, bogner, silvas
Subscribers: llvm-commits, emaste
Differential Revision: http://reviews.llvm.org/D16134
llvm-svn: 257934
Summary:
This patch adds support for using LIT to drive generating PGO profile data for clang.
This first pass implementation should work on Linux and Unix based platforms. If you build clang using CMake with LLVM_BUILD_INSTRUMENTED=On the CMake build generates a generate-profdata target that will use the just-built clang to build any test files (see hello_world.cpp as an example). Each test compile will generate profraw files for each clang process. After all tests have run CMake will merge the profraw files using llvm-profdata.
Future opportunities for extension:
* Support for Build->Profile->Build bootstrapping
* Support for linker order file generation using a similar mechanism and the same training data
* Support for Windows
Reviewers: dexonsmith, friss, bogner, cmatthews, vsk, silvas
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15462
llvm-svn: 255740
Currently the SATestBuild.py and SATestAdd.py buildbot scripts expect project
sources to be checked into the project repository. This commit changes these
scripts to additionally support a model where project sources are downloaded
rather than checked into the repository. Sometimes projects may need to be
modified (for example, to support a newer versions of clang), so the updated scripts
also allow for an optional patch file that will be applied to the downloaded
project source before analysis.
To support this workflow, this commit changes the expected layout of
a project in the repository. The project-specific helper scripts will stay
in the root of each project directory, but the benchmark source itself (if
checked into the repo) should now be stored in a subdirectory named
'CachedSource':
project_name/
cleanup_run_static_analyzer.sh [optional]
run_static_analyzer.cmd [required]
download_project.sh [optional]
CachedSource/ [optional]
changes_for_analyzer.patch [optional]
If the 'CachedSource' source directory is not present, the download script will
be executed. This script should download the project source into 'CachedSource'.
Then, if 'changes_for_analyzer.patch' is present its changes will
be applied to a copy of 'CachedSource' before analysis.
Differential Revision: http://reviews.llvm.org/D14345
llvm-svn: 252410
Fake arguments are automatically handled for serialization, cloning,
and other representational tasks, but aren't included in pretty-printing
or parsing (should we eventually ever automate that).
This is chiefly useful for attributes that can be written by the
user, but which are also frequently synthesized by the compiler,
and which we'd like to remember details of the synthesis for.
As a simple example, use this to narrow the cases in which we were
generating a specialized note for implicitly unavailable declarations.
llvm-svn: 251469
This patch adds hashes to the plist and html output to be able to identfy bugs
for suppressing false positives or diff results against a baseline. This hash
aims to be resilient for code evolution and is usable to identify bugs in two
different snapshots of the same software. One missing piece however is a
permanent unique identifier of the checker that produces the warning. Once that
issue is resolved, the hashes generated are going to change. Until that point
this feature is marked experimental, but it is suitable for early adoption.
Differential Revision: http://reviews.llvm.org/D10305
Original patch by: Bence Babati!
llvm-svn: 251011
Automatically insert line feed after pretty printing of all pragma-like attributes + fix printing of pragma-like pragmas on declarations.
Differential Revision: http://reviews.llvm.org/D13546
llvm-svn: 250017
Move the logic looking for additional checkers in the SA_ADDITIONAL_CHECKERS
environmental variable from SATestBuild's main() to runScanBuild(). This allows
SATestAdd.py to use the variable as well. Without it, we won't include
additional checkers when building reference results for the build bot.
Differential Revision: http://reviews.llvm.org/D12891
llvm-svn: 247767
Update the static analyzer buildbot script to set -isysroot to the OS X SDK path
when analyzing preprocessed files on OS X.
Differential Revision: http://reviews.llvm.org/D12769
llvm-svn: 247617
We can use the 'H' typespec modifier to use 128-bit vectors directly
in the only two users of this special-case: the vcvt f16 intrinsics.
This also lets us use more meaningful prototype modifiers.
llvm-svn: 245778
We had "vcvt_f16" and "VCVT_HIGH_F16": for other FP types, this naming
is used for intrinsics with integer overloads. The FP->FP conversions,
on the other hand, use the full "vcvt_f32_f64" name instead.
Use the same naming convention for the f16<->f32 conversions.
While there, reorder the definitions a little bit.
llvm-svn: 245763
Improvement to the memory leak fix in 244196.
Address validity is required for the Intrinsic objects, but since the
collections only ever grow (no elements are removed), deque provides
sufficient guarantees (that the objects will never be reallocated/moved
around) for this use case.
llvm-svn: 244241
GenerateHasAttrSpellingStringSwitch and GenerateTargetRequirements had
duplicated code to check the conditions for target-specific attributes.
Refactor the duplicated code into a separate function. NFC.
llvm-svn: 242731
Clang used to silently ignore __declspec(novtable). It is implemented
now, but leaving the vtable uninitialized does not work when using the
Itanium ABI, where the class layout for complex class hierarchies is
stored in the vtable. It might be possible to honor the novtable
attribute in some simple cases and either report an error or ignore
it in more complex situations, but it’s not clear if that would be
worthwhile. There is also value in having a simple and predictable
behavior, so this changes clang to simply ignore novtable when not using
the Microsoft C++ ABI.
llvm-svn: 242730
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
Adds a new warning (under -Wnullability-completeness) that complains
about pointer, block pointer, or member pointer declarations that have
not been annotated with nullability information (directly or inferred)
within a header that contains some nullability annotations. This is
intended to be used to help maintain the completeness of nullability
information within a header that has already been audited.
Note that, for performance reasons, this warning will underrepresent
the number of non-annotated pointers in the case where more than one
pointer is seen before the first nullability type specifier, because
we're only tracking one piece of information per header. Part of
rdar://problem/18868820.
llvm-svn: 240158
On ARM/AArch64, we currently always use EmitScalarExpr for the immediate
builtin arguments, instead of directly emitting the constant. When the
overflow sanitizer is enabled, this generates overflow intrinsics
instead of constants, breaking assumptions in various places.
Instead, use the knowledge of "immediates" to directly emit a constant:
- teach the tablegen backend to emit the "immediate" modifiers
- use those modifiers in the NEON CodeGen, on ARM and AArch64.
Fixes PR23517.
Differential Revision: http://reviews.llvm.org/D10045
llvm-svn: 239002
Recognise options to output dependency files and don't perform checks.
Report input file name when reporting a check failure so it is more obvious in large build logs.
Differential Revision: http://reviews.llvm.org/D10183
llvm-svn: 238928
Files compiled with -via-file-asm should be byte for byte identical. This
change improves the checking on dash_s_no_change to detect non-code
differences. If there is a difference, the check goes on to compare code and
debug to try and be more informative.
llvm-svn: 238926
If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.
Call sites were found with the ASTMatcher + some semi-automated cleanup.
memberCallExpr(
argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
hasArgument(0, bindTemporaryExpr(
hasType(recordDecl(hasNonTrivialDestructor())),
has(constructExpr()))),
unless(isInTemplateInstantiation()))
No functional change intended.
llvm-svn: 238601
The GCC construct __attribute__((aligned)) is defined to set alignment
to "the default alignment for the target architecture" according to
the GCC documentation:
The default alignment is sufficient for all scalar types, but may not be
enough for all vector types on a target that supports vector operations.
The default alignment is fixed for a particular target ABI.
clang currently hard-coded an alignment of 16 bytes for that construct,
which is correct on some platforms (including X86), but wrong on others
(including SystemZ). Since this value is ABI-relevant, it is important
to get correct for compatibility purposes.
This patch adds a new TargetInfo member "DefaultAlignForAttributeAligned"
that targets can set to the appropriate default __attribute__((aligned))
value.
Note that I'm deliberately *not* using the existing "SuitableAlign"
value, which is used to set the pre-defined macro __BIGGEST_ALIGNMENT__,
since those two values may not be the same on all platforms. In fact,
on X86, __attribute__((aligned)) always uses 16-byte alignment, while
__BIGGEST_ALIGNMENT__ may be larger if AVX-2 or AVX-512 are supported.
(This is actually not yet correctly implemented in clang either.)
The patch provides a value for DefaultAlignForAttributeAligned only for
SystemZ, and leaves the default for all other targets at 16, which means
no visible change in behavior on all other targets. (The value is still
wrong for some other targets, but I'd prefer to leave it to the target
maintainers for those platforms to fix.)
llvm-svn: 235397
This is a tool for checking consistency of code generation with different
compiler options (such as -g or outputting to .s). This tool has found a number
of code generation issues. The script acts as a wrapper to clang or clang++
performing 2 (or more) compiles then comparing the object files. Instructions
for use are in check_cfc.py including how to use with LNT.
Differential Revision: http://reviews.llvm.org/D8723
llvm-svn: 233919
We know all subclasses in tblgen so just generate a giant switch for
the few virtual methods or turn them into a member variable using spare
bits. The giant jump tables aren't pretty but still much smaller than
a vtable for every attribute, shrinking Release+Asserts clang by ~400k.
Also halves the size of the Attr base class. No functional change
intended.
llvm-svn: 232726
Now that SmallString is a first-class citizen, most SmallString::str()
calls are not required. This patch removes a whole bunch of them, yet
there are lots more.
There are two use cases where str() is really needed:
1) To use one of StringRef member functions which is not available in
SmallString.
2) To convert to std::string, as StringRef implicitly converts while
SmallString do not. We may wish to change this, but it may introduce
ambiguity.
llvm-svn: 232622
We do not implicitly create an OpenCLImageAccessAttr, so this change only affects out of tree users. There is no way to test this behavior specifically that I can see, since this only affects implicit creation of attributes.
Fixes PR22403.
llvm-svn: 231803
This attribute serves as a hint to improve warnings about the ranges of
enumerators used as flag types. It currently has no working C++ implementation
due to different semantics for enums in C++. For more explanation, see the docs
and testcases.
Reviewed by Aaron Ballman.
llvm-svn: 222906
Instead of manually maintaining a flag indicating whether we're about to print
out the last child of the parent node (to determine whether we print "`" or
"|"), capture a callable to print that child and defer printing it until we
either see a next child or finish the parent.
No functionality change intended.
llvm-svn: 220930
Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1).
Reviewed by Richard Smith
llvm-svn: 219589
When generating records/unions, the same enum type may be generated more
than once (with different names). In these cases, the name of the enum
values are not sufficiently unique to prevent multiple declarations. E.g:
typedef enum T3 { enum0val0 } T3;
typedef T3 T2[3];
typedef enum T4 { enum0val0 } T4;
typedef union T1 { T2 field0; T4 field1; char field2; } T1;
Added a unique suffix to enum values so that multiple identical enum types do
not use the same enum value names.
One example of this bug is produced by:
ABITestGen.py --no-unsigned --no-vector --no-complex --no-bool \
--max-args 0 --max-record-depth 1 -o inputs/test.9921.a.c \
-T inputs/test.9921.b.c -D inputs/test.9921.driver.c \
--min=9921 --count=1
llvm-svn: 216166
This function might be a bit easier if it were split in two with a lot
of early returns - and that setOptional bit in the outer function, but
anyway.
llvm-svn: 215263
Updating the diagnostics in the launch_bounds test since they have been improved in that case. Adding a test for nonnull since it has little test coverage, but has truly variadic arguments.
llvm-svn: 214407
The NEON intrinsics in arm_neon.h are designed to work on vectors
"as-if" loaded by (V)LDR. We load vectors "as-if" (V)LD1, so the
intrinsics are currently incorrect.
This patch adds big-endian versions of the intrinsics that does the
"obvious but dumb" thing of reversing all vector inputs and all
vector outputs. This will produce extra REVs, but we trust the
optimizer to remove them.
llvm-svn: 211893
There comes a time in the life of any amateur code generator when dumb string
concatenation just won't cut it any more. For NeonEmitter.cpp, that time has
come.
There were a bunch of magic type codes which meant different things depending on
the context. There were a bunch of special cases that really had no reason to be
there but the whole thing was so creaky that removing them would cause something
weird to fall over. There was a 1000 line switch statement for code generation
involving string concatenation, which actually did lexical scoping to an extent
(!!) with a bunch of semi-repeated cases.
I tried to refactor this three times in three different ways without
success. The only way forward was to rewrite the entire thing. Luckily the
testing coverage on this stuff is absolutely massive, both with regression tests
and the "emperor" random test case generator.
The main change is that previously, in arm_neon.td a bunch of "Operation"s were
defined with special names. NeonEmitter.cpp knew about these Operations and
would emit code based on a huge switch. Actually this doesn't make much sense -
the type information was held as strings, so type checking was impossible. Also
TableGen's DAG type actually suits this sort of code generation very well
(surprising that...)
So now every operation is defined in terms of TableGen DAGs. There are a bunch
of operators to use, including "op" (a generic unary or binary operator), "call"
(to call other intrinsics) and "shuffle" (take a guess...). One of the main
advantages of this apart from making it more obvious what is going on, is that
we have proper type inference. This has two obvious advantages:
1) TableGen can error on bad intrinsic definitions easier, instead of just
generating wrong code.
2) Calls to other intrinsics are typechecked too. So
we no longer need to work out whether the thing we call needs to be the Q-lane
version or the D-lane version - TableGen knows that itself!
Here's an example: before:
case OpAbdl: {
std::string abd = MangleName("vabd", typestr, ClassS) + "(__a, __b)";
if (typestr[0] != 'U') {
// vabd results are always unsigned and must be zero-extended.
std::string utype = "U" + typestr.str();
s += "(" + TypeString(proto[0], typestr) + ")";
abd = "(" + TypeString('d', utype) + ")" + abd;
s += Extend(utype, abd) + ";";
} else {
s += Extend(typestr, abd) + ";";
}
break;
}
after:
def OP_ABDL : Op<(cast "R", (call "vmovl", (cast $p0, "U",
(call "vabd", $p0, $p1))))>;
As an example of what happens if you do something wrong now, here's what happens
if you make $p0 unsigned before the call to "vabd" - that is, $p0 -> (cast "U",
$p0):
arm_neon.td:574:1: error: No compatible intrinsic found - looking up intrinsic 'vabd(uint8x8_t, int8x8_t)'
Available overloads:
- float64x2_t vabdq_v(float64x2_t, float64x2_t)
- float64x1_t vabd_v(float64x1_t, float64x1_t)
- float64_t vabdd_f64(float64_t, float64_t)
- float32_t vabds_f32(float32_t, float32_t)
... snip ...
This makes it seriously easy to work out what you've done wrong in fairly nasty
intrinsics.
As part of this I've massively beefed up the documentation in arm_neon.td too.
Things still to do / on the radar:
- Testcase generation. This was implemented in the previous version and not in
the new one, because
- Autogenerated tests are not being run. The testcase in test/ differs from
the autogenerated version.
- There were a whole slew of special cases in the testcase generation that just
felt (and looked) like hacks.
If someone really feels strongly about this, I can try and reimplement it too.
- Big endian. That's coming soon and should be a very small diff on top of this one.
llvm-svn: 211101
By describing system header suppressions directly in tablegen we eliminate
special cases in getDiagnosticSeverity().
Dropping the reliance on builtin diagnostic classes when mapping also gets us
closer to the goal of reusing the diagnostic machinery for custom diagnostics.
No change in functionality.
llvm-svn: 211023
hint attributes. Includes tests for pragma printing and for attribute order
which is incorrectly reversed by ParsedAttributes.
Reviewed by Aaron Ballman
llvm-svn: 210925
This begins to address cognitive dissonance caused by treating the Note
diagnostic level as a severity in the diagnostic engine.
No change in functionality.
llvm-svn: 210758
will never be true in a well-defined context. The checking for null pointers
has been moved into the caller logic so it does not rely on undefined behavior.
llvm-svn: 210498
I was bitten by this when working with the dll attributes: when a dll
attribute was cloned from a class template declaration to its
specialization, the Inherited flag didn't get cloned.
Differential Revision: http://reviews.llvm.org/D3972
llvm-svn: 209950
The attribute emitter was using FunctionTemplate to map the diagnostic to "functions or methods", but that isn't a particularly clear diagnostic in these cases anyway (since they do not apply to ObjC methods). Updated the attribute emitter to remove custom logic for FunctionTemplateDecl, and updated the test cases for the change in diagnostic wording.
llvm-svn: 209209
Replace a large monolitic function, with per-table functions which all nicely
fit on my screen. I also added documentation to each function that describes
what kind of tables are generated and which information is contained and
switched to range based for loops. Finally, I run clang-format over the moved
code.
I spent a significant amount of time to understand this code when reasoning
about possible extensions to the diagnostic interface to support 'remark'
diagnostics. This change will definitely help such an implementation, but
already by itself it will save other people a lot of time when trying to
understand this functionality.
Even though the patch touches the full function, it is mostly mechanical. No
functional change intended. The generated tblgen files are identical.
llvm-svn: 208136
Since the community says that a blacklist is not good enough, and I don't have
enough time now to implement a proper whitelist, let's just remove the
attribute validation.
But, nevertheless, we can still communicate in the generated XML if our parser
found an issue with the HTML. But this bit is best-effort and is specifically
called out in the schema as such.
llvm-svn: 207712
through to the output even if the input comment comes from an untrusted source
Attribute filtering is currently based on a blacklist, which right now includes
all event handler attributes (they contain JavaScipt code). It should be
switched to a whitelist, but going over all of the HTML5 spec requires a
significant amount of time.
llvm-svn: 206882
Clean up the __has_attribute implementation without modifying its behavior.
Replaces the tablegen-driven AttrSpellings.inc, which lived in the lexing layer with AttrHasAttributeImpl.inc, which lives in the basic layer. Updates the preprocessor to call through to this new functionality which can take additional information into account (such as scopes and syntaxes).
Expose the ability for parts of the compiler to ask whether an attribute is supported for a given spelling (including scope), syntax, triple and language options.
llvm-svn: 205181
Richard Smith