New issue
Advanced search Search tips

Issue 809078 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

flat_map/flat_tree can be unintentionally copied

Project Member Reported by gab@chromium.org, Feb 5 2018

Issue description

flat_map/flat_tree can be implicitly copied as I just realized while digging into an issue, e.g.

https://cs.chromium.org/chromium/src/components/safe_browsing/android/safe_browsing_api_handler_bridge.cc?rcl=edff7d305f82de81cec263413897a7d126661da7&l=191

  api_task_runner_->PostTask(
      FROM_HERE,
      base::BindOnce(&SafeBrowsingApiHandlerBridge::Core::StartURLCheck,
                     base::Unretained(core_.get()), callback, url,
                     threat_types));

most sets are small (in this case it's mostly IDs), I'm not sure it's super important but it still seems to me like unintentional copies are generally bad and can be specifically horrible depending on the set..?

I tried making the copy constructor explicit but it's a major pain : https://chromium-review.googlesource.com/c/chromium/src/+/901604

In particular GMOCK isn't happy, things like
  EXPECT_CALL(favicon_service_, SetFavicons(base::flat_set<GURL>{kPageURL},
                                            kManifestURL, kWebManifestIcon, _));
use the implicit copy constructor for the args...
 

Comment 1 by gab@chromium.org, Feb 5 2018

Status: WontFix (was: Untriaged)
Actually.. this is true of all container types... The check is whether T is copiable, after that the container is assumed okay-to-copy.
Yeah, we copy stuff all the time by accident, I've seen it with std::maps and such too, it's not wonderful. We should improve our coding practices and use move and references better.

Sign in to add a comment