| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
0) Converted the ResourceType::Type enum to ResourceType enum in content namespace, like this:
enum ResourceType {
RESOURCE_TYPE_MAIN_FRAME = 0, //...
RESOURCE_TYPE_SUB_FRAME, // ...
RESOURCE_TYPE_STYLESHEET, // ...
.
.
.
};
1) FromWebURLRequest() is is only called from within content (child & renderer), moved into
content/child/web_url_request_util.* and renamed to WebURLRequestToResourceType().
2) ValidType/FromInt/IsSubresource aren't called from anywhere. Removed.
3) IsSharedWorker/IsServiceWorker are not necessary, they're just
an enum
comparison and are only called in 5 places. Removed them and
just the if check directly.
-IsFrame is called in a number of places. Leave it
in this header as a function. Since it's not scoped in a class
anymore,
it needs a more descriptive name. Renamed to IsResourceTypeFrame().
BUG=None
TEST=None
R=jam@chromium.org
TBR=darin@chromium # trivial changes all around src/
Review URL: https://codereview.chromium.org/425653002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@286665 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
R=jam@chromium.org
Review URL: https://codereview.chromium.org/11283004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@163929 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
typedefed uint32. This allows code all over Chromium to use an explicit type instead of "int". This also means the individual named bit constants themselves have the same explicit type. I find the resulting code to be noticeably clearer. This also exposed a bug in SSLErrorInfo::GetErrorsForCertStatus() where not having an explicit type allowed a function argument ordering bug to creep in, so I claim this is safer too.
Normally this makes things like DCHECK_EQ() unhappy, but when I'd originally tested this I didn't seem to need to make any changes due to that. Will be watching the trybots...
The original motiviation for this change was to find a way to eliminate some cases of passing anonymous-typed values as template arguments (which happens when you use a value from the enum in e.g. EXPECT_EQ()), which is technically illegal in C++03, though we don't warn about it. Simply naming the enum would have done this, but this would have encouraged readers to actually use the enum name as a type, which for a bitfield is inappropriate for the reason given in the first paragraph.
BUG=92247
TEST=Compiles
Review URL: http://codereview.chromium.org/7969023
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@102415 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bit values into a typedefed uint32. This allows code all over Chromium to use an explicit type instead of "int". (This isn't possible by simply naming the enum as technically the enum doesn't define all of the possible combinations of bits.) This also means the individual named bit constants themselves have the same explicit type. I find the resulting code to be noticeably clearer. This also exposed a bug in SSLErrorInfo::GetErrorsForCertStatus() where not having an explicit type allowed a function argument ordering bug to creep in, so I claim this is safer too.
I also added CERT_STATUS_NO_ERROR in place of "0" as a magic number.
Normally this makes things like DCHECK_EQ() unhappy, but when I'd originally tested this I didn't seem to need to make any changes due to that. Will be watching the trybots...
The original motiviation for this change was to find a way to eliminate some cases of passing anonymous-typed values as template arguments (which happens when you use a value from the enum in e.g. EXPECT_EQ()), which is technically illegal in C++03, though we don't warn about it. Simply naming the enum would have done this, but this would have encouraged readers to actually use the enum name as a type, which for a bitfield is inappropriate for the reason given in the first paragraph.
BUG=92247
TEST=Compiles
Review URL: http://codereview.chromium.org/7819009
TBR=pkasting@chromium.org
Review URL: http://codereview.chromium.org/7995014
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@102325 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
typedefed uint32. This allows code all over Chromium to use an explicit type instead of "int". (This isn't possible by simply naming the enum as technically the enum doesn't define all of the possible combinations of bits.) This also means the individual named bit constants themselves have the same explicit type. I find the resulting code to be noticeably clearer. This also exposed a bug in SSLErrorInfo::GetErrorsForCertStatus() where not having an explicit type allowed a function argument ordering bug to creep in, so I claim this is safer too.
I also added CERT_STATUS_NO_ERROR in place of "0" as a magic number.
Normally this makes things like DCHECK_EQ() unhappy, but when I'd originally tested this I didn't seem to need to make any changes due to that. Will be watching the trybots...
The original motiviation for this change was to find a way to eliminate some cases of passing anonymous-typed values as template arguments (which happens when you use a value from the enum in e.g. EXPECT_EQ()), which is technically illegal in C++03, though we don't warn about it. Simply naming the enum would have done this, but this would have encouraged readers to actually use the enum name as a type, which for a bitfield is inappropriate for the reason given in the first paragraph.
BUG=92247
TEST=Compiles
Review URL: http://codereview.chromium.org/7819009
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@102322 0039d316-1c4b-4281-b951-d872f2087c98
|
|
specific to Chrome (i.e. interstitial, dialogs) stays behind. This change just moves code, and so adds a bunch of files to DEPS. I'll add proper interfaces in a follow up cl, but keeping the move simple at first.
BUG=76697
Review URL: http://codereview.chromium.org/7111013
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@87866 0039d316-1c4b-4281-b951-d872f2087c98
|