ec7928ef26 use _s to construct static string_views at several places
94de927cab VS10Generator: avoid many string allocations
8ca2504a4d use string_views to avoid memory allocations
761f1adcae check for a valid URL scheme before starting to do any splitting
ef778d77e0 replace std::string::substr() with operations that do not allocate memory
77616f4681 pass cm::string_view to cmVisualStudioSlnParser::ParseTag()
ada6a3226f use cm::string_view for language extension lookups
48adc29721 replace "std::string::find(x) == 0" with cmHasPrefix()
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4501
Once the list of extensions is build the set is just a copy of the vector and
not modified anymore. Use a string_view for the members of the set, which saves
a small amount of memory. It also makes possible to use string_views as lookup
keys, so the callers do not need to create copies for the extensions anymore.
Only one key can match per iteration, avoid any further compares when one match
was already found. While at it entirely avoid that the key and value strings are
copied.
For now, compiler extensions are no longer activated on CMake sources.
However these extensions are still used for various third parties.
This MR is a partial answer to the issue #20454.
1994f950ff cmake: List valid values for --trace-format on the command line
e39766d84a Help: Fix documentation of --trace-format parameter
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4500
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
