- Generate and pass sequential frame indexes into the ovr_GetTrackingState call and the corresponding call to ovr_SubmitFrame
MozReview-Commit-ID: 5tJl5YJt7Eo
Treat global variables the same as function arguments and return values: No
unsigned SIMD types allowed. This simplifies interoperation with WebAssembly.
Add a Type::isGloblVarType() which can be used to check for valid types.
Fold CheckGlobalVariableImportExpr into its single caller.
Remove Type::var(ValType) and Type::ret(ExprType). These backwards conversions
were only used for diagnostics, and we can use the existing ToCString() function
for that. Move this function form Wasm.cpp to WasmTypes.h so it can be used
everywhere.
MozReview-Commit-ID: FolGlCTVmgZ
Add Uint32x4 to NumLit and Type classes.
Reject unsigned SIMD types in function signatures to avoid confusion when
interoperating with WebAssembly.
MozReview-Commit-ID: 7FvQKKITVKR
Also move IsSimdTypeName() into builtin/SIMD.cpp and handle all SIMD type names
there too.
Use IsSimdValidOperationType(simdType, SimdOperation::Constructor) to check for
supported SIMD types in asm.js instead of depending on IsSimdTypeName() to only
return true on supported types.
MozReview-Commit-ID: FZrnPZc8zmJ
The wasm types don't have signed/unsigned SIMD integers. Add enumerators for
those unsigned simd operations that behave differently than their signed I32x4
counterparts.
Implement wasm code generation for unsigned SIMD types.
Split the convertSimd() function into two variants for conversions and bitcasts
respectively. Add a SimdSign argument to the conversion variants.
Add a SimdSign argument to the extractSimdElement() function. This is not
strictly needed for I32x4 since wasm uses I32 for both signed and unsigned ints.
It will be required for the I8x16 and I16x8 types, though, because the lane
value needs to be extended to an I32.
Split out the binarySimdComp function for binary comparisons, and thread
through a SimdSign argument.
Add a SimdSign to EmitSimdOp() and thread it through where needed.
MozReview-Commit-ID: B8FHOHzjbBX
The MSimd*::NewAsmJS() factory functions are not longer needed since the normal
MSimd*::New() functions also require the SIMD arguments to be unboxed since
bug 1244254.
Remove the trivial NewAsmJS functions here. The remaining SIMD NewAsmJS
functions will be removed in the next commit.
MozReview-Commit-ID: JtgRKZTmrzS
These two functions can also take a Type argument instead of ValType/ExprType.
This makes it possible to avoid some explicit SIMD type enumerations, and the
Type <= ValType subtyping test is no longer needed.
MozReview-Commit-ID: 1nkMDUdgLkE
When validating function calls and coercions, use a canonical Type instead of a
wasm::ExprType to express the desired return type.
This will make it possible to distinguish signed/unsigned SIMD types during
validation.
MozReview-Commit-ID: 4S0SuRRgCzm
The WebAssembly and the asm.js type systems are diverging. In particular,
WebAssembly will not distinguish signed/unsigned SIMD types, while asm.js must
since it is compatible with SIMD.js. The wasm::ValType enum also has an I64
which is not supported by asm.js
Reduce OdinMonkey's dependency on wasm::ValType by returning a canonical 'class
Type' instead from these functions:
- IsCoercionCall()
- CheckTypeAnnotation()
- CheckArgumentType()
Avoid wasm::ValType for asm.js locals. We want to allow signed/unsigned SIMD
locals.
Remove NumLit::type().
MozReview-Commit-ID: Eutj6QKqn02
This subset of the asm.js types corresponds to the Void type and all the
coercion targets. It corresponds to wasm::ExprType, except:
- asm.js does not support I64.
- asm.js distinguishes signed/unsigned SIMD types, wasm does not.
The function Type::canonicalize() maps a type into the canonical set.
Type::isCanonical() checks for membership.
This subset of Type::Which will be used to replace wasm::ValType and
wasm::ExprType in the asm.js type checking code. This makes it possible to
type-check unsigned SIMD types correctly.
Eliminate Type:checkedValueType(). Use Type::canonicalToValType() instead.
MozReview-Commit-ID: EBrCiPVYzh8
This function is only used by CheckIsVarType which is actually used for
checking function arguments.
Rename isVarType -> isArgType and CheckIsVarType -> CheckIsArgType to better
match the usage.
This frees up the concept of a "var type" for the following patch.
MozReview-Commit-ID: 4J63ammf3zS
This method is e10s-compatible. It is async, so it requires
rejiggering the test a little. This also requires fixing up a shim
version for xpcshell tests. Finally, this test is the only user of
SpecialPowers.createDOMFiles, so I removed it.
The C++ standard, [facet.num.get.virtuals], defines the method to be
used for reading numeric values from an iterator. The core loop is
defined thusly in N3242 (the draft for the C++11 standard):
Stage 2: If in==end then stage 2 terminates. Otherwise a charT is
taken from in and local variables are initialized as if by
char_type ct = *in;
char c = src[find(atoms, atoms + sizeof(src) - 1, ct) - atoms];
if (ct == use_facet<numpunct<charT> >(loc).decimal_point())
c = '.';
bool discard =
ct == use_facet<numpunct<charT> >(loc).thousands_sep()
&& use_facet<numpunct<charT> >(loc).grouping().length() != 0;
where the values src and atoms are defined as if by:
static const char src[] = "0123456789abcdefxABCDEFX+-";
char_type atoms[sizeof(src)];
use_facet<ctype<charT> >(loc).widen(src, src + sizeof(src), atoms);
for this value of loc.
If discard is true, then if '.' has not yet been accumulated, then the
position of the character is remembered, but the character is
otherwise ignored. Otherwise, if '.' has already been accumulated, the
character is discarded and Stage 2 terminates.
If the character is either discarded or accumulated then in is
advanced by ++in and processing returns to the beginning of stage 2.
Stage 3: The sequence of chars accumulated in stage 2 (the field) is
converted to a numeric value by the rules of one of the functions
declared in the header <cstdlib>:
- For a signed integer value, the function strtoll.
- For an unsigned integer value, the function strtoull.
- For a floating-point value, the function strtold.
The important part for our purposes here is the line:
char c = src[find(atoms, atoms + sizeof(src) - 1, ct) - atoms];
which implies that we are to accumulate any and all characters that
might be numerical constituents. According to the spec text, we might
accumulate a long run of numeric constituents, only to decide in stage 3
that our accumulated string cannot be a valid number. Please note that
this includes characters like 'x' and 'X' which are only valid as part
of a hexadecimal prefix.
sdp_unittests has a number of tests that look like:
ParseInvalid<SdpImageattrAttributeList::XYRange>("[x", 1);
The test converts the input string to a stringstream, and attempts to
read an integer from the stream starting after the '[' character. The
test expects that no input from the string stream will be consumed, as
the character 'x' cannot begin any number, and thus the position of the
stream after failure will be 1. This behavior is consistent with MSVC's
standard library, libstdc++, and stlport.
However, libc++ uses a different algorithm that appears to hew more
closely to the letter of the spec, and consumes the 'x' character as
being a valid constituent character ("accumulates" in the above text).
The string is rejected as an invalid integer, yet the position of the
string stream afterwards is different from what the test expects, and we
therefore fail.
This patch therefore alters a number of tests to use a different invalid
character, 'v', that both the incremental algorithm (MSVC, libstdc++,
stlport) and the all-at-once algorithm (libc++) will recognize as not
being a valid constituent character and stop the parsing early, as
expected. You might think that specifying the base for numeric input as
std::dec would work, and it partially does, but reading floating-point
numbers still reads the 'x' characters (!).
