Closed Bug 604276 Opened 15 years ago Closed 15 years ago

Silence some MSVC warnings

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b8

People

(Reporter: jorendorff, Assigned: jorendorff)

References

Details

(Whiteboard: [fixed-in-tracemonkey])

Attachments

(1 file, 1 obsolete file)

These appear many times: d:\dev\tracemonkey\js\src\jscompartment.h(66) : warning C4251: 'JSCompartment::crossCompartmentWrappers' : class 'js::HashMap<Key,Value,HashPolicy,AllocPolicy>' needs to have dll-interface to be used by clients of struct 'JSCompartment' d:\dev\tracemonkey\js\src\jsscope.h(211) : warning C4307: '+' : integral constant overflow These appear once: d:/dev/tracemonkey/js/src/jscntxt.cpp(2049) : warning C4355: 'this' : used in base member initializer list d:/dev/tracemonkey/js/src/jstracer.cpp(10274) : warning C4099: 'js::BoxArg' : type name first seen using 'class' now seen using 'struct'
Attached patch v1 (obsolete) — Splinter Review
Assignee: general → jorendorff
Attachment #483064 - Flags: review?(dmandelin)
Instead of the noisy pragma, you could do: struct JSContext { JSContext *thisInInitializer() { return this; } JSContext() : busyArrays(thisInInitializer()) {} ... };
The |thisInitializer| solution seems better to me too. On that constant overflow warning, what is the static assertion trying to do, anyway? Can (0xffffffff + 1) be anything other than 0 as a 32-bit value, ever? Maybe we should just delete the assertion.
Attached patch v2Splinter Review
Attachment #483064 - Attachment is obsolete: true
Attachment #483229 - Flags: review?(lw)
Attachment #483064 - Flags: review?(dmandelin)
Attachment #483229 - Flags: review?(lw) → review+
> On that constant overflow warning, what is the static assertion trying to do, > anyway? Can (0xffffffff + 1) be anything other than 0 as a 32-bit value, ever? > Maybe we should just delete the assertion. The assertion really is checking that when we add 1 to SHAPE_INVALID_SLOT, it overflows and produces 0. See the comment on JSShape::setParent, also in jsscope.h. http://hg.mozilla.org/tracemonkey/diff/b1facf8ba54e/js/src/jsscope.h Maybe we should just move the static assertion into the body of setParent. But getting to zero warnings by deleting static assertions would be running the wrong way, I think.
(In reply to comment #5) > > On that constant overflow warning, what is the static assertion trying to do, > > anyway? Can (0xffffffff + 1) be anything other than 0 as a 32-bit value, ever? > > Maybe we should just delete the assertion. > > The assertion really is checking that when we add 1 to SHAPE_INVALID_SLOT, it > overflows and produces 0. See the comment on JSShape::setParent, also in > jsscope.h. > http://hg.mozilla.org/tracemonkey/diff/b1facf8ba54e/js/src/jsscope.h > > Maybe we should just move the static assertion into the body of setParent. > > But getting to zero warnings by deleting static assertions would be running the > wrong way, I think. Sure, I wouldn't recommend just deleting assertions in general. This one is just hard for me to distinguish from "const int foo = 3; JS_STATIC_ASSERT(foo + 1 == 4);". I would probably just go with a comment like "This must be 0xfffffff so that adding overflows, blah", so that anyone modifying that code would know not to change it lightly. I guess the static assert does add a level of "paranoid" safety in that if someone didn't read the comment and changed the value, they would trip the assert. Moving it to setParent does seem like a good idea to me, maybe with an brief explanation (or pointer to one) as to why this property is required right next to the assert. Anyway, I don't feel that strongly about this--it was just what popped into my head on reading the v1 patch.
re overflow, see Bug 598055
Whiteboard: [fixed-in-tracemonkey]
Blocks: 598055
This is FIXED, no?
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Depends on: 758132
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: