Merge pull request #897 from MicrosoftDocs/master

merge to live

Author: TerryGLee

docs/code-quality/C26400.md

@@ -17,21 +17,6 @@ caps.latest.revision: 0
 author: "corob-msft"
 ms.author: "corob"
 manager: "ghogen"
-translation.priority.ht: 
-  - "de-de"
-  - "es-es"
-  - "fr-fr"
-  - "it-it"
-  - "ja-jp"
-  - "ko-kr"
-  - "ru-ru"
-  - "zh-cn"
-  - "zh-tw"
-translation.priority.mt: 
-  - "cs-cz"
-  - "pl-pl"
-  - "pt-br"
-  - "tr-tr"
 ---
 # C26400 NO_RAW_POINTER_ASSIGNMENT
 This check helps to enforce the *rule I.11: Never transfer ownership by a raw pointer (T\*)*, which is a subset of the rule *R.3: A raw pointer (a T\*) is non-owning.* Specifically, it warns on any call to operator `new` which saves its result in a variable of raw pointer type. It also warns on calls to functions that return `gsl::owner<T>` if their results are assigned to raw pointers. The idea here is that you should clearly state ownership of memory resources. For more information, see the [C++ Core Guidelines](http://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#r-resource-management).  

docs/code-quality/C26401.md

@@ -17,21 +17,6 @@ caps.latest.revision: 0
 author: "corob-msft"
 ms.author: "corob"
 manager: "ghogen"
-translation.priority.ht: 
-  - "de-de"
-  - "es-es"
-  - "fr-fr"
-  - "it-it"
-  - "ja-jp"
-  - "ko-kr"
-  - "ru-ru"
-  - "zh-cn"
-  - "zh-tw"
-translation.priority.mt: 
-  - "cs-cz"
-  - "pl-pl"
-  - "pt-br"
-  - "tr-tr"
 ---
 # C26401 DONT_DELETE_NON_OWNER
 This check detects places where moving to `owner<T>` can be a good option for the first stage of refactoring. Like C26400 it enforces rules I.11 and R.3, but focuses on the “release” portion of the pointer lifetime. It warns on any call to operator `delete` if its target is neither an `owner<T>` nor an implicitly assumed owner. For more information, see [C26400](c26400.md) regarding the auto declarations. This does include expressions that refer to global variables, formals, and so on. 

docs/code-quality/C26402.md

@@ -17,21 +17,6 @@ caps.latest.revision: 0
 author: "corob-msft"
 ms.author: "corob"
 manager: "ghogen"
-translation.priority.ht: 
-  - "de-de"
-  - "es-es"
-  - "fr-fr"
-  - "it-it"
-  - "ja-jp"
-  - "ko-kr"
-  - "ru-ru"
-  - "zh-cn"
-  - "zh-tw"
-translation.priority.mt: 
-  - "cs-cz"
-  - "pl-pl"
-  - "pt-br"
-  - "tr-tr"
 ---
 # C26401 DONT_DELETE_NON_OWNER
 This check detects places where moving to `owner<T>` can be a good option for the first stage of refactoring. Like C26400 it enforces rules I.11 and R.3, but focuses on the “release” portion of the pointer lifetime. It warns on any call to operator `delete` if its target is neither an `owner<T>` nor an implicitly assumed owner. For more information, see [C26400](c26400.md) regarding the auto declarations. This does include expressions that refer to global variables, formals, and so on. 

docs/code-quality/C26403.md

@@ -17,21 +17,6 @@ caps.latest.revision: 0
 author: "corob-msft"
 ms.author: "corob"
 manager: "ghogen"
-translation.priority.ht: 
-  - "de-de"
-  - "es-es"
-  - "fr-fr"
-  - "it-it"
-  - "ja-jp"
-  - "ko-kr"
-  - "ru-ru"
-  - "zh-cn"
-  - "zh-tw"
-translation.priority.mt: 
-  - "cs-cz"
-  - "pl-pl"
-  - "pt-br"
-  - "tr-tr"
 ---
 # C26403 RESET_OR_DELETE_OWNER
 Owner pointers are like unique pointers: they own a resource exclusively, and manage release of the resource, as well as its transfers to other owners. This check validates that a local owner pointer properly maintains its resource through all execution paths in a function. If the resource was not transferred to another owner, or was not explicitly release, the checker warns, and points to the declaration of the pointer variable.

docs/code-quality/C26404.md

@@ -17,21 +17,6 @@ caps.latest.revision: 0
 author: "corob-msft"
 ms.author: "corob"
 manager: "ghogen"
-translation.priority.ht: 
-  - "de-de"
-  - "es-es"
-  - "fr-fr"
-  - "it-it"
-  - "ja-jp"
-  - "ko-kr"
-  - "ru-ru"
-  - "zh-cn"
-  - "zh-tw"
-translation.priority.mt: 
-  - "cs-cz"
-  - "pl-pl"
-  - "pt-br"
-  - "tr-tr"
 ---
 # C26404  DONT_DELETE_INVALID
 Once owner pointer releases or transfers its resource, it gets into an “invalid” state. 

docs/code-quality/C26405.md

@@ -17,21 +17,6 @@ caps.latest.revision: 0
 author: "corob-msft"
 ms.author: "corob"
 manager: "ghogen"
-translation.priority.ht: 
-  - "de-de"
-  - "es-es"
-  - "fr-fr"
-  - "it-it"
-  - "ja-jp"
-  - "ko-kr"
-  - "ru-ru"
-  - "zh-cn"
-  - "zh-tw"
-translation.priority.mt: 
-  - "cs-cz"
-  - "pl-pl"
-  - "pt-br"
-  - "tr-tr"
 ---
 # C26405  DONT_ASSIGN_TO_VALID
 If an owner pointer already points to a valid memory buffer, it must not be assigned to another value without releasing its current resource first. Such assignment may lead to a resource leak even if the resource address is copied into some raw pointer (because raw pointers shouldn’t release resources).

docs/code-quality/C26406.md

@@ -17,21 +17,6 @@ caps.latest.revision: 0
 author: "corob-msft"
 ms.author: "corob"
 manager: "ghogen"
-translation.priority.ht: 
-  - "de-de"
-  - "es-es"
-  - "fr-fr"
-  - "it-it"
-  - "ja-jp"
-  - "ko-kr"
-  - "ru-ru"
-  - "zh-cn"
-  - "zh-tw"
-translation.priority.mt: 
-  - "cs-cz"
-  - "pl-pl"
-  - "pt-br"
-  - "tr-tr"
 ---
 # C26406  DONT_ASSIGN_RAW_TO_OWNER
 Owners are initialized from allocations or from other owners. Assigning a value from a raw pointer to an owner pointer is not allowed. Raw pointers don’t guarantee ownership transfer; there is still may be an original owner which holds the resource and will attempt to release it. Note that assigning a value from owner to a raw pointer is fine; raw pointers are valid clients to access resources, but not to manage them.

docs/code-quality/C26407.md

@@ -17,21 +17,6 @@ caps.latest.revision: 0
 author: "corob-msft"
 ms.author: "corob"
 manager: "ghogen"
-translation.priority.ht: 
-  - "de-de"
-  - "es-es"
-  - "fr-fr"
-  - "it-it"
-  - "ja-jp"
-  - "ko-kr"
-  - "ru-ru"
-  - "zh-cn"
-  - "zh-tw"
-translation.priority.mt: 
-  - "cs-cz"
-  - "pl-pl"
-  - "pt-br"
-  - "tr-tr"
 ---
 # C26407 DONT_HEAP_ALLOCATE_UNNECESSARILY
 To avoid unnecessary use of pointers we try to detect common patterns of local allocations, for example when the result of a call to operator new is stored in a local variable and later explicitly deleted. This supports the rule R.5: *Prefer scoped objects, don't heap-allocate unnecessarily*. The suggested fix is to use an RAII type instead of a raw pointer and allow it to deal with resources. If an allocation is a single object, then it may be obviously unnecessary and a local variable of the object’s type would work better.

docs/code-quality/C26408.md

@@ -17,21 +17,6 @@ caps.latest.revision: 3
 author: "corob-msft"
 ms.author: "corob"
 manager: "ghogen"
-translation.priority.ht: 
-  - "de-de"
-  - "es-es"
-  - "fr-fr"
-  - "it-it"
-  - "ja-jp"
-  - "ko-kr"
-  - "ru-ru"
-  - "zh-cn"
-  - "zh-tw"
-translation.priority.mt: 
-  - "cs-cz"
-  - "pl-pl"
-  - "pt-br"
-  - "tr-tr"
 ---
 # C26408 NO_MALLOC_FREE
 This warning flags places where `malloc` or `free` is invoked explicitly in accordance to R.10: Avoid `malloc` and `free`. One potential fix for such warnings would be to use [std::make_unique](/cpp/standard-library/memory-functions#make_unique) to avoid explicit creation and destruction of objects. If such a fix is not acceptable, operator [new and delete](/cpp/cpp/new-and-delete-operators) should be preferred. In some cases, if exceptions are not welcome, `malloc` and `free` can be replaced with the nothrow version of operators `new` and `delete`.

docs/code-quality/C26409.md

@@ -17,21 +17,6 @@ caps.latest.revision: 3
 author: "corob-msft"
 ms.author: "corob"
 manager: "ghogen"
-translation.priority.ht: 
-  - "de-de"
-  - "es-es"
-  - "fr-fr"
-  - "it-it"
-  - "ja-jp"
-  - "ko-kr"
-  - "ru-ru"
-  - "zh-cn"
-  - "zh-tw"
-translation.priority.mt: 
-  - "cs-cz"
-  - "pl-pl"
-  - "pt-br"
-  - "tr-tr"
 ---
 # C26409 NO_NEW_DELETE
   Even if code is clean of calls to malloc() and free() we still suggest that you consider better options than explicit use of operators [new and delete](/cpp/cpp/new-and-delete-operators). See more details in the description of the rule *R.11: Avoid calling new and delete explicitly*. The ultimate fix is to start using smart pointers with appropriate factory methods, such as [std::make_unique](/cpp/standard-library/memory-functions#make_unique).

docs/code-quality/C26410.md

@@ -17,21 +17,6 @@ caps.latest.revision: 0
 author: "corob-msft"
 ms.author: "corob"
 manager: "ghogen"
-translation.priority.ht: 
-  - "de-de"
-  - "es-es"
-  - "fr-fr"
-  - "it-it"
-  - "ja-jp"
-  - "ko-kr"
-  - "ru-ru"
-  - "zh-cn"
-  - "zh-tw"
-translation.priority.mt: 
-  - "cs-cz"
-  - "pl-pl"
-  - "pt-br"
-  - "tr-tr"
 ---
 # C26410  NO_REF_TO_CONST_UNIQUE_PTR
 Generally, references to const unique pointer are meaningless. They can safely be replaced by a raw reference or a pointer.

docs/code-quality/C26411.md

@@ -17,21 +17,6 @@ caps.latest.revision: 0
 author: "corob-msft"
 ms.author: "corob"
 manager: "ghogen"
-translation.priority.ht: 
-  - "de-de"
-  - "es-es"
-  - "fr-fr"
-  - "it-it"
-  - "ja-jp"
-  - "ko-kr"
-  - "ru-ru"
-  - "zh-cn"
-  - "zh-tw"
-translation.priority.mt: 
-  - "cs-cz"
-  - "pl-pl"
-  - "pt-br"
-  - "tr-tr"
 ---
 # CC26411  NO_REF_TO_UNIQUE_PTR
 Passing a unique pointer by reference assumes that its resource may be released or transferred inside of a target function. If function uses its parameter only to access the resource, it is safe to pass a raw pointer or a reference.

docs/code-quality/C26481.md

@@ -17,21 +17,6 @@ caps.latest.revision: 0
 author: "corob-msft"
 ms.author: "corob"
 manager: "ghogen"
-translation.priority.ht: 
-  - "de-de"
-  - "es-es"
-  - "fr-fr"
-  - "it-it"
-  - "ja-jp"
-  - "ko-kr"
-  - "ru-ru"
-  - "zh-cn"
-  - "zh-tw"
-translation.priority.mt: 
-  - "cs-cz"
-  - "pl-pl"
-  - "pt-br"
-  - "tr-tr"
 ---
 # C26481 NO_POINTER_ARITHMETIC
 This check supports the rule *I.13: Do not pass an array as a single pointer*. Whenever raw pointers are used in arithmetic operations they should be replaced with safer kinds of buffers like `span<T>` or `vector<T>`.

docs/code-quality/C26485.md

@@ -17,21 +17,6 @@ caps.latest.revision: 0
 author: "corob-msft"
 ms.author: "corob"
 manager: "ghogen"
-translation.priority.ht: 
-  - "de-de"
-  - "es-es"
-  - "fr-fr"
-  - "it-it"
-  - "ja-jp"
-  - "ko-kr"
-  - "ru-ru"
-  - "zh-cn"
-  - "zh-tw"
-translation.priority.mt: 
-  - "cs-cz"
-  - "pl-pl"
-  - "pt-br"
-  - "tr-tr"
 ---
 # C26485 NO_ARRAY_TO_POINTER_DECAY
 Like C26481, this check helps to enforce the rule I.13: *Do not pass an array as a single pointer* by detecting places where static array type information gets lost due to decay to a raw pointer. zstring and czstring types are not excluded.

docs/code-quality/all-rules-rule-set.md

@@ -13,21 +13,6 @@ caps.latest.revision: 9
 author: "gewarren"
 ms.author: "gewarren"
 manager: "ghogen"
-translation.priority.ht: 
-  - "de-de"
-  - "es-es"
-  - "fr-fr"
-  - "it-it"
-  - "ja-jp"
-  - "ko-kr"
-  - "ru-ru"
-  - "zh-cn"
-  - "zh-tw"
-translation.priority.mt: 
-  - "cs-cz"
-  - "pl-pl"
-  - "pt-br"
-  - "tr-tr"
 ---
 # All Rules rule set
 The All Rules rule set contains all of the rules for both native and managed code. The rule set includes all the rules that are described  in the following topics:  

docs/code-quality/analyzing-c-cpp-code-quality-by-using-code-analysis.md

@@ -21,21 +21,6 @@ caps.latest.revision: 35
 author: "corob-msft"
 ms.author: "corob"
 manager: "ghogen"
-translation.priority.ht: 
-  - "de-de"
-  - "es-es"
-  - "fr-fr"
-  - "it-it"
-  - "ja-jp"
-  - "ko-kr"
-  - "ru-ru"
-  - "zh-cn"
-  - "zh-tw"
-translation.priority.mt: 
-  - "cs-cz"
-  - "pl-pl"
-  - "pt-br"
-  - "tr-tr"
 ---
 # Analyzing C/C++ Code Quality by Using Code Analysis
 You can improve your C/C++ code by using the code analysis in Visual Studio to find and fix code defects.  

docs/code-quality/analyzing-managed-code-quality-by-using-code-analysis.md

@@ -16,21 +16,6 @@ caps.latest.revision: 24
 author: "gewarren"
 ms.author: "gewarren"
 manager: "ghogen"
-translation.priority.ht: 
-  - "de-de"
-  - "es-es"
-  - "fr-fr"
-  - "it-it"
-  - "ja-jp"
-  - "ko-kr"
-  - "ru-ru"
-  - "zh-cn"
-  - "zh-tw"
-translation.priority.mt: 
-  - "cs-cz"
-  - "pl-pl"
-  - "pt-br"
-  - "tr-tr"
 ---
 # Analyzing Managed Code Quality by Using Code Analysis
 You can use the code analysis tools in Visual Studio to discover potential issues in your code, such as non-secure data access, usage violations, and design problems. Code analysis works on .NET Framework, native (C and C++), and database applications. Code analysis for managed code organizes rules in *rule sets* that target specific coding issues.  

docs/code-quality/annotating-function-behavior.md

@@ -25,21 +25,6 @@ caps.latest.revision: 11
 author: "corob-msft"
 ms.author: "corob"
 manager: "ghogen"
-translation.priority.ht: 
-  - "de-de"
-  - "es-es"
-  - "fr-fr"
-  - "it-it"
-  - "ja-jp"
-  - "ko-kr"
-  - "ru-ru"
-  - "zh-cn"
-  - "zh-tw"
-translation.priority.mt: 
-  - "cs-cz"
-  - "pl-pl"
-  - "pt-br"
-  - "tr-tr"
 ---
 # Annotating Function Behavior
 In addition to annotating [function parameters and return values](../code-quality/annotating-function-parameters-and-return-values.md), you can annotate properties of the whole function.