Old implementation uses involved Flex input management technique that
requires usage of obsolete YY_INPUT macro. This causes a lot of useless
allocations and byte-by-byte scanning. New implementation avoids those
hacks, it uses yy_scan_string() API to setup Flex input. Also it fixes
reporting of syntax error position and corresponding tests.
This option has been broken since commit b9f9915516 (cmMakefile: Remove
VarUsageStack., 2015-05-17, v3.3.0-rc1~52^2). That commit removed the
check that an initialized variable has actually been used and caused the
option to warn on every variable ever set. This was not caught by the
test suite because the test for the feature only checked that warnings
appear when needed and not that they do not appear when not needed.
The option was never very practical to use. Remove it to avoid the
runtime cost of usage tracking and checks for every variable (which we
were doing even when the option was not used).
7d6861f367 fileapi: Extend codemodel targets with language standard
ba835874a4 Add backtrace support for language standard
e43486a639 cmGeneratorTarget: Clarify name of language property lookup helper
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4798
Issue a deprecation warning on calls to `cmake_minimum_required` or
`cmake_policy` that set policies based on versions older than 2.8.12.
Note that the effective policy version includes `...<max>` treatment.
This is important in combination with commit ca24b70d31 (Export: Specify
a policy range in exported files, 2020-05-16, v3.18.0-rc1~133^2).
742ff97f80 Refactor language standard computation
0892c798f7 cmMakefile: Change CompileFeatureKnown to take target name instead of target
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4803
The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for policies
introduced in CMake 3.11 and below to encourage projects to port away
from setting policies to OLD.
Adds a flag to indicate that pipe output from a custom command should be
interpreted as UTF-8 encoded. This change does not introduce a public
way to set the flag, but generators that create internally-generated
commands know if they are calling cmake, which uses UTF-8 pipes.
MSBuild added support for interpreting output of PreBuildEvent,
PreLinkEvent, PostBuildEvent, and CustomBuildStep as UTF-8. This change
will appear in Visual Studio 16.6 Preview 3. It is opt-in, and you need
to add the StdOutEncoding tag. MSBuild treats these as property bags so
if we emit the tag for earlier versions of Visual Studio it would be
safely ignored. This change emits the StdOutEncoding tag and sets it to
UTF-8 whenever the custom command UTF-8 pipe flag is set. This fixes
globalization issues when the output from cmake contained characters
that required MSBuild to interpret as UTF-8 before displaying them.
Arguably, many of these are bugs in `clang-tidy`. An if/else tree with
other conditionals between cloned blocks may be relying on the
intermediate logic to fall out of the case and inverting this logic may
be non-trivial.
See: https://bugs.llvm.org/show_bug.cgi?id=44165
CMake 3.16 and below allow multiple `export()` calls with the same output
file even without using `APPEND`. The implementation worked by accident
by leaking memory. Refactoring in commit 5444a8095d (cmGlobalGenerator:
modernize memrory managemenbt, 2019-12-29, v3.17.0-rc1~239^2) cleaned up
that memory leak and converted it to a use-after-free instead.
The problem is caused by using the `cmGlobalGenerator::BuildExportSets`
map to own `cmExportBuildFileGenerator` instances. It can own only
one instance per output FILE name at a time, so repeating use of the
same file now frees the old `cmExportBuildFileGenerator` instance
and leaves the pointer in the `cmMakefile::ExportBuildFileGenerators`
vector dangling. Move ownership of the instances into `cmMakefile`'s
vector since its entries are not replaced on a repeat output FILE.
In future work we should introduce a policy to error out on this case.
For now simply fix the use-after-free to restore CMake <= 3.16 behavior.
Fixes: #20469
For users of CMake who want to optimize their scripts if they take a
while to run, this commit adds the ability to output profiling data.
To enable this output, it adds the two command line parameters
to select the output path and format.
This commit adds the first profiling format of type ``google-trace``,
which is the output is a JSON file containing Duration events as per the
Google Trace Format specification:
https://docs.google.com/document/d/1CvAClvFfyA5R-
PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview#
The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for policies
introduced in CMake 3.10 and below to encourage projects to port away
from setting policies to OLD.
