This option is always interpreted strictly as a hexadecimal string,
even if it has no prefix that indicates the number format, hence
the existing call to StringRef::getAsInteger(16, ...).
StringRef::getAsInteger(0, ...) consumes a leading "0x" prefix is
present, but when the radix is specified, the radix shouldn't
be included.
Both MS rc.exe and GNU windres accept the language with that
prefix.
Also allow specifying the codepage to llvm-windres with a different
radix, as GNU windres allows that (but MS rc.exe doesn't).
This fixes https://llvm.org/PR51295.
Differential Revision: https://reviews.llvm.org/D107263
(cherry picked from commit 46020f6f0c8aa134002208b2ecf0593b04c46d08)
When the default target arch isn't one that is supported as a
windows target, we want to set a suitable architecture (so that
Clang tests that run plain 'llvm-rc' succeed checks for e.g.
"#ifdef _WIN32" even for llvm builds that default to e.g. ppc64).
But if the default target architecture is usable, don't rewrite it.
(Rewriting it, by e.g. "T.setArch(T.getArch())", normalizes the
spelling of the architecture, e.g. changing i686 to i386. Such a
change can make clang unable to find the right sysroot.)
This can't, unfortunately, practically be tested very well because
it is entirely dependent on the default triple of the llvm build.
Differential Revision: https://reviews.llvm.org/D104589
This is a mechanical change. This actually also renames the
similarly named methods in the SmallString class, however these
methods don't seem to be used outside of the llvm subproject, so
this doesn't break building of the rest of the monorepo.
These serve as a convenient combination of consume_front/back and
startswith_lower/endswith_lower, consistent with other existing
case insensitive methods named <operation>_lower.
Differential Revision: https://reviews.llvm.org/D104218
This primarily parses a different set of options and invokes the same
resource compiler as llvm-rc normally. Additionally, it can convert
directly to an object file (which in MSVC style setups is done with the
separate cvtres tool, or by the linker).
(GNU windres also supports other conversions; from coff object file back
to .res, and from .res or object file back to .rc form; that's not yet
implemented.)
The other bigger complication lies in being able to imply or pass the
intended target triple, to let clang find the corresponding mingw sysroot
for finding include files, and for specifying the default output object
machine format.
It can be implied from the tool triple prefix, like
`<triple>-[llvm-]windres` or picked up from the windres option e.g.
`-F pe-x86-64`. In GNU windres, that option takes BFD style format names
such as pe-i386 or pe-x86-64. As libbfd in binutils doesn't support
Windows on ARM, there's no such canonical name for the ARM targets.
Therefore, as an LLVM specific extension, this option is extended to
allow passing full triples, too.
Differential Revision: https://reviews.llvm.org/D100756
When llvm-rc invokes clang for preprocessing, it uses a target
triple derived from the default target. The test verifies that
e.g. _WIN32 is defined when preprocessing.
If running clang with e.g. -target ppc64le-windows-msvc, that
particular arch/OS combination isn't hooked up, so _WIN32 doesn't
get defined in that configuration. Therefore, the preprocessing
test fails.
Instead make llvm-rc inspect the architecture of the default target.
If it's one of the known supported architectures, use it as such,
otherwise set a default one (x86_64). (Clang can run preprocessing
with an x86_64 target triple, even if the x86 backend isn't
enabled.)
Also remove superfluous llvm:: specifications on enums in llvm-rc.cpp.
Allow opting out from preprocessing with a command line argument.
Update tests to pass -no-preprocess to make it not try to use clang
(which isn't a build level dependency of llvm-rc), but add a test that
does preprocessing under clang/test/Preprocessor.
Update a few options to allow them both joined (as -DFOO) and separate
(-D BR), as rc.exe allows both forms of them.
With the verbose flag set, this prints the preprocessing command
used (which differs from what rc.exe does).
Tests under llvm/test/tools/llvm-rc only test constructing the
preprocessor commands, while tests under clang/test/Preprocessor test
actually running the preprocessor.
Differential Revision: https://reviews.llvm.org/D100755
This matches how such options are most commonly defined in other tools.
This was pointed out in an earlier review a few months ago, that
the llvm-rc td entries felt shouty.
The INCLUDE option is renamed to includepath, to avoid clashing with
the tablegen include directive.
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
llvm-svn: 369013
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
This allows avoiding conflicts between paths that begin with the same
chars as some llvm-rc options (which can be used with either slashes
or dashes).
Differential Revision: https://reviews.llvm.org/D56743
llvm-svn: 351305
Summary:
Before, "[options] <inputs>" is unconditionally appended to the `Name` parameter. It is more flexible to change its semantic to `Usage` and let user customize the usage line.
% llvm-objcopy
...
USAGE: llvm-objcopy <input> [ <output> ] [options] <inputs>
With this patch:
% llvm-objcopy
...
USAGE: llvm-objcopy input [output]
Reviewers: rupprecht, alexshap, jhenderson
Reviewed By: rupprecht
Subscribers: jakehehrlich, mehdi_amini, steven_wu, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D51009
llvm-svn: 344097
This breaks the OpenFlags enumeration into two separate
enumerations: OpenFlags and CreationDisposition. The first
controls the behavior of the API depending on whether or not
the target file already exists, and is not a flags-based
enum. The second controls more flags-like values.
This yields a more easy to understand API, while also allowing
flags to be passed to the openForRead api, where most of the
values didn't make sense before. This also makes the apis more
testable as it becomes easy to enumerate all the configurations
which make sense, so I've added many new tests to exercise all
the different values.
llvm-svn: 334221
When preprocessing resource scripts (which can easily be done outside
of llvm-rc), included headers can leave behind C declarations (despite
preprocessing with -DRC_INVOKED), that can't be parsed by a resource
compiler.
This is handled in all of rc.exe, by parsing the preprocessor output
line markers and ignoring content from files named *.h and *.c,
documented at [1].
In addition to this filtering, strip out any other preprocessor directive
that is left behind (like pragmas) which also can't be handled by the
tokenizer.
The added test uses both standard #line markers (supported by rc.exe) and
GNU style extended line markers, thus this test doesn't pass with rc.exe,
but passes with GNU windres. (Windres on the other hand doesn't filter
out files named *.c, only *.h.)
Differential Revision: https://reviews.llvm.org/D46579
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa381033(v=vs.85).aspx
llvm-svn: 331903
Only support UTF-8 (since LLVM contains UTF-8 parsing support
already, and the code even does that already) and Windows-1252
(where most code points has the same value in unicode). Keep the
existing default as only allowing ASCII input.
Using the option type JoinedOrSeparate, since the real rc.exe
handles options in this form, even if llvm-rc uses Separate for
other similar existing options.
Rename the struct SearchParams to WriterParams since it's now used
for more than just include paths.
Add a missing getResourceTypeName method to the BundleResource class,
to fix error printing from within STRINGTABLE resources (used in
tests).
Differential Revision: https://reviews.llvm.org/D46238
llvm-svn: 331391
We have a few functions that virtually all command wants to run on
process startup/shutdown. This patch adds InitLLVM class to do that
all at once, so that we don't need to copy-n-paste boilerplate code
to each llvm command's main() function.
Differential Revision: https://reviews.llvm.org/D45602
llvm-svn: 330046
It turns out this #include isn't used from Host.h anyway,
but by having it it causes circular include dependencies.
This issues only surfaced while I was working on a separate
patch, so I'm submitting this first so that it's independent
of the other, unrelated patch.
llvm-svn: 318489
Previously we would only look in the current directory for a
resource, which might not be the same as the directory of the
rc file. Furthermore, MSVC rc supports a /I option, and can
also look in the system environment. This patch adds support
for this search algorithm.
Differential Revision: https://reviews.llvm.org/D38740
llvm-svn: 315499
This allows llvm-rc to serialize STRINGTABLE resources.
These are output in an unusual way: we locate them at the end of the
file, and strings are merged into bundles of max 16 strings, depending
on their IDs, language, and characteristics.
Ref: msdn.microsoft.com/en-us/library/windows/desktop/aa381050.aspx
Patch by: Marek Sokolowski
Differential Revision: https://reviews.llvm.org/D38420
llvm-svn: 315112
This allows to process HTML resources defined in .rc scripts and output
them to resulting .res files. Additionally, some infrastructure allowing
to output these files is created.
This is the first resource type we can operate on.
Thanks to Nico Weber for his original work in this area.
Differential Revision: reviews.llvm.org/D37283
llvm-svn: 314538
As for now, the parser supports a limited set of statements and
resources. This will be extended in the following patches.
Thanks to Nico Weber (thakis) for his original work in this area.
This patch was originally submitted as r311175 and got reverted
in r311177 because of the problems with compilation under gcc.
Differential Revision: https://reviews.llvm.org/D36340
llvm-svn: 311184
As for now, the parser supports a limited set of statements and
resources. This will be extended in the following patches.
Thanks to Nico Weber (thakis) for his original work in this area.
Differential Revision: https://reviews.llvm.org/D36340
llvm-svn: 311175
This extends the shell of llvm-rc tool with the ability of tokenization
of the input files. Currently, ASCII and ASCII-compatible UTF-8 files
are supported.
Thanks to Nico Weber (thakis) for his original work in this area.
Differential Revision: https://reviews.llvm.org/D35957
llvm-svn: 310621
This starts the development on one of MS Visual Studio binutils,
Resource Converter. The tool compiles resource scripts (.rc)
into binary resource files (.res).
The current implementation does nothing but parse the command
line arguments. It is going to be extended in the future.
Differential Revision: https://reviews.llvm.org/D35810
llvm-svn: 308940
