BASELINE: Update Chromium to 60.0.3112.70

Change-Id: I9911c2280a014d4632f254857876a395d4baed2d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>

4 files changed, 67 insertions, 16 deletions

diff --git a/chromium/styleguide/c++/c++.md b/chromium/styleguide/c++/c++.md
index c7bb4916fbe..7e036d3da66 100644
--- a/chromium/styleguide/c++/c++.md
+++ b/chromium/styleguide/c++/c++.md
@@ -224,7 +224,7 @@ following conventions. Here we refer to the parameter type as `T` and name as
   * If the function does not modify `t`'s ownership, declare the param as `T*`. The
     caller is expected to ensure `t` stays alive as long as necessary, generally
     through the duration of the call. Exception: In rare cases (e.g. using
-    lambdas with STL algorithms over containers of `uniuqe_ptr<>`s), you may be
+    lambdas with STL algorithms over containers of `unique_ptr<>`s), you may be
     forced to declare the param as `const std::unique_ptr<T>&`. Do this only when
     required.
 
diff --git a/chromium/styleguide/c++/c++11.html b/chromium/styleguide/c++/c++11.html
index 1700149d9b3..402e5c958d7 100644
--- a/chromium/styleguide/c++/c++11.html
+++ b/chromium/styleguide/c++/c++11.html
@@ -404,7 +404,7 @@ template &lt;typename T&gt;<br/>void Function(T&amp;&amp; t) { ... }</code></td>
 <td><code>emplace()</code>, <code>emplace_back()</code>, <code>emplace_front()</code>, <code>emplace_hint()</code></td>
 <td>Constructs elements directly within a container without a copy or a move. Less verbose than <code>push_back()</code> due to not naming the type being constructed.</td>
 <td>E.g. <a href="http://en.cppreference.com/w/cpp/container/vector/emplace_back">std::vector::emplace_back</a></td>
-<td><code>std::map::emplace()</code> is not yet available on all libstdc++ versions we support. When using emplacement for performance reasons, your type should probably be movable (since e.g. a vector of it might be resized); given a movable type, then, consider whether you really need to avoid the move done by <code>push_back()</code>. For readability concerns, treat like <code>auto</code>; sometimes the brevity over <code>push_back()</code> is a win, sometimes a loss. <a href="https://groups.google.com/a/chromium.org/forum/#!topic/cxx/m3cblzEta7A">Discussion thread</a></td>
+<td>When using emplacement for performance reasons, your type should probably be movable (since e.g. a vector of it might be resized); given a movable type, then, consider whether you really need to avoid the move done by <code>push_back()</code>. For readability concerns, treat like <code>auto</code>; sometimes the brevity over <code>push_back()</code> is a win, sometimes a loss. <a href="https://groups.google.com/a/chromium.org/forum/#!topic/cxx/m3cblzEta7A">Discussion thread</a></td>
 </tr>
 
 <tr>
@@ -425,6 +425,14 @@ template &lt;typename T&gt;<br/>void Function(T&amp;&amp; t) { ... }</code></td>
 </tr>
 
 <tr>
+<td>Iterator Operators</td>
+<td><code>std::next()</code>, <code>std::prev()</code></td>
+<td>Copies an iterator and increments or decrements the copy by some value</td>
+<td><a href="http://en.cppreference.com/w/cpp/iterator/next">std::next</a>, <a href="http://en.cppreference.com/w/cpp/iterator/prev">std::prev</a></td>
+<td><a href="https://groups.google.com/a/chromium.org/forum/#!topic/cxx/KeHhLI-E2Ww">Discussion thread</a></td>
+</tr>
+
+<tr>
 <td>Math functions</td>
 <td>All C++11 features in <code>&lt;cmath&gt;</code>, e.g.:<br/>
 <code>INFINITY</code>, <code>NAN</code>, <code>FP_NAN</code><br/>
@@ -833,14 +841,6 @@ std::move(t).f();&nbsp;&nbsp;// second</code></td>
 </tr>
 
 <tr>
-<td>Iterator Operators</td>
-<td><code>std::next()</code>, <code>std::prev()</code></td>
-<td>Copies an iterator and increments or decrements the copy by some value</td>
-<td><a href="http://en.cppreference.com/w/cpp/iterator/next">std::next</a>, <a href="http://en.cppreference.com/w/cpp/iterator/prev">std::prev</a></td>
-<td></td>
-</tr>
-
-<tr>
 <td>Pointer Traits Class Template</td>
 <td><code>std::pointer_traits</code></td>
 <td>Provides a standard way to access properties of pointers and pointer-like types</td>
diff --git a/chromium/styleguide/objective-c/objective-c.md b/chromium/styleguide/objective-c/objective-c.md
index e37bb76ef05..5cd5379053c 100644
--- a/chromium/styleguide/objective-c/objective-c.md
+++ b/chromium/styleguide/objective-c/objective-c.md
@@ -46,3 +46,52 @@ most of the file is Objective-C.
 mostly testing Objective-C objects and methods, the test should be written using
 C++ style.
 
+## All files are Objective-C++
+
+Chrome back-end code is all C++ and we want to leverage many C++ features, such as stack-based classes and namespaces. As a result, all front-end Bling files should be .mm files, as we expect eventually they will contain C++ code or language features.
+## Use scoped_nsobject<T> and WeakNSObject<T> where ARC is not available. 
+
+While there are no smart pointers in Objective-C, Chrome has `scoped_nsobject<T>` and `WeakNSObject<T>` to automatically manage (and document) object ownership. 
+
+Under ARC, scoped_nsobject<T> and WeakNSObject<T> should only be used for interfacing with existing APIs that take these, or for declaring a C++ member variable in a header. Otherwise use __weak variables and strong/weak properties. **Note that scoped_nsobject and WeakNSObject provide the same API under ARC**, i.e. scoped_nsobject<T> foo([[Bar alloc] init]); is correct both under ARC and non-ARC.
+
+`scoped_nsobject<T>` should be used for all owned member variables in C++ classes (except the private classes that only exist in implementation files) and Objective-C classes built without ARC, even if that means writing dedicated getters and setters to implement `@property` declarations. Same goes for WeakNSObject - always use it to express weak ownership of an Objective-C object, unless you are writing ARC code. We'd rather have a little more boilerplate code than a leak.
+
+This also means that most common uses of `autorelease` (as recommended by the Obj-C Style Guide) are no longer necessary. For example, the guide recommends this pattern for temporary objects:
+
+    MyObject* temp = [[[MyObject alloc] init] autorelease];
+
+Instead, you can use `scoped_nsobject<T>` to avoid the autorelease and ensure the object is cleaned up automatically.
+
+    scoped_nsobject<MyObject> temp([[MyObject alloc] init]);
+
+Obviously, the use of `autorelease` is allowed when the object is the return value or it needs to live beyond the current scope.
+
+## Use ObjCCast<T> and ObjcCCastStrict<T> 
+
+As C++ style guide tells you, we never use C casts and prefer `static_cast<T>` and `dynamic_cast<T>`. However, for Objective-C casts we have two specific casts: `base::mac::ObjCCast<T>arg` is similar to `dynamic_cast<T>`, and `ObjcCCastStrict` `DCHECKs` against that class.  
+## IBOutlets
+
+While Apple recommends creating properties for IBOutlets, we discourage that since it makes the details of the view hierarchy public. Instead, declare a private variable, mark that as the IBOutlet, and then create a private retained property (i.e., declared in the `@interface MyObject ()` block in the implementation file) for that variable. Ensure that you have an `ObjCPropertyReleaser` (see [this CL](https://chromereviews.googleplex.com/3578024/) for an example) and that will handle releasing the XIB objects.
+
+## Blocks
+
+We follow Google style for blocks, except that historically we have used 2-space indentation for blocks that are parameters, rather than 4. You may continue to use this style when it is consistent with the surrounding code.
+
+## NOTIMPLEMENTED and NOTREACHED logging macros
+
+`NOTREACHED`: This function should not be called. If it is, we have a problem somewhere else.
+`NOTIMPLEMENTED`: This isn't implemented because we don't use it yet. If it's called, then we need to figure out what it should do.
+
+When something is called, but don't need an implementation, just comment that rather than using a logging macro.
+## TODO comments
+
+Sometimes we include TODO comments in code. Generally we follow [C++ style](https://google.github.io/styleguide/cppguide.html#TODO_Comments), but here are some more specific practices we've agreed upon as a team:
+* **Every TODO must have a bug**
+* Bug should be labeled with **Hotlist-TODO-iOS**
+* Always list bug in parentheses following "TODO"
+    * `// TODO(crbug.com/######): Something that needs doing.`
+    * Do NOT include http://
+* Optionally include a username for reference
+* Optionally include expiration date (make sure it's documented in the bug!)
+
diff --git a/chromium/styleguide/styleguide.md b/chromium/styleguide/styleguide.md
index 85f792daa37..1a24bb5e957 100644
--- a/chromium/styleguide/styleguide.md
+++ b/chromium/styleguide/styleguide.md
@@ -17,15 +17,17 @@ Regardless of the language used, please keep code [gender neutral](gender_neutra
 
 ## Python
 
-Python code should follow [PEP-8](https://www.python.org/dev/peps/pep-0008/).
-
-Some existing scripts were originally written following Google's internal
-style guideline and have the following two exceptions. New scripts should,
-however, be PEP-8 compliant.
+Python code should follow [PEP-8](https://www.python.org/dev/peps/pep-0008/),
+except:
 
   * Use two-space indentation instead of four-space indentation.
   * Use `CamelCase()` method and function names instead of `unix_hacker_style()` names.
 
+(The rationale for these is mostly legacy: the code was originally written
+following Google's internal style guideline, the cost of updating all of the
+code to PEP-8 compliance was not small, and consistency was seen to be a
+greater virtue than compliance.)
+
 [Depot tools](http://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools.html)
 contains a local copy of pylint, appropriately configured.
 
@@ -41,6 +43,6 @@ Guidelines](https://sites.google.com/a/chromium.org/dev/chromium-os/python-style
 
 ## Web languages (JavaScript, HTML, CSS)
 
-When working on Web-based UI features, consult the [Web Development Style Guide](https://sites.google.com/a/chromium.org/dev/developers/web-development-style-guide) for the Chromium conventions used in JS/CSS/HTML files.
+When working on Web-based UI features, consult the [Web Development Style Guide](web/web.md) for the Chromium conventions used in JS/CSS/HTML files.
 
 Internal uses of web languages, notably "layout" tests, should preferably follow these style guides, but it is not enforced.