terminal/src/inc/LibraryIncludes.h

130 lines
3.1 KiB
C
Raw Normal View History

// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
// clang-format off
#pragma once
#pragma warning(push)
// C
#include <climits>
#include <cwchar>
#include <cwctype>
// STL
// Block minwindef.h min/max macros to prevent <algorithm> conflict
#define NOMINMAX
#include <algorithm>
#include <atomic>
#include <cmath>
#include <deque>
#include <filesystem>
#include <fstream>
#include <functional>
#include <iomanip>
#include <iterator>
#include <list>
#include <map>
#include <memory_resource>
#include <memory>
#include <mutex>
#include <new>
#include <numeric>
#include <optional>
#include <queue>
#include <regex>
#include <set>
#include <shared_mutex>
#include <sstream>
#include <stdexcept>
#include <string_view>
#include <string>
#include <thread>
#include <tuple>
#include <unordered_map>
Add Dynamic Profile Generators (#2603) _**This PR targets the #2515 PR**_. It does that for the sake of diffing. When this PR and #2515 are both ready, I'll merge #2515 first, then change the target of this branch, and merge this one. <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This PR adds support for "dynamic profiles", in accordance with the [Cascading Settings Spec](https://github.com/microsoft/terminal/blob/master/doc/cascadia/Cascading-Default-Settings.md#dynamic-profiles). Currently, we have three types of default profiles that fit the category of dynamic profile generators. These are profiles that we want to create on behalf of the user, but require runtime information to be able to create correctly. Because they require runtime information, we can't ship a static version of these profiles as a part of `defaults.json`. These three profile generators are: * The Powershell Core generator * The WSL Distro generator * The Azure Cloud Shell generator <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #754 * [x] I work here * [x] look at all these **Tests** * [x] Requires documentation to be updated - This is done as part of the parent PR <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments We want to be able to enable the user to edit dynamic profiles that are generated from DPGs. When dynamic profiles are added, we'll add entries for them to the user's `profiles.json`. We do this _without re-serializing_ the settings. Instead, we insert a partial serialization for the profile into the user's settings. ### Remaining TODOs: * Make sure that dynamic profiles appear in the right place in the order of profiles -> #2722 * [x] don't serialize the `colorTable` key for dynamic profiles. * [x] re-parse the user settings string if we've changed it. * Handle changing the default profile to pwsh if it exists on first launch, or file a follow-up issue -> #2721 <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Start dynamically creating profiles * Give the inbox generators a namespace and generally hack this a lot less * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * Serialize the source key * Make the Azure cloud shell a dynamic profile * Make the built-in namespaces public * Add a mechanism for quick-diffing a profile This will be used to generate the json snippets for dynamically generated profiles. * Generate partial serializations of dynamic profiles _not_ in the user settings * Start writing tests for generating dyn profiles * dyn profiles generate GUIDs based on _source * we won't run DPGs when they'd disabled? * Add more DPG tests - TestDontRunDisabledGenerators * Don't layer profiles with a source that's also different * Add another test, DoLayerUserProfilesOnDynamicsWhenSourceMatches * Actually insert new dynamic profiles into the file * Minor cleanup of `Profile::ShouldBeLayered` * Migrate legacy profiles gracefully * using namespace winrt::Windows::UI::Xaml; * _Only_ layer dynamic profiles from user settings, never create * Write a test for migrating dynamic profiles * Comments for dayssssss * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Don't layer a profile if the json doesn't have a GUID * Fix a test I unfixed * get rid of extraneous bois{}; * Piles of PR feedback * Collection of PR nits * PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * In-den-taition! * Some typos, PR nits * Fix this broken defaults case * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * PR nits
2019-09-16 22:34:27 +02:00
#include <unordered_set>
#include <utility>
#include <vector>
// WIL
#include <wil/Common.h>
#include <wil/Result.h>
#include <wil/resource.h>
#include <wil/wistd_memory.h>
#include <wil/stl.h>
#include <wil/com.h>
#include <wil/filesystem.h>
#include <wil/win32_helpers.h>
// GSL
// Block GSL Multi Span include because it both has C++17 deprecated iterators
// and uses the C-namespaced "max" which conflicts with Windows definitions.
#define GSL_MULTI_SPAN_H
#include <gsl/gsl>
#include <gsl/span_ext>
// CppCoreCheck
#include <CppCoreCheck/Warnings.h>
// Chromium Numerics (safe math)
Refactor UiaTextRange For Improved Navigation and Reliability (#4018) ## Summary of the Pull Request This pull request is intended to achieve the following goals... 1) reduce duplicate code 2) remove static functions 3) improve readability 4) improve reliability 5) improve code-coverage for testing 6) establish functioning text buffer navigation in Narrator and NVDA This also required a change to the wrapper class `XamlUiaTextRange` that has been causing issues with Narrator and NVDA. See below for additional context. ## References #3976 - I believe this might have been a result of improperly handling degenerate ranges. Fixed here. #3895 - reduced the duplicate code. No need to separate into different files #2160 - same as #3976 above #1993 - I think just about everything is no longer static ## PR Checklist * [x] Closes #3895, Closes #1993, Closes #3976, Closes #2160 * [x] CLA signed * [x] Tests added/passed ## Detailed Description of the Pull Request / Additional comments ### UiaTextRange - converted endpoints into the COORD system in the TextBuffer coordinate space - `start` is inclusive, `end` is exclusive. A degenerate range is when start == end. - all functions are no longer static - `MoveByUnit()` functions now rely on `MoveEndpointByUnit()` functions - removed unnecessary typedefs like `Endpoint`, `ScreenInfoRow`, etc.. - relied more heavily on existing functionality from `TextBuffer` and `Viewport` ### XamlUiaTextRange - `GetAttributeValue()` must return a special HRESULT that signifies that the requested attribute is not supported. This was the cause of a number of inconsistencies between Narrator and NVDA. - `FindText()` should return `nullptr` if nothing was found. #4373 properly fixes this functionality now that Search is a shared module ### TextBuffer - Word navigation functionality is entirely in `TextBuffer` for proper abstraction - a total of 6 functions are now dedicated to word navigation to get a good understanding of the differences between a "word" in Accessibility and a "word" in selection As an example, consider a buffer with this text in it: " word other " In selection, a "word" is defined as the range between two delimiters, so the words in the example include [" ", "word", " ", "other", " "]. In accessibility , a "word" includes the delimiters after a range of readable characters, so the words in the example include ["word ", "other "]. Additionally, accessibility word navigation must be able to detect if it is on the first or last word. This resulted in a slight variant of word navigation functions that return a boolean instead of a COORD. Ideally, these functions can be consolidated, but that is too risky for a PR of this size as it can have an effect on selection. ### Viewport - the concept of `EndExclusive` is added. This is used by UiaTextRange's `end` anchor as it is exclusive. To signify that the last character in the buffer is included in this buffer, `end` must be one past the end of the buffer. This is `EndExclusive` - Since many functions check if the given `COORD` is in bounds, a flag must be set to allow `EndExclusive` as a valid `COORD` that is in bounds. ### Testing - word navigation testing relies more heavily on TextBuffer tests - additional testing was created for non-movement focused functions of UiaTextRange - The results have been compared to Microsoft Word and some have been verified by UiAutomation/Narrator contacts as expected results. ## Validation Steps Performed Tests pass Narrator works NVDA works
2020-01-31 21:59:39 +01:00
#pragma warning(push)
#pragma warning(disable:4100) // unreferenced parameter
#include <base/numerics/safe_math.h>
Refactor UiaTextRange For Improved Navigation and Reliability (#4018) ## Summary of the Pull Request This pull request is intended to achieve the following goals... 1) reduce duplicate code 2) remove static functions 3) improve readability 4) improve reliability 5) improve code-coverage for testing 6) establish functioning text buffer navigation in Narrator and NVDA This also required a change to the wrapper class `XamlUiaTextRange` that has been causing issues with Narrator and NVDA. See below for additional context. ## References #3976 - I believe this might have been a result of improperly handling degenerate ranges. Fixed here. #3895 - reduced the duplicate code. No need to separate into different files #2160 - same as #3976 above #1993 - I think just about everything is no longer static ## PR Checklist * [x] Closes #3895, Closes #1993, Closes #3976, Closes #2160 * [x] CLA signed * [x] Tests added/passed ## Detailed Description of the Pull Request / Additional comments ### UiaTextRange - converted endpoints into the COORD system in the TextBuffer coordinate space - `start` is inclusive, `end` is exclusive. A degenerate range is when start == end. - all functions are no longer static - `MoveByUnit()` functions now rely on `MoveEndpointByUnit()` functions - removed unnecessary typedefs like `Endpoint`, `ScreenInfoRow`, etc.. - relied more heavily on existing functionality from `TextBuffer` and `Viewport` ### XamlUiaTextRange - `GetAttributeValue()` must return a special HRESULT that signifies that the requested attribute is not supported. This was the cause of a number of inconsistencies between Narrator and NVDA. - `FindText()` should return `nullptr` if nothing was found. #4373 properly fixes this functionality now that Search is a shared module ### TextBuffer - Word navigation functionality is entirely in `TextBuffer` for proper abstraction - a total of 6 functions are now dedicated to word navigation to get a good understanding of the differences between a "word" in Accessibility and a "word" in selection As an example, consider a buffer with this text in it: " word other " In selection, a "word" is defined as the range between two delimiters, so the words in the example include [" ", "word", " ", "other", " "]. In accessibility , a "word" includes the delimiters after a range of readable characters, so the words in the example include ["word ", "other "]. Additionally, accessibility word navigation must be able to detect if it is on the first or last word. This resulted in a slight variant of word navigation functions that return a boolean instead of a COORD. Ideally, these functions can be consolidated, but that is too risky for a PR of this size as it can have an effect on selection. ### Viewport - the concept of `EndExclusive` is added. This is used by UiaTextRange's `end` anchor as it is exclusive. To signify that the last character in the buffer is included in this buffer, `end` must be one past the end of the buffer. This is `EndExclusive` - Since many functions check if the given `COORD` is in bounds, a flag must be set to allow `EndExclusive` as a valid `COORD` that is in bounds. ### Testing - word navigation testing relies more heavily on TextBuffer tests - additional testing was created for non-movement focused functions of UiaTextRange - The results have been compared to Microsoft Word and some have been verified by UiAutomation/Narrator contacts as expected results. ## Validation Steps Performed Tests pass Narrator works NVDA works
2020-01-31 21:59:39 +01:00
#pragma warning(pop)
// Boost
#include "boost/container/small_vector.hpp"
// IntSafe
#define ENABLE_INTSAFE_SIGNED_FUNCTIONS
#include <intsafe.h>
Update til::bitmap to use dynamic_bitset<> + libpopcnt (#5092) This commit replaces `std::vector<bool>` with `dynamic_bitset<>` by @pinam45 (https://github.com/pinam45/dynamic_bitset) and with `libpopcnt` for high-performance bit counting by @kimwalisch (https://github.com/kimwalisch/libpopcnt). * [x] In support of performance, incremental rendering, and Terminal "not speed enough" as well as my sanity relative to `std::vector<bool>` * [x] Tests updated and passed. * [x] `LICENSE`, `NOTICE`, and provenance files updated. * [x] I'm a core contributor. I discussed it with @DHowett-MSFT and cleared the licensing checks before pulling this in. ## Details `std::vector<bool>` provided by the Microsoft VC Runtime is incapable of a great many things. Many of the methods you come to expect off of `std::vector<T>` that are dutifully presented through the `bool` variant will spontaneously fail at some future date because it decides you allocated, resized, or manipulated the `vector<bool>` specialization in an unsupported manner. Half of the methods will straight up not work for filling/resizing in bulk. And you will tear your hair out as it will somehow magically forget the assignment of half the bits you gave it part way through an iteration then assert out and die. As such, to preserve my sanity, I searched for an alternative. I came across the self-contained header-only library `dynamic_bitset` by @pinam45 which appears to do as much of `boost::dynamic_bitset` as I wanted, but without including 400kg of boost libraries. It also has a nifty optional dependency on `libpopcnt` by @kimwalisch that will use processor-specific extensions for rapidly counting bits. @DHowett-MSFT and I briefly discussed how nice `popcnt` would have been on `std::vector<bool>` last week... and now we can have it. (To be fair, I don't believe I'm using it yet... but we'll be able to easily dial in `til::bitmap` soon and not worry about a performance hit if we do have to walk bits and count them thanks to `libpopcnt`.) This PR specifically focuses on swapping the dependencies out and ingesting the new libraries. We'll further tune `til::bitmap` in future pulls as necessary. ## Validation * [x] Ran the automated tests for bitmap. * [x] Ran the terminal manually and it looks fine still.
2020-03-25 03:41:10 +01:00
// LibPopCnt - Fast C/C++ bit population count library (on bits in an array)
#include <libpopcnt.h>
// Dynamic Bitset (optional dependency on LibPopCnt for perf at bit counting)
// Variable-size compressed-storage header-only bit flag storage library.
#pragma warning(push)
#pragma warning(disable:4702) // unreachable code
Update til::bitmap to use dynamic_bitset<> + libpopcnt (#5092) This commit replaces `std::vector<bool>` with `dynamic_bitset<>` by @pinam45 (https://github.com/pinam45/dynamic_bitset) and with `libpopcnt` for high-performance bit counting by @kimwalisch (https://github.com/kimwalisch/libpopcnt). * [x] In support of performance, incremental rendering, and Terminal "not speed enough" as well as my sanity relative to `std::vector<bool>` * [x] Tests updated and passed. * [x] `LICENSE`, `NOTICE`, and provenance files updated. * [x] I'm a core contributor. I discussed it with @DHowett-MSFT and cleared the licensing checks before pulling this in. ## Details `std::vector<bool>` provided by the Microsoft VC Runtime is incapable of a great many things. Many of the methods you come to expect off of `std::vector<T>` that are dutifully presented through the `bool` variant will spontaneously fail at some future date because it decides you allocated, resized, or manipulated the `vector<bool>` specialization in an unsupported manner. Half of the methods will straight up not work for filling/resizing in bulk. And you will tear your hair out as it will somehow magically forget the assignment of half the bits you gave it part way through an iteration then assert out and die. As such, to preserve my sanity, I searched for an alternative. I came across the self-contained header-only library `dynamic_bitset` by @pinam45 which appears to do as much of `boost::dynamic_bitset` as I wanted, but without including 400kg of boost libraries. It also has a nifty optional dependency on `libpopcnt` by @kimwalisch that will use processor-specific extensions for rapidly counting bits. @DHowett-MSFT and I briefly discussed how nice `popcnt` would have been on `std::vector<bool>` last week... and now we can have it. (To be fair, I don't believe I'm using it yet... but we'll be able to easily dial in `til::bitmap` soon and not worry about a performance hit if we do have to walk bits and count them thanks to `libpopcnt`.) This PR specifically focuses on swapping the dependencies out and ingesting the new libraries. We'll further tune `til::bitmap` in future pulls as necessary. ## Validation * [x] Ran the automated tests for bitmap. * [x] Ran the terminal manually and it looks fine still.
2020-03-25 03:41:10 +01:00
#include <dynamic_bitset.hpp>
#pragma warning(pop)
Update til::bitmap to use dynamic_bitset<> + libpopcnt (#5092) This commit replaces `std::vector<bool>` with `dynamic_bitset<>` by @pinam45 (https://github.com/pinam45/dynamic_bitset) and with `libpopcnt` for high-performance bit counting by @kimwalisch (https://github.com/kimwalisch/libpopcnt). * [x] In support of performance, incremental rendering, and Terminal "not speed enough" as well as my sanity relative to `std::vector<bool>` * [x] Tests updated and passed. * [x] `LICENSE`, `NOTICE`, and provenance files updated. * [x] I'm a core contributor. I discussed it with @DHowett-MSFT and cleared the licensing checks before pulling this in. ## Details `std::vector<bool>` provided by the Microsoft VC Runtime is incapable of a great many things. Many of the methods you come to expect off of `std::vector<T>` that are dutifully presented through the `bool` variant will spontaneously fail at some future date because it decides you allocated, resized, or manipulated the `vector<bool>` specialization in an unsupported manner. Half of the methods will straight up not work for filling/resizing in bulk. And you will tear your hair out as it will somehow magically forget the assignment of half the bits you gave it part way through an iteration then assert out and die. As such, to preserve my sanity, I searched for an alternative. I came across the self-contained header-only library `dynamic_bitset` by @pinam45 which appears to do as much of `boost::dynamic_bitset` as I wanted, but without including 400kg of boost libraries. It also has a nifty optional dependency on `libpopcnt` by @kimwalisch that will use processor-specific extensions for rapidly counting bits. @DHowett-MSFT and I briefly discussed how nice `popcnt` would have been on `std::vector<bool>` last week... and now we can have it. (To be fair, I don't believe I'm using it yet... but we'll be able to easily dial in `til::bitmap` soon and not worry about a performance hit if we do have to walk bits and count them thanks to `libpopcnt`.) This PR specifically focuses on swapping the dependencies out and ingesting the new libraries. We'll further tune `til::bitmap` in future pulls as necessary. ## Validation * [x] Ran the automated tests for bitmap. * [x] Ran the terminal manually and it looks fine still.
2020-03-25 03:41:10 +01:00
// {fmt}, a C++20-compatible formatting library
#include <fmt/format.h>
#include <fmt/compile.h>
#define USE_INTERVAL_TREE_NAMESPACE
#include <IntervalTree.h>
// SAL
#include <sal.h>
// WRL
// Microsoft::WRL::Details::StaticStorage contains a programming error.
// The author attempted to create a properly aligned backing storage for a type T,
// but instead of giving the member the proper alignas, the struct got it.
// The compiler doesn't like that. --> Suppress the warning.
#pragma warning(push)
#pragma warning(disable: 4324) // structure was padded due to alignment specifier
#include <wrl.h>
#pragma warning(pop)
Move ConPTY to use til::bitmap (#5024) ## Summary of the Pull Request Moves the ConPTY drawing mechanism (`VtRenderer`) to use the fine-grained `til::bitmap` individual-dirty-bit tracking mechanism instead of coarse-grained rectangle unions to improve drawing performance by dramatically reducing the total area redrawn. ## PR Checklist * [x] Part of #778 and #1064 * [x] I work here * [x] Tests added and updated. * [x] I'm a core contributor ## Detailed Description of the Pull Request / Additional comments - Converted `GetDirtyArea()` interface from `IRenderEngine` to use a vector of `til::rectangle` instead of the `SMALL_RECT` to banhammer inclusive rectangles. - `VtEngine` now holds and operates on the `til::bitmap` for invalidation regions. All invalidation operation functions that used to be embedded inside `VtEngine` are deleted in favor of using the ones in `til::bitmap`. - Updated `VtEngine` tracing to use new `til::bitmap` on trace and the new `to_string()` methods detailed below. - Comparison operators for `til::bitmap` and complementary tests. - Fixed an issue where the dirty rectangle shortcut in `til::bitmap` was set to 0,0,0,0 by default which means that `|=` on it with each `set()` operation was stretching the rectangle from 0,0. Now it's a `std::optional` so it has no value after just being cleared and will build from whatever the first invalidated rectangle is. Complementary tests added. - Optional run caching for `til::bitmap` in the `runs()` method since both VT and DX renderers will likely want to generate the set of runs at the beginning of a frame and refer to them over and over through that frame. Saves the iteration and creation and caches inside `til::bitmap` where the chance of invalidation of the underlying data is known best. It is still possible to iterate manually with `begin()` and `end()` from the outside without caching, if desired. Complementary tests added. - WEX templates added for `til::bitmap` and used in tests. - `translate()` method for `til::bitmap` which will slide the dirty points in the direction specified by a `til::point` and optionally back-fill the uncovered area as dirty. Complementary tests added. - Moves all string generation for `til` types `size`, `point`, `rectangle`, and `some` into a `to_string` method on each object such that it can be used in both ETW tracing scenarios AND in the TAEF templates uniformly. Adds a similar method for `bitmap`. - Add tagging to `_bitmap_const_iterator` such that it appears as a valid **Input Iterator** to STL collections and can be used in a `std::vector` constructor as a range. Adds and cleans up operators on this iterator to match the theoretical requirements for an **Input Iterator**. Complementary tests added. - Add loose operators to `til` which will allow some basic math operations (+, -, *, /) between `til::size` and `til::point` and vice versa. Complementary tests added. Complementary tests added. - Adds operators to `til::rectangle` to allow scaling with basic math operations (+, -, *) versus `til::size` and translation with basic math operations (+, -) against `til::point`. Complementary tests added. - In-place variants of some operations added to assorted `til` objects. Complementary tests added. - Update VT tests to compare invalidation against the new map structure instead of raw rectangles where possible. ## Validation Steps Performed - Wrote additional til Unit Tests for all additional operators and functions added to the project to support this operation - Updated the existing VT renderer tests - Ran perf check
2020-03-23 16:57:54 +01:00
// WEX/TAEF testing
// Include before TIL if we're unit testing so it can light up WEX/TAEF template extensions
#ifdef UNIT_TESTING
#include <WexTestClass.h>
#endif
// TIL - Terminal Implementation Library
#ifndef BLOCK_TIL // Certain projects may want to include TIL manually to gain superpowers
#include "til.h"
#endif
#pragma warning(pop)
// clang-format on