- 24 Feb, 2021 1 commit
-
-
Seth Brenith authored
Currently, some ScopeInfo fields are defined as indexed fields with a length of either one or zero, because the field might be present or it might not. Based on comments in https://crrev.com/c/v8/v8/+/2601880 , this strategy is not sustainable and we need a better way to represent optional fields so that we don't have to pass zero when accessing their only element. This change is a proposal to fix that problem. Syntax: I'm proposing using a question mark because TypeScript does, and Torque syntax looks somewhat like TypeScript. I don't feel strongly about this though, and I'm open to other suggestions. field_name?[condition_expression]: FieldType; Internal Torque compiler representation: Internally, I've updated the Torque compiler to still treat these fields as indexed, but with an extra flag saying they're optional. When getting a LocationReference for a field access expression on an optional field, Torque produces a Slice like it would for any other indexed field and subsequently calls AtIndex(0) to get a Reference. AtIndex can crash the process if the index is out of bounds (which is good), so some other parts of the Torque compiler need minor adjustments so that it doesn't take references to optional fields unless it actually needs them. Initialization: This proposal doesn't include any changes to initialization logic, so an optional field can still be initialized using '...' and an iterator. Perhaps we could introduce an Optional<T> struct for prettier initialization in a future change. Bug: v8:7793 Change-Id: I37649495f4c259e685261f53e4cf2859da66a31f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706306 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#73018}
-
- 09 Feb, 2021 1 commit
-
-
Nico Hartmann authored
This CL adds support for generating acquire/release accessors on class fields. Adds first use of this new feature (@acquireRead and @releaseWrite) on FunctionTemplateInfo::rare_data. Bug: v8:7790, v8:11122 Change-Id: I98f533807ab784d8667fd43564fe84686d27830c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679684Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Seth Brenith <seth.brenith@microsoft.com> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#72596}
-
- 03 Feb, 2021 1 commit
-
-
Seth Brenith authored
When generating getters, Torque needs to decide whether to perform a normal or relaxed load. Thus far, it has used the somewhat non-obvious logic that any indexed field with tagged non-smi data gets relaxed loads. This change adds a new annotation @relaxedRead to be consistent with the existing @relaxedWrite annotation. I added @relaxedRead annotations on any field that previously had this automatic behavior and whose getter is called, except for those in ScopeInfo because I'm relatively confident that it doesn't need relaxed access. Bug: v8:7793 Change-Id: I9987eea13760b967f1b8a3189b69742e55140c30 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2600113 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#72499}
-
- 11 Nov, 2020 1 commit
-
-
Tobias Tebbi authored
This CL lets Torque generate the Context C++ class and BodyDescriptor for Context. This requires two Torque changes: - Allow @generateBodyDescriptor on @abstract classes, since all Context classes share the same BodyDescriptor. - Add a new annotation @relaxedWrite, which makes C++ setters use WRITE_RELAXED_FIELD instead of WRITE_FIELD. Attention: As a side-effect, this CL disables using WRITE_RELAXED_FIELD by default for all non-array fields. If this causes problems, we should manually add @relaxedWrite to the corresponding fields. Bug: v8:7793 Change-Id: I735b310bcb36a3612d86c22efa9c0bfc108d4ca6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529453 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#71123}
-
- 22 Oct, 2020 1 commit
-
-
Seth Brenith authored
Originally, the Torque-generated verifier for a field with type Undefined|Zero|NonNullForeign would check `f.IsUndefined() || f.IsZero() || f.IsNonNullForeign()`. At some point, we changed Torque so that it now generates the much weaker `f.IsOddball() || f.IsSmi() || f.IsForeign()`. This change returns the verifiers to their initial precision. Mostly we can use the names of abstract types to build up the correct type check expression, but a few abstract types like PodArrayOfWasmValueType have no way that we can tell them apart from their parent type at runtime. It would be confusing to have a function Object::IsPodArrayOfWasmValueType which actually just checks whether the object is a ByteArray, so this change introduces a new annotation which allows abstract type declarations to state that they should use their parent type during verification. This change also adds new test cases to help avoid future regressions of this logic. Bug: v8:7793 Change-Id: Ie5046d742fd45e0e0f6c2ba387d909e9f2ac6df1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2469960Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70698}
-
- 05 Oct, 2020 1 commit
-
-
Seth Brenith authored
Currently, when accessing a field that doesn't have a constant offset, Torque emits code to compute each preceding indexed field's length and add them all together. This works, but such code can get super long if a class has many indexed fields, and especially if the length expressions of some indexed fields refer to other indexed fields. We'd like the output of the new C++ backend to be short enough to go in inline headers which will be included in many compilation units. This change attempts to reorganize the code so that the computation of each length expression can only be emitted exactly once. This only shortens the generated C++ code; the resulting TurboFan output should be identical. There are two main parts: 1. For each indexed field, we already generate a macro that can get a Slice referring to that field. Update these macros to not use the dot operator on that field. Using the dot operator on the predecessor field is allowed. 2. Update the dot operator for indexed fields to emit a call to the macro from step 1. This sort of reverses the dependency added by the previous change https://crrev.com/c/2429566 : rather than the slice macros depending on the dot operator, this change makes the dot operator depend on the slice macros. The overall torque_generated directory shrinks by under 1% with this change, but the runtime_macros.cc file (which should eventually become inline headers) shrinks by 24%. More to the point, this change keeps runtime_macros.cc from ballooning out of control when we add a work-in-progress Torque definition for ScopeInfo ( https://crrev.com/c/2357758 ). Bug: v8:7793 Change-Id: I989dda9c3666f1a49281fef03acb35baebb5b63a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432070Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70325}
-
- 27 Jul, 2020 1 commit
-
-
Tobias Tebbi authored
When mksnapshot fails on a static assert in Torque, print the statement and position from the Torque source. To enable special treatment, change the syntax of static asserts in Torque from StaticAssert() to static_assert() to align with assert() and check() statements. Bug: v8:7793 Change-Id: Idda8e3c342bdcefc893ff297f8d7727d2734c221 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2317314 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#69069}
-
- 10 Jul, 2020 1 commit
-
-
Gus Caplan authored
This allows `new (Pretenured) X{}` to force a pretenured allocation. Bug: v8:7793 Change-Id: Ib09f186b3b503b9b23291c39c1390f120d25eebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2288409 Commit-Queue: Gus Caplan <me@gus.host> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#68801}
-
- 06 May, 2020 1 commit
-
-
Ng Zhi An authored
See https://chromium.googlesource.com/chromium/src/+/HEAD/styleguide/c++/c++-dos-and-donts.md#prefer-to-use. Bug: v8:10488 Change-Id: I3d2503b46172bc2fa310b24f04e944ff211ebf51 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182310Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67626}
-
- 01 May, 2020 1 commit
-
-
Tobias Tebbi authored
Torque desugars try-catch/label constructs with several handlers into nested try structures, with the first handler ending-up innermost. So currently, if you write try { ... } label Foo { Throw(...); } catch (e) { } The catch will catch the preceding Throw in another handler. This is different from how multiple try-catch handlers are done in languages like Java, where throwing from a preceding catch handler is not caught by a later one. To avoid this possible ambiguity, this CL prohibits this pattern, enforcing that a catch handler comes first, before any other label-handler attached to the same try. This way, a catch handler never catches from any other handler on the same try, since they have to come later. Bug: v8:7793 Change-Id: I943f14b2393d307c4254a3fc3a78f236dbcf86df Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2169098 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67516}
-
- 17 Apr, 2020 1 commit
-
-
Seth Brenith authored
Currently it's possible to hit an internal compiler error by declaring a non-extern class that doesn't extend anything. It's not very meanigful for a class to not extend from anything, so the parser should enforce this requirement. Change-Id: I38064f87345d28ce84521261bbfd33d9b1c71334 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2153847 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67212}
-
- 18 Mar, 2020 1 commit
-
-
Tobias Tebbi authored
- Allow type expression for abstract type supertypes. For consistency, and ease of implementation, also allow this for enums. - Allow subtyping of structs. This requires changing all places where we checked for struct types and instead check if we have a subtype of a struct type. - This allows defining two subtypes of the Reference<T> struct for mutable and constant references. Mutable references are a subtype of constant references. - &T desugars to MutableReference<T> const &T desugars to ConstReference<T> - A const field of a class produces a constant reference. A const field of a mutable reference to a struct is const. A mutable field of a const reference to a struct is const. - It is possible to assign a new struct value to a mutable reference to a struct, even if the struct contains const fields. This is analogous to allowing assignments of let-bound structs with constant fields. Not in this CL: - A notion of const slices. - Applying const to appropriate class fields. Bug: v8:7793 Change-Id: I6e7b09d44f54db25f8bf812be5f3b554b80414e0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096615Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66759}
-
- 02 Jan, 2020 1 commit
-
-
Milad Farazmand authored
Compilation fails on certain versions of gcc with "'find_if' is not a member of 'std'" Change-Id: Ifd0046e0838e5476515b646b35400d0973e80a01 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1980501Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65578}
-
- 23 Dec, 2019 1 commit
-
-
Nico Hartmann authored
Bug: v8:10053 Change-Id: I90e0798ce490dea035cf4ecb934a4b8d98c61bc3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977859 Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65551}
-
- 20 Dec, 2019 1 commit
-
-
Tobias Tebbi authored
This allows the definition of classes with several arrays and ports SmallOrderedHashTable subclasses to Torque as an example, including the existing CSA allocation functions for them. Overview of changes: - Introduce ResidueClass to encapsulate the modulo-arithmetic necessary to do alignment checks. - Add MachineOperatorReducer to the CSA pipeline to address now missing CSA ad-hoc constant folding that got blocked by a temporary phi. - Allow assignments to references to structs. This is needed to initialize the data_table part of SmallOrderedHashMap. - Make the NumberLiteralExpression AST-node store a double instead of a string. This is necessary to detect arrays with constant size used for padding. - Turn offsets into base::Optional<size_t> to ensure we don't use an invalid or statically unknown offset. - Remove CreateFieldReferenceInstruction since it doesn't work for complex offset computations and the logic can be expressed better in ImplementationVisitor. - Validate alignment of structs embedded in classes. Bug: v8:10004 v8:7793 Change-Id: Ifa414b42278e572a0c577bf9da3d37f80771a258 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958011 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#65538}
-
- 12 Dec, 2019 1 commit
-
-
Tobias Tebbi authored
This allows arbitrary expressions to specify the length of an array. These expressions get access to globally declared things and the preceding fields of the current object. Unfortunately, this breaks generated C++ runtime code, so as a workaround, I special-case expressions that are just an identifier and handle them as before. We might want to support more cases there in the future, probably also with special-casing since having a full C++ back-end for Torque is infeasible. Bug: v8:10004 v8:7793 Change-Id: I0d5d1200c0e727766beed7bfb2d43a8abb9cacf0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1942610 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#65427}
-
- 06 Dec, 2019 1 commit
-
-
Seth Brenith authored
This change is the first part of adding Torque support for a "bitfield struct", which represents a set of bitfields packed together into an integer value. With this change, Torque can generate the list of BitField template specializations that allow runtime code to use the bitfield values. The flags used in SharedFunctionInfo are converted to Torque to exercise this functionality. Bitfield values are not yet accessible directly from Torque code. Bug: v8:7793 Change-Id: I9e4a3df7c847111b6e02e513f175dbf938b0be35 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1949047 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#65371}
-
- 31 Oct, 2019 1 commit
-
-
Tobias Tebbi authored
This has two advantages: - It improves error messages by avoiding wrong template instantiations. - More flexible overloads by disabling generics for overload resolution when their constraints are violated. Bug: v8:7793 Change-Id: I7d2b8ef736988e8de16d25a4a4b16b49e27c6a11 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1890097Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#64676}
-
- 29 Oct, 2019 1 commit
-
-
Nico Hartmann authored
In some places objects where allocated on the heap and stored in a std::unique_ptr later. This CL changes this so that a The std::unique_ptr<T>(new T(...)) construct is replaced with std: :unique_ptr takes ownership of new objects immediately. std: :make_unique<T>(...) where possible. Change-Id: Icdb4c9e7536d2b437df1a5bb6c3ad94c97e1e4cc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1871916 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#64603}
-
- 24 Oct, 2019 1 commit
-
-
Tobias Tebbi authored
This expands the existing mechanism for generic structs to also cover abstract types. This involves: - Moving the SpecializationKey from StructType to Type, so that it's also available to AbstractType. - Moving the generic parameters out of the StructDeclaration AST node and using the existing GenericDeclaration AST node for generic structs and abstract types too. - The GenericStructType declarable gets generalized to GenericType. This will be useful for defining a Weak<T> type for weak pointers. Bug: v8:7793 Change-Id: I183b3a038a143cf0ae5888150104c4a025fd736c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859623 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64533}
-
- 22 Oct, 2019 1 commit
-
-
Tobias Tebbi authored
Name mangling is hard to get right and not easy to read. This CL replaces the remaining name mangling of types and generics with simpler names that are not always unique, but then fixes them up by appending a unique counter. For struct types, this required an @export annotation since we use some struct types in CSA. Drive-by-fixes: - Overwrite the copy constructor of Type to clear the list of alias names when creating a new type. - Change the existing append-a-number scheme to have different counters for each name. This the number of changed names when adding something and is more readable. Bug: v8:7793 Change-Id: Ied11ea1a251130f4562ddc0d81967368349e0bf6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1866650 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64449}
-
- 11 Oct, 2019 1 commit
-
-
Seth Brenith authored
Design doc: https://docs.google.com/document/d/1ZU6rCvF2YHBGMLujWqqaxlPsjFfjKDE9C3-EugfdlAE/edit Changes from the design doc: - Changed to use 'class' declarations rather than 'type' declarations for things that need instance types but whose layout is not known to Torque. These declarations end with a semicolon rather than having a full set of methods and fields surrounded by {}. If the class's name should not be treated as a class name in generated output (because it's actually a template, or doesn't exist at all), we use the standard 'generates' clause to declare the most appropriate C++ class. - Removed @instanceTypeName. - @highestInstanceType became @highestInstanceTypeWithinParentClassRange to indicate a semantic change: it no longer denotes the highest instance type globally, but only within the range of values for its immediate parent class. This lets us use it for Oddball, which is expected to be the highest primitive type. - Added new abstract classes JSCustomElementsObject and JSSpecialObject to help with some range checks. - Added @lowestInstanceTypeWithinParentClassRange so we can move the new classes JSCustomElementsObject and JSSpecialObject to the beginning of the JSObject range. This seems like the least-brittle way to establish ranges that also include JSProxy (and these ranges are verified with static assertions in instance-type.h). - Renamed @instanceTypeValue to @apiExposedInstanceTypeValue. - Renamed @instanceTypeFlags to @reserveBitsInInstanceType. This change introduces the new annotations and adds the ability for Torque to assign instance types that satisfy those annotations. Torque now emits two new macros: - TORQUE_ASSIGNED_INSTANCE_TYPES, which is used to define the InstanceType enumeration - TORQUE_ASSIGNED_INSTANCE_TYPE_LIST, which replaces the non-String parts of INSTANCE_TYPE_LIST The design document mentions a couple of other macro lists that could easily be replaced, but I'd like to defer those to a subsequent checkin because this one is already pretty large. Bug: v8:7793 Change-Id: Ie71d93a9d5b610e62be0ffa3bb36180c3357a6e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1757094 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64258}
-
- 20 Aug, 2019 1 commit
-
-
Seth Brenith authored
Extend the order-independent annotation parsing logic to include the following forms: @foo // bare annotation (already supported) @foo(0x70) // decimal literal @foo(HI) // identifier @foo("hello there") // quoted string This is obviously still pretty far from annotations in other languages, which usually support arbitrary expressions and multiple parameters, but I think it's sufficient to cover a pretty good variety of usages. The existing class-field annotations @if and @ifnot are reimplemented in the new style, meaning they could now appear in any order relative to other annotations on the same field (and can be repeated, though I doubt it would be of much use to anybody). Change-Id: I97b7c0c9a541ca3126b5ae3a2484688b04dda9f4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1754947 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63285}
-
- 06 Aug, 2019 1 commit
-
-
Tobias Tebbi authored
Bug: v8:7793 Change-Id: I5f5461e4e3d31c6d3c2c1fba4ce48a4eb5db5d8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725625 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63098}
-
- 26 Jul, 2019 1 commit
-
-
Georg Schmid authored
This CL removes the built-in reference type in favor of a Torque-implemented generic struct, i.e., internal::Reference<T>. It also adds various infrastructure for getting and creating new generic struct instances, as well as matching against them. R=tebbi@chromium.org Change-Id: I1e3d6afe355a0603fa9c3ad789c6b8a97d1b3c26 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1718148 Commit-Queue: Georg Schmid <gsps@google.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#62939}
-
- 23 Jul, 2019 1 commit
-
-
Georg Schmid authored
This CL introduces generic Torque structs. Generics are grounded early in the Torque compilation pipeline, meaning that every instantiation of a generic struct with concrete types will be turned into a distinct StructType. As an example, consider a Tuple of types T1, T2: struct Tuple<T1: type, T2: type> { const fst: T1; const snd: T2; } which can be manipulated using generic macros, such as macro Swap<T1: type, T2: type>(tuple: Tuple<T1, T2>): Tuple<T2, T1> { return Tuple<T2, T1>{fst: tuple.snd, snd: tuple.fst}; } Currently there is no type inference for struct instantiation sites, so type arguments have to be provided explicitly: const intptrAndSmi = Tuple<intptr, Smi>{fst: 1, snd: 2}; R=sigurds@chromium.org, tebbi@chromium.org Change-Id: I43111561cbe53144db473dc844a478045644ef6c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714868 Commit-Queue: Georg Schmid <gsps@google.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62878}
-
- 14 Jun, 2019 3 commits
-
-
Tobias Tebbi authored
This is a reland of 6eff6cc9 Original change's description: > [torque] introduce separate implicit parameters for JavaScript calling convention > > Implicit parameters for builtins with JavaScript linkage are now separate, using > the keyword "js-implicit". They have to be one of: > - context: Context > - receiver: Object (this in JS) > - target: JSFunction (arguments.callee in JS) > - newTarget: Object (new.target in JS) > > Bug: v8:9120 v8:7793 > > Change-Id: I916f60971bb53d5046b6006725d0ce39291ca55e > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1658159 > Reviewed-by: Tamer Tas <tmrts@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62174} TBR=tmrts@chromium.org Bug: v8:9120 v8:7793 Change-Id: Idb25d316d9d87e345ab74c2df583ff2648da012c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660483 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62182}
-
Yang Guo authored
This reverts commit 6eff6cc9. Reason for revert: Presubmit failure. Original change's description: > [torque] introduce separate implicit parameters for JavaScript calling convention > > Implicit parameters for builtins with JavaScript linkage are now separate, using > the keyword "js-implicit". They have to be one of: > - context: Context > - receiver: Object (this in JS) > - target: JSFunction (arguments.callee in JS) > - newTarget: Object (new.target in JS) > > Bug: v8:9120 v8:7793 > > Change-Id: I916f60971bb53d5046b6006725d0ce39291ca55e > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1658159 > Reviewed-by: Tamer Tas <tmrts@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62174} TBR=sigurds@chromium.org,tebbi@chromium.org,tmrts@chromium.org,szuend@chromium.org Change-Id: Ide206788745bd15677bd60fe32d2476321967069 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9120 v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660482Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#62175}
-
Tobias Tebbi authored
Implicit parameters for builtins with JavaScript linkage are now separate, using the keyword "js-implicit". They have to be one of: - context: Context - receiver: Object (this in JS) - target: JSFunction (arguments.callee in JS) - newTarget: Object (new.target in JS) Bug: v8:9120 v8:7793 Change-Id: I916f60971bb53d5046b6006725d0ce39291ca55e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1658159Reviewed-by:
Tamer Tas <tmrts@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#62174}
-
- 11 Jun, 2019 1 commit
-
-
Simon Zünd authored
This CL introduces an 'import' statement. It does not produce any AST node. The AST contextual directly collects what source id imports what other source id. Currently the import map is unused. In the future, import syntax will be used to implement partial compilation. Bug: v8:7793 Change-Id: I5f09e6254d7ca2e7bc1a93d2e2d82e202cafc8ef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649357 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#62080}
-
- 06 Jun, 2019 1 commit
-
-
Simon Zünd authored
This CL adds lint errors when 'let' bindings, arguments and labels are not used. Note that errors for 'const' bindings will be added later. In cases where arguments are actually needed to match the signature, the warning can be silenced by prefixing identifiers with "_". This might be needed for generic specializations or builtins called from TurboFan. Trying to use a variable or label that was marked with "_" results in a compilation error. Implicit arguments are not linted. They are implemented using exact string matching. Prefixing an implicit argument with "_" in a callee would break all callers as the names would no longer match. Drive-by: Fix all new lint errors in the existing Torque code. Bug: v8:7793 Change-Id: I68b3c59c76b956e9f88709e9388a40a19546ce52 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645092 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62027}
-
- 05 Jun, 2019 1 commit
-
-
Simon Zünd authored
R=tebbi@chromium.org Bug: v8:7793 Change-Id: Ibba7651f8bd6a8e06b7810a8190d210b4cd54be0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645324 Auto-Submit: Simon Zünd <szuend@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#62001}
-
- 27 May, 2019 1 commit
-
-
Clemens Hammacher authored
This replaces all typedefs that define types and not functions by the equivalent "using" declaration. This was done mostly automatically using this command: ag -l '\btypedef\b' src test | xargs -L1 \ perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg' Patchset 2 then adds some manual changes for typedefs for pointer types, where the regular expression did not match. R=mstarzinger@chromium.org TBR=yangguo@chromium.org, jarin@chromium.org Bug: v8:9183 Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61849}
-
- 20 May, 2019 1 commit
-
-
Tobias Tebbi authored
Macros are now inaccessible from CSA except if their declaration is marked with the "export" keyword. The implicit field accessors for class fields are always exported. In this CL, unwarranted access from CSA is prevented by appending a pseudo-random suffix to non-exported names. This is to be replaced by something more principled, namely by not including these macros at all in the headers included from CSA. Bug: v8:7793 Change-Id: I3ffb2e91a616623f81b4b4508e001ad0cf65d2c2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1615258 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#61672}
-
- 16 May, 2019 1 commit
-
-
Seth Brenith authored
This commit attempts to change as little behavior as possible, but it does require reordering the fields within Map to abide by Torque rules specifying that strong and weak fields must be in separate sections. Also includes some Torque compiler updates: - Allow enums (types extending from integral types) as class fields - Rename @ifdef to @if and add @ifnot for inverse checks - Allow void fields in class declarations, which take up no space and emit no accessors Bug: v8:8952 Change-Id: I1de6f34c1b15ed87d718666a05176980a218e97c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1480919 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#61588}
-
- 14 May, 2019 1 commit
-
-
Simon Zünd authored
This CL adds support for macros, builtins, generics and specializations for the "textDocument/symbol" request. To filter out implicitly created specializations, the "is_user_defined" flag is hoisted from Macro to the Declarable super class. As a side-effect, errors thrown during specialization now have the correct SourcePosition. Drive-by-change: Using "Goto Definition" on the identifier of the specialization will jump to the associated generic. Bug: v8:8880 Change-Id: I0c60571c58107375c1b5d2a8e620cf12a0f0f3fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609795 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#61486}
-
- 13 May, 2019 3 commits
-
-
Michael Hablich authored
This reverts commit a0fc5d72. Reason for revert: This now breaks other bot *shrug*. Original change's description: > Revert "[torque] Add ClassFlag(s) enum" > > This reverts commit 5343d789. > > Reason for revert: breaks roll: https://chromium-review.googlesource.com/c/chromium/src/+/1610023 > > Original change's description: > > [torque] Add ClassFlag(s) enum > > > > This removes the need for passing ever more boolean flags > > to the class constructor. > > > > Change-Id: I0271e1b96585252183dcf070eb440ebdaf2a270f > > Bug: v8:7793 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1607760 > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > > Reviewed-by: Daniel Clifford <danno@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#61444} > > TBR=danno@chromium.org,sigurds@chromium.org,tebbi@chromium.org > > Change-Id: I38566d8f4203f9cf1e759a3e915cafa86460e6e4 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: v8:7793 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609807 > Reviewed-by: Michael Hablich <hablich@chromium.org> > Commit-Queue: Michael Hablich <hablich@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61456} TBR=danno@chromium.org,sigurds@chromium.org,hablich@chromium.org,tebbi@chromium.org Change-Id: I9edb9a95cd30b6f4c9fd7502eb3a1124e3e8d977 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609808Reviewed-by:
Michael Hablich <hablich@chromium.org> Commit-Queue: Michael Hablich <hablich@chromium.org> Cr-Commit-Position: refs/heads/master@{#61458}
-
Michael Hablich authored
This reverts commit 5343d789. Reason for revert: breaks roll: https://chromium-review.googlesource.com/c/chromium/src/+/1610023 Original change's description: > [torque] Add ClassFlag(s) enum > > This removes the need for passing ever more boolean flags > to the class constructor. > > Change-Id: I0271e1b96585252183dcf070eb440ebdaf2a270f > Bug: v8:7793 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1607760 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Daniel Clifford <danno@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61444} TBR=danno@chromium.org,sigurds@chromium.org,tebbi@chromium.org Change-Id: I38566d8f4203f9cf1e759a3e915cafa86460e6e4 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609807Reviewed-by:
Michael Hablich <hablich@chromium.org> Commit-Queue: Michael Hablich <hablich@chromium.org> Cr-Commit-Position: refs/heads/master@{#61456}
-
Sigurd Schneider authored
This removes the need for passing ever more boolean flags to the class constructor. Change-Id: I0271e1b96585252183dcf070eb440ebdaf2a270f Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1607760 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#61444}
-
- 10 May, 2019 1 commit
-
-
Seth Brenith authored
This change generates functions that verify the things that Torque knows about objects and their fields. We still must implement each verifier function in objects-debug.cc, but we can call into the generated code to verify that field types match their Torque definitions. If no additional verification is required, we can use the macro USE_TORQUE_VERIFIER as a shorthand for a verifier that calls the corresponding generated function. A new annotation @noVerifier can be applied to both class and field definitions, to prevent generating verification code. This allows fully customized verification for complicated cases like JSFunction::prototype_or_initial_map, which might not exist at all, and JSObject::elements, which might be a one pointer filler map. Because Factory::InitializeJSObjectFromMap fills new objects with undefined values, and many verifiers need to deal with partially- initialized objects, the generated verifiers allow undefined values on every class deriving from JSObject. In cases where stricter checks were previously performed, they are kept in objects-debug.cc. Bug: v8:7793 Change-Id: I84034efadca89ba0aceddf92e886ffbfaa4c23fa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594042 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#61422}
-