CSSTest.SelectorParse fails on GitHub Actions but not on Travis or on
any developer systems. Disable the test until we can determine what's
going on here.
This is implemented using several URL path helper functions. The
functions aren't strictly necessary, but the functions make it easier
to implement and test the resolution functionality.
The url class is a URL parser and container class that makes working
with URLs easier. In particular, the resolve() function makes working
with base URLs and possibly relative URLs easier.
url instances are meant to be immutable. If users need to modify a
url instance they can do so by creating a new url instance. See the
resolve() implementation for a non-trivial example of how to build a
new url instance using existing url instances.
Note that the current implementation is inefficient due to each URL
component requiring its own separate memory allocation. We should
consider re-writing this to use tstring_view once that branch is
merged into master.
Add codepoint utility functions that test whether a codepoint belongs
to a set of codepoints (e.g., the valid codepoints for a URL scheme).
Most of these functions are implemented using a compact lookup table
so should be reasonably fast.
The functions are based on similar functions from the css-parser branch
that were introduced in commit 1698324920. We'll want to merge these
sets of functions together once the branches are merged.
tstring_view is a string reference type that provides a view into a
string that is owned elsewhere (e.g., by a std::string object).
tstring_view implements the same interface as std::base_string_view in
the standard library. When litehtml moves to C++17 consider replacing
the tstring_view implementation with the standard library
implementations (e.g., via a using statement).
GoogleTest provides a number of nice features (such as autodiscovery)
that make writing and running tests easier and less tedious. This
patch converts the litehtml tests over to use GoogleTest. Note that
the conversion is mostly mechanical -- no attempt has been made to
make the tests "idiomatic" GoogleTests.
Most of the CMake changes are based on code from the GoogleTest
documentation, specifically the "Quickstart: Building with CMake"
guide:
https://google.github.io/googletest/quickstart-cmake.html
