IDL: Drop redundant null check for string and wrapper type attributes

Source/bindings/scripts/v8_types.py

Index: Source/bindings/scripts/v8_types.py
diff --git a/Source/bindings/scripts/v8_types.py b/Source/bindings/scripts/v8_types.py
index 95bb3adbfe46dd09d1d8e196e61aa930739d3882..e357766d4b3099fca64a9a940c86cf0c31833ddd 100644
--- a/Source/bindings/scripts/v8_types.py
+++ b/Source/bindings/scripts/v8_types.py
@@ -558,6 +558,8 @@ def v8_conversion_type(idl_type, extended_attributes):
     if base_idl_type in CPP_UNSIGNED_TYPES:
         return 'unsigned'
     if idl_type.is_string_type:
+        if idl_type.is_nullable:
+            return 'StringOrNull'
         if 'TreatReturnedNullStringAs' not in extended_attributes:
             return base_idl_type
         treat_returned_null_string_as = extended_attributes['TreatReturnedNullStringAs']
@@ -676,6 +678,9 @@ CPP_VALUE_TO_V8_VALUE = {
     'double': 'v8::Number::New({isolate}, {cpp_value})',
     'unrestricted double': 'v8::Number::New({isolate}, {cpp_value})',
     'void': 'v8Undefined()',
+    # [TreatNullReturnValueAs]
+    'StringOrNull': '!{cpp_value}.isNull() ? v8String({isolate}, {cpp_value}) : v8::Handle<v8::Value>(v8::Null({isolate}))',

[haraken, 2014/07/01 00:57:33]

Flip the order and avoid a negation.

{cpp_value}.isNull() ? v8::Handle<v8::Value>(v8::Null({isolate})) :
v8String({isolate}, {cpp_value})

Do we have a run-bindings-test for this? I couldn't find a diff caused by this
change.

[Jens Widell, 2014/07/01 06:43:22]

Done.

+    'StringOrUndefined': '!{cpp_value}.isNull() ? v8String({isolate}, {cpp_value}) : v8Undefined()',

[haraken, 2014/07/01 00:57:33]

Ditto.

BTW, who needs StringOrUndefined? The behavior sounds a bit strange in terms of
the spec.

[Jens Widell, 2014/07/01 06:43:22]

A bit strange, yes. Kicks in with [TreatReturnedNullStringAs=Undefined], which
is used in a few places in real IDL files. Somewhat unclear if any of them
actually ever return a null string, so this may be dead code.

These added code snippets don't end up anywhere in generated code with current
IDL files, but the dictionary items are always accessed to calculate (unused)
attribute context values, so not having them raises KeyError.

I've added tests for the cases where they would be used; DOMString? or
[TreatReturnedNullStringAs] combined with [CachedAttribute] or
[LogPreviousValue].

     # Special cases
     'EventHandler': '{cpp_value} ? v8::Handle<v8::Value>(V8AbstractEventListener::cast({cpp_value})->getListenerObject(impl->executionContext())) : v8::Handle<v8::Value>(v8::Null({isolate}))',
     'ScriptValue': '{cpp_value}.v8Value()',