| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 224226
|
|
|
|
|
|
|
| |
It makes more sense for ThreadLocal<const T>::get to return a const T*
and ThreadLocal<T>::get to return a T*.
llvm-svn: 224225
|
|
|
|
|
|
| |
This removes a duplicated stat on every file that llvm-ar looks at.
llvm-svn: 224138
|
|
|
|
|
|
| |
I will add a real use in another commit.
llvm-svn: 224136
|
|
|
|
| |
llvm-svn: 224135
|
|
|
|
|
|
| |
As a bonus we can actually check the return value.
llvm-svn: 224046
|
|
|
|
| |
llvm-svn: 224029
|
|
|
|
|
|
| |
This interface was added 2 years ago but users never developed.
llvm-svn: 223368
|
|
|
|
|
|
|
| |
Allows long paths for the executable and redirected stdin/stdout/stderr.
Addresses PR21563.
llvm-svn: 222671
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fill in omission of `cast_or_null<>` and `dyn_cast_or_null<>` for types
that wrap pointers (e.g., smart pointers).
Type traits need to be slightly stricter than for `cast<>` and
`dyn_cast<>` to resolve ambiguities with simple types.
There didn't seem to be any unit tests for pointer wrappers, so I tested
`isa<>`, `cast<>`, and `dyn_cast<>` while I was in there.
This only supports pointer wrappers with a conversion to `bool` to check
for null. If in the future it's useful to support wrappers without such
a conversion, it should be a straightforward incremental step to use the
`simplify_type` machinery for the null check. In that case, the unit
tests should be updated to remove the `operator bool()` from the
`pointer_wrappers::PTy`.
llvm-svn: 222644
|
|
|
|
|
|
|
| |
The logic for detecting EOF was wrong and would fail if we ever requested
more than 16k past the last read position.
llvm-svn: 222505
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"global-init", "global-init-src" and "global-init-type" were originally
used to blacklist entities in ASan init-order checker. However, they
were never documented, and later were replaced by "=init" category.
Old blacklist entries should be converted as follows:
* global-init:foo -> global:foo=init
* global-init-src:bar -> src:bar=init
* global-init-type:baz -> type:baz=init
llvm-svn: 222401
|
|
|
|
| |
llvm-svn: 221887
|
|
|
|
| |
llvm-svn: 221845
|
|
|
|
|
|
|
|
|
|
| |
Windows normally limits the length of an absolute path name to 260
characters; directories can have lower limits. These limits increase
to about 32K if you use absolute paths with the special '\\?\'
prefix. Teach Support\Windows\Path.inc to use that prefix as needed.
TODO: Other parts of Support could also learn to use this prefix.
llvm-svn: 221841
|
|
|
|
|
|
|
|
| |
built as SHARED. Users of LLVMSupport won't inherit ${system_libs}.
unittests/SupporTests is another user of libpthreads. Apply LLVM_SYSTEM_LIBS for him explicitly.
llvm-svn: 221531
|
|
|
|
|
|
|
|
|
|
| |
mach-o supports "fat" files which are a header/table-of-contents followed by a
concatenation of mach-o files built for different architectures. Currently,
MemoryBuffer has no easy way to map a subrange (slice) of a file which lld
will need to select a mach-o slice of a fat file. The new function provides
an easy way to map a slice of a file into a MemoryBuffer. Test case included.
llvm-svn: 219260
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm::format() is somewhat unsafe. The compiler does not check that integer
parameter size matches the %x or %d size and it does not complain when a
StringRef is passed for a %s. And correctly using a StringRef with format() is
ugly because you have to convert it to a std::string then call c_str().
The cases where llvm::format() is useful is controlling how numbers and
strings are printed, especially when you want fixed width output. This
patch adds some new formatting functions to raw_streams to format numbers
and StringRefs in a type safe manner. Some examples:
OS << format_hex(255, 6) => "0x00ff"
OS << format_hex(255, 4) => "0xff"
OS << format_decimal(0, 5) => " 0"
OS << format_decimal(255, 5) => " 255"
OS << right_justify(Str, 5) => " foo"
OS << left_justify(Str, 5) => "foo "
llvm-svn: 218463
|
|
|
|
|
|
|
|
| |
It isn't always useful to skip blank lines, as evidenced by the
somewhat awkward use of line_iterator in llvm-cov. This adds a knob to
control whether or not to skip blanks.
llvm-svn: 217960
|
|
|
|
|
|
| |
The wrong value was returned and the unittest did not cover the stub dylib case.
llvm-svn: 217933
|
|
|
|
|
|
|
|
| |
We already have routines to encode SLEB128 as well as encode/decode ULEB128.
This last function fills out the matrix. I'll need this for some llvm-objdump
work I am doing.
llvm-svn: 217830
|
|
|
|
|
|
|
| |
Use llvm::COFF::BigObjMagic insetad of the string literal.
Also checks the version number.
llvm-svn: 217633
|
|
|
|
|
|
|
| |
identify_magic recognized a COFF bigobj as an import library file.
This patch fixes that.
llvm-svn: 217627
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main difference is the removal of
std::error_code exists(const Twine &path, bool &result);
It was an horribly redundant interface since a file not existing is also a valid
error_code. Now we have an access function that returns just an error_code. This
is the only function that has to be implemented for Unix and Windows. The
functions can_write, exists and can_execute an now just wrappers.
One still has to be very careful using these function to avoid introducing
race conditions (Time of check to time of use).
llvm-svn: 217625
|
|
|
|
| |
llvm-svn: 217618
|
|
|
|
| |
llvm-svn: 217331
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of aligning and moving the CurPtr forward, and then comparing
with End, simply calculate how much space is needed, and compare that
to how much is available.
Hopefully this avoids any doubts about comparing addresses possibly
derived from past the end of the slab array, overflowing, etc.
Also add a test where aligning CurPtr would move it past End.
llvm-svn: 217330
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds to LLVMSupport the capability of writing files with
international characters encoded in the current system encoding. This
is relevant for Windows, where we can either use UTF16 or the current
code page (the legacy Windows international characters). On UNIX, the
file is always saved in UTF8.
This will be used in a patch for clang to thoroughly support response
files creation when calling other tools, addressing PR15171. On
Windows, to correctly support internationalization, we need the
ability to write response files both in UTF16 or the current code
page, depending on the tool we will call. GCC for mingw, for instance,
requires files to be encoded in the current code page. MSVC tools
requires files to be encoded in UTF16.
Patch by Rafael Auler!
llvm-svn: 217068
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An unpleasant surprise while migrating unique_ptrs (see changes in
lib/Object): ErrorOr<int*> was implicitly convertible to
ErrorOr<std::unique_ptr<int>>.
Keep the explicit conversions otherwise it's a pain to convert
ErrorOr<int*> to ErrorOr<std::unique_ptr<int>>.
I'm not sure if there should be more SFINAE on those explicit ctors (I
could check if !is_convertible && is_constructible, but since the ctor
has to be called explicitly I don't think there's any need to disable
them when !is_constructible - they'll just fail anyway. It's the
converting ctors that can create interesting ambiguities without proper
SFINAE). I had to SFINAE the explicit ones because otherwise they'd be
ambiguous with the implicit ones in an explicit context, so far as I
could tell.
The converting assignment operators seemed unnecessary (and similarly
buggy/dangerous) - just rely on the converting ctors to convert to the
right type for assignment instead.
llvm-svn: 217048
|
|
|
|
|
|
|
|
|
| |
behaviour
In theory, alignPtr() could push a pointer beyond the end of the current slab, making
comparisons with that pointer undefined behaviour. Use an integer type to avoid this.
llvm-svn: 216973
|
|
|
|
| |
llvm-svn: 216925
|
|
|
|
|
|
| |
Code reviewed by Chandlerc
llvm-svn: 216703
|
|
|
|
|
|
|
|
| |
MemoryBuffer::getMemBuffer to move initialization now that it returns by unique_ptr instead of raw pointer.
Cleanup/improvements following r216583.
llvm-svn: 216605
|
|
|
|
| |
llvm-svn: 216583
|
|
|
|
|
|
| |
In fact, most users were already using the StringRef version.
llvm-svn: 216575
|
|
|
|
|
|
| |
just letting them be implicitly created.
llvm-svn: 216525
|
|
|
|
| |
llvm-svn: 216422
|
|
|
|
|
|
|
|
|
|
| |
Take a StringRef instead of a "const char *".
Take a "std::error_code &" instead of a "std::string &" for error.
A create static method would be even better, but this patch is already a bit too
big.
llvm-svn: 216393
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch contains the LLVM side of the fix of PR17239.
This bug that happens because the /link (clang-cl.exe argument) is
marked as "consume all remaining arguments". However, when inside a
response file, /link should only consume all remaining arguments inside
the response file where it is located, not the entire command line after
expansion.
My patch will change the semantics of the RemainingArgsClass kind to
always consume only until the end of the response file when the option
originally came from a response file. There are only two options in this
class: dash dash (--) and /link.
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D4899
Patch by Rafael Auler!
llvm-svn: 216280
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D5029
llvm-svn: 216268
|
|
|
|
|
|
| |
std::unique_ptr
llvm-svn: 216223
|
|
|
|
|
|
|
|
| |
It seems unnecessary to have to use an extra branch to check for this special case.
http://reviews.llvm.org/D4945
llvm-svn: 216036
|
|
|
|
| |
llvm-svn: 215855
|
|
|
|
|
|
|
|
|
|
| |
We already handle the no-slabs case when checking whether the current slab
is large enough: if no slabs have been allocated, CurPtr and End are both 0.
alignPtr(0), will still be 0, and so "if (Ptr + Size <= End)" fails.
Differential Revision: http://reviews.llvm.org/D4943
llvm-svn: 215841
|
|
|
|
|
|
|
|
|
| |
This reverts commit r215784 / 3f8a26f6fe16cc76c98ab21db2c600bd7defbbaa.
LLD has 3 StringSaver's, one of which takes a lock when saving the
string... Need to investigate more closely.
llvm-svn: 215790
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This class is generally useful.
In breaking it out, the primary change is that it has been made
non-virtual. It seems like being abstract led to there being 3 different
(2 in llvm + 1 in clang) concrete implementations which disagreed about
the ownership of the saved strings (see the manual call to free() in the
unittest StrDupSaver; yes this is different from the CommandLine.cpp
StrDupSaver which owns the stored strings; which is different from
Clang's StringSetSaver which just holds a reference to a
std::set<std::string> which owns the strings).
I've identified 2 other places in the
codebase that are open-coding this pattern:
memcpy(Alloc.Allocate<char>(strlen(S)+1), S, strlen(S)+1)
I'll be switching them over. They are
* llvm::sys::Process::GetArgumentVector
* The StringAllocator member of YAMLIO's Input class
This also will allow simplifying Clang's driver.cpp quite a bit.
Let me know if there are any other places that could benefit from
StringSaver. I'm also thinking of adding a saveStringRef member for
getting a stable StringRef.
llvm-svn: 215784
|
|
|
|
| |
llvm-svn: 215556
|
|
|
|
|
|
| |
-Wunused-result warnings.
llvm-svn: 215539
|
|
|
|
| |
llvm-svn: 215267
|
|
|
|
| |
llvm-svn: 215243
|