Clang always assumes that files are utf-8. If an invalidly encoded character is
used in an identifier, clang always errors. If it's used in a character
literal, clang warns Winvalid-source-encoding (on by default). Clang never
checks the encoding of things in comments (adding this seems like a nice
feature if it doesn't impact performance).
For cl.exe /utf-8 (which enables /validate-charset), if a bad character is used
in an identifier, it emits both an error and a warning. If it's used in a
literal or a comment, it emits a warning.
So mapping /validate-charset to -Winvalid-source-encoding seems like a fairly
decent fit.
https://reviews.llvm.org/D23945
llvm-svn: 279872
This is triggered when we are compiling an implementation of a module,
it has relative includes to a VFS-mapped module with umbrella headers.
Currently we will find the real path to headers under the umbrella directory,
but the umbrella directories are using virtual path.
rdar://27951255
Thanks Ben and Richard for reviewing the patch!
Differential Revision: http://reviews.llvm.org/D23858
llvm-svn: 279838
Otherwise we can't handle secondary base classes at offsets greater than
2**24. This agrees with libstdc++abi.
We could extend this change to other LLP64 platforms, but then we would
want to update libc++abi and it would require additional review.
Fixes PR29116
llvm-svn: 279786
Clang tracks only start columns, not start-end ranges. CodeView allows for that, but the VS debugger doesn't handle anything less than a complete range well--it either highlights the wrong part of a statement or truncates source lines in the assembly view. It's better to have no column information at all.
So by default, we'll omit the column information for CodeView targeting Windows.
Since the column info is still useful for sanitizers, I've promoted -gcolumn-info (and -gno-column-info) to a CoreOption and added a couple tests to make sure that works for clang-cl.
Differential Revision: https://reviews.llvm.org/D23720
llvm-svn: 279765
This isn't exactly what MSVC does, unfortunately. MSVC does not pass
objects with destructors but no copy constructors by address. More ARM
expertise is required to really understand what should be done here.
Fixes PR29136.
llvm-svn: 279764
Emit proper diagnostics when -Wdocumentation is used with constructs such as:
template<typename T>
using fn = int(T aaa, int ccc);
Previously clang wouldn't recognize the function and complain with
'comment that is not attached to a function declaration'.
Differential Revision: https://reviews.llvm.org/D23860
rdar://problem/27300695
llvm-svn: 279754
JavaScript template strings can be nested arbitrarily:
foo = `text ${es.map(e => { return `<${e}>`; })} text`;
This change lexes nested template strings using a stack of lexer states to
correctly switch back to template string lexing on closing braces.
Also, reuse the same stack for the token-stashed logic.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D22431
llvm-svn: 279727
Summary:
1. Pair removed from StringMap was not destroyed
2. ObjectFile had no owner
Reviewers: sfantao
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D23865
llvm-svn: 279722
If the inline info is not duplicated into the skeleton CU, then there's
value in using -gsplit-dwarf and -gmlt together (to keep all those extra
subprograms out of the skeleton CU, while also producing smaller .dwo
files)
llvm-svn: 279687
The oneshot probe only gets executed the first time the probe is hit in the process. For order file generation this is really all we care about.
llvm-svn: 279673
per-frame stack usage enough to cause it to hit our stack limit. This is not
ideal; we should find a better way of dealing with this, such as increasing
our stack allocation when built with ASan.
llvm-svn: 279668
Give appropriate warnings with -Wdocumentation for @param comments
that refer to function aliases defined with 'using'. Very similar
to typedef's behavior. This does not add support for
TypeAliasTemplateDecl yet.
Differential Revision: https://reviews.llvm.org/D23783
rdar://problem/27300695
llvm-svn: 279662
In cases where .dwo/.dwp files are guaranteed to be available, skipping
the extra online (in the .o file) inline info can save a substantial
amount of space - see the original r221306 for more details there.
llvm-svn: 279651
Summary:
This patch adds the capability to bundle object files in sections of the host binary using a designated naming convention for these sections. This patch uses the functionality of the object reader already in the LLVM library to read bundled files, and invokes clang with the incremental linking options to create bundle files.
Bundling files involves creating an IR file with the contents of the bundle assigned as initializers of globals binded to the designated sections. This way the bundling implementation is agnostic of the host object format.
The features added by this patch were requested in the RFC discussion in http://lists.llvm.org/pipermail/cfe-dev/2016-February/047547.html.
Reviewers: echristo, tra, jlebar, hfinkel, ABataev, Hahnfeld
Subscribers: mkuron, whchung, cfe-commits, andreybokhanko, Hahnfeld, arpith-jacob, carlo.bertolli, mehdi_amini, caomhin
Differential Revision: https://reviews.llvm.org/D21851
llvm-svn: 279634
Summary:
One of the goals of programming models that support offloading (e.g. OpenMP) is to enable users to offload with little effort, by annotating the code with a few pragmas. I'd also like to save users the trouble of changing their existent applications' build system. So having the compiler always return a single file instead of one for the host and each target even if the user is doing separate compilation is desirable.
This diff proposes a tool named clang-offload-bundler (happy to change the name if required) that is used to bundle files associated with the same user source file but different targets, or to unbundle a file into separate files associated with different targets.
This tool supports the driver support for OpenMP under review in http://reviews.llvm.org/D9888. The tool is used there to enable separate compilation, so that the very first action on input files that are not source files is a "unbundling action" and the very last non-linking action is a "bundling action".
The format of the bundled files is currently very simple: text formats are concatenated with comments that have a magic string and target identifying triple in between, and binary formats have a header that contains the triple and the offset and size of the code for host and each target.
The goal is to improve this tool in the future to deal with archive files so that each individual file in the archive is properly dealt with. We see that archives are very commonly used in current applications to combine separate compilation results. So I'm convinced users would enjoy this feature.
This tool can be used like this:
`clang-offload-bundler -targets=triple1,triple2 -type=ii -inputs=a.triple1.ii,a.triple2.ii -outputs=a.ii`
or
`clang-offload-bundler -targets=triple1,triple2 -type=ii -outputs=a.triple1.ii,a.triple2.ii -inputs=a.ii -unbundle`
I implemented the tool under clang/tools. Please let me know if something like this should live somewhere else.
This patch is prerequisite for http://reviews.llvm.org/D9888.
Reviewers: hfinkel, rsmith, echristo, chandlerc, tra, jlebar, ABataev, Hahnfeld
Subscribers: whchung, caomhin, andreybokhanko, arpith-jacob, carlo.bertolli, mehdi_amini, guansong, Hahnfeld, cfe-commits
Differential Revision: https://reviews.llvm.org/D13909
llvm-svn: 279632
This diff reorders the fields and removes excessive padding.
This fixes the following warning:
PTHLexer.cpp:629:7: warning: Excessive padding in 'class (anonymous namespace)::PTHStatData' (14 padding bytes, where 6 is optimal). Optimal fields order: Size, ModTime, UniqueID, HasData, IsDirectory, consider reordering the fields or adding explicit padding members.
Patch by: Alexander Shaposhnikov <shal1t712@gmail.com>
Differential Revision: https://reviews.llvm.org/D23826
llvm-svn: 279607
Summary:
Add a cmake check for sys/resource.h and replace the __has_include() check with its result, in order to make it possible to use rlimits when building with compilers not supporting __has_include() -- i.e. when bootstrapping.
// Please also re-apply dfcd52eb1d8e5d322404b40414cb7331c7380a8c (llvm-config.h fix)
Patch by: Michał Górny
Reviewers: rsmith, beanz
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23744
llvm-svn: 279559
to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly
determine whether a function definition is visible, and mark both the function
and the template as visible when merging function template definitions to
provide hasVisibleDefinition with the relevant information.
The change to always pass the right declaration as the PatternDef to
DiagnoseUninstantiableTemplate also caused those checks to happen before other
diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the
same situations, so I sunk the relevant diagnostics into
DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes
in reviews.llvm.org/D23492 by Vassil Vassilev.
This reinstates r279486, reverted in r279500, with a fix to
DiagnoseUninstantiableTemplate to only mark uninstantiable explicit
instantiation declarations as invalid if we actually diagnosed them. (When we
trigger an explicit instantiation of a class member from an explicit
instantiation declaration for the class, it's OK if there is no corresponding
definition and we certainly don't want to mark the member invalid in that
case.) This previously caused a build failure during bootstrap.
llvm-svn: 279557
/Brepro means we want reproducible builds, i.e. we _don't_ want the timestamp
that's needed to be compatible with the incremental linker.
https://reviews.llvm.org/D23805
llvm-svn: 279555
iOS (and other 32-bit ARM variants) always require a valid frame pointer to
improve backtraces. Previously the -fomit-frame-pointer and
-momit-leaf-frame-pointer options were being silently discarded via hacks in
the backend. It's better if Clang configures itself to emit the correct IR and
warns about (ignored) attempts to override this.
llvm-svn: 279546
clang already treats all inputs as utf-8. Warn if anything but utf-8 is passed.
Do this by mapping source-charset to finput-charset, which already behaves like
this. Slightly tweak finput-charset to accept "utf-8" case-insensitively. This
matches gcc's and cl.exe's behavior, and IANA says that character set names are
case-insensitive.
https://reviews.llvm.org/D23807
llvm-svn: 279531
If a call expression represents a method call of a class template,
and the method itself isn't templated, then the method may be considered
to be a template instantiation without template specialization arguments.
No longer crash when we could not find template specialization arguments.
Patch by Raphael Isemann!
Differential Revision: https://reviews.llvm.org/D23780
llvm-svn: 279529
to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly
determine whether a function definition is visible, and mark both the function
and the template as visible when merging function template definitions to
provide hasVisibleDefinition with the relevant information.
The change to always pass the right declaration as the PatternDef to
DiagnoseUninstantiableTemplate also caused those checks to happen before other
diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the
same situations, so I sunk the relevant diagnostics into
DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes
in reviews.llvm.org/D23492 by Vassil Vassilev.
llvm-svn: 279486
in isDefinedInClangModule() and assume that the incomplete definition
is not defined in the module.
This broke the -gmodules self host recently.
rdar://problem/27894367
llvm-svn: 279485
Nico Weber