Part of https://github.com/Azure/azure-sdk-for-cpp/issues/1277, checking what types of warnings the CI emits.
Verified all SDK product `.cpp`, `.hpp`, `.txt`, and `.md` files, primarily focused on azure-core. They are all clean now. There are some exceptions that needs to be added for keyvault and storage, but they are false positives, so not a concern.
> `cspell lint --config .vscode/cspell.json *.hpp */**/*.hpp`
CSpell: Files checked: 188, Issues found: 0 in 0 files
> `cspell lint --config .vscode/cspell.json *.cpp */**/*.cpp`
CSpell: Files checked: 186, Issues found: 88 in 15 files (keyvault and storage false positives, or tests)
> `cspell lint --config .vscode/cspell.json *.md */**/*.md`
CSpell: Files checked: 45, Issues found: 5 in 2 files (eng/common)
> `cspell lint --config .vscode/cspell.json *.txt */**/*.txt`
CSpell: Files checked: 44, Issues found: 0 in 0 files
> `cspell lint --config .vscode/cspell.json *.* */**/*`
CSpell: Files checked: 646, Issues found: 328 in 69 files (most of these are in eng\docs\api\assets\style.css or eng/common)
Deprioritize and ignored the errors from the test files (including test resource json files), and `eng/common` since those need to be centrally fixed.
* Removed the `Azure::Core::Http::Request` ctor overload that takes both a `bodyStream` and a `bufferedDownload` boolean since it is not used anywhere.
* Add back the unit tests by making them friends.
* Add back line at end of file.
* Check for context cancellation in more places within the winhttp transport layer before each I/O call.
* Update cspell to add exceptions to false positives.
* Address PR feedback.
* Do not check for context cancellation before querying the response headers.
Posix platforms do not generate secure random bytes with random_device().
On posix platforms use the openSSL random byte generator which generates cryptographically secure random bytes
**NOTE**: Once the assert work is done this abort() will be switched over to assert.
* Update vcpkg ports to use a manifest json file instead of a CONTROL file.
* Update vcpkg ports to use a manifest json file instead of a CONTROL file
for remaining packages.
* Add the new vcpkg manifet json files and also update the template
package.
* Update paths in the cmake and eng scripts to find the right file now
that CONTROL is gone.
* Update the Azure.Core changelog to be more consise and complete for the beta.8
release.
* Fix the new feature section since `GetDeadline` was added this release.
* Add note about types moving between header files.
* Make identity related fixes.
Co-authored-by: Victor Vazquez <victor.vazquez@microsoft.com>
* Changed the `Azure::Core::Http::HttpMethod` regular enum into an extensible enum class.
* Update CL to mention removal of HttpMethodToString.
* Delete the default http method ctor.
* progress
* missing
* fix comp errors
* remove comments
* Bad merge with my recent changes to master
* Format
Co-authored-by: Ahson Khan <ahson_ahmedk@yahoo.com>
Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com>
This would unblock #2010.
Closes#2032.
Closes#1880.
I know this comes out of the blue, but it seems to me the right change to do. This is a proposal, let me know what you think.
First, I started with the fact that we need to make `CancelWhen()` public.
Then, I realized that I don't like the `CancelWhen()` naming. `CancelAt()` is better?
But `CancelAt()` sounds like an order to do something, not as getter.
So, it should be named `Get...`. `GetCancelWhen()`? `GetCancelAt()`? Sounds strage.
`GetDeadline()` - not bad, bit it is not that clear, what the deadline is.
And I looked at the `WithDeadline()` method. And in comment, the first line is `@brief Create a context with expiration.`.
"Expiration" sounds better explanation for the essense of the "deadline".
So, I went with `GetExpiration()`. I think "Expiration" is also a better name, because should we want to add the method called "bool IsExpired()", it comes naturally using the existing terminology, sounds better than "`IsPastDeadline()`".
Next thing - if we have "`GetExpiration()`", it is strange to have a method called `Get()`. So, we have `WithExpiration()` and `WithValue()`. So, it sounds like the getter should be called `GetValue()`. I did that rename as well.
Then, I looked at "`With...`" method naming. It is a factory method. If for getters we have `Get`, then for factory methods we should have `Create`. So, I renamed `WithExpiration()` and `WithValue()` to `CreateWithExpiration()` and `CreateWithValue()`.
Then I looked at `Context::time_point` typedef. First, in general, if we can avoid public typedefs, it is better, because we don't need to document them and worry if we broke client code when we change them.
Second, it is strange that we use `Azure::DateTime` everywhere, but not in context.
So, I replaced it with `Azure::DateTime`. It is good because it allows us to drop to/from epoch conversions (#1880), and really all that extra dance we do to cast to representation and back to datetime is the ways to stay within legal type casting limits of compiler type declaration, while in reality there isn't much that is happening in the code: `DateTime` is essentially an `int64`, and with all these conversions to epoch time, then to representation and back, compiler does not generate real code, it still operates with that only `int64`.
Why we cast to `DateTime::rep` and back at all? Context stores it as `atomic`, and I am not questioning that. You can't get `std::atomic<DateTime>` today explicitly, so we "extract" representation (`int64`) and store it as `std::atomic<DateTime::rep>`, which is the same thing as `std::atomic_int64`.
-- Update: --
1. "Expiration" => "Deadline" (Jeffrey's request)
2. Added `Context::HasExpiration()` (response to Jinming) // plus, we do have `HasValue()` so why not have `HasDeadline()`.
3. `WithDeadline()`, `WithValue` => Two overloads of `CreateChildContext()` (my own initiative).
-- Update 2: --
`CreateChildContext()` => `WithDeadline()`, `WithValue`
-- Update 3: --
Removed `HasDeadline()`
