Moves VSNPrintf, SNPrintf and StrNCpy out of utils/utils.h into
base/strings.h.
Bug: v8:11879
Change-Id: I0e165cb27c42f89c9acd1c6378514b40a90cd18d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972732
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75308}
The adding of base:: was mostly prepared using git grep and sed:
git grep -l <pattern> | grep -v base/vector.h | \
xargs sed -i 's/\b<pattern>\b/base::<pattern>/
with lots of manual clean-ups due to the resulting
v8::internal::base::Vectors.
#includes were fixed using:
git grep -l "src/utils/vector.h" | \
axargs sed -i 's!src/utils/vector.h!src/base/vector.h!'
Bug: v8:11879
Change-Id: I3e6d622987fee4478089c40539724c19735bd625
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968412
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75243}
Using the default cctest TEST(...) macro causes later writes to
FLAG_stack_size to have no effect, because the StackGuard reads
that flag's value during Isolate initialization, which is done
before the test body is executed. This patch changes the two
existing tests that accidentally did this to UNINITIALIZED_TEST,
putting them in charge of Isolate creation, thereby ensuring that
the intended stack size is configured correctly.
Change-Id: Ib030795ef46f23d576f6dbbd26b347ac804b5085
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2862778
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74309}
These simplify production of extra information in stack traces or
dereferencing source maps in processing stack traces. While these
can be managed externally, this can be very complicated in
environments where scripts come from many different sources,
possibly not even under embedder control. Since V8 already has
easy access to this information, it's nice to share it with
embedders.
Bug: v8:11509
Change-Id: Ic5a1685adf4cdf456bdf7191ce815f728cf491e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2724571
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73148}
As outlined in the design document linked below, we're removing the
support for the non-standard Function.displayName property for the
purpose of Error.stack and DevTools Inspector stack traces. The
motivation here is that the negative lookup is costly, and we have
Function.name as a standard alternative (configurable since ES6 for
exactly this reason).
I dediced to go with JSFunction::GetDebugName(), since
JSFunction::GetName() was confusing in that it'd only get the "name"
property's value if it's a data property, but not with accessors.
JSFunction::GetDebugName() makes it clear that this is really a debug
helper function and might not give you the "name" property value.
Doc: https://bit.ly/devtools-function-displayName-removal
Bug: v8:8742, chromium:1177685, chromium:1077657, chromium:17356
Change-Id: I7717585cbace626174b2f2ed2a4f68f75429eca1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692189
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72715}
Remove the ambient dependency on the currently entered isolate, let the
embedder pass it in explicitly.
Bug: v8:11287
Change-Id: I03690390a308a59e2c6ea5c6ae268780d836b717
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2608209
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72105}
- Use C++ primitives (int, bool) for the ScriptOrigin constructor.
- Deprecate the old accessors and constructor
Bug: v8:11195
Change-Id: I739edd6b4c58e19a8a16ddce863eea14ec933697
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555005
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71384}
Using the Template::Set method which const char name is more ergonomic
and it creates directly an internalized name instead of the normal
string that most users pass in.
Bug: v8:10884
Change-Id: I00c6d49fee9de16b8ebbfe75be4b383831f0d4dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400980
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69787}
String::NewFromLiteral is a templated function that takes a char[N]
argument that can be used as an alternative to String::NewFromUtf8 and
returns a Local<String> rather than a MaybeLocal<String> reducing the
number of ToLocalChecked() or other checks.
Since the string length is known at compile time, it can statically
assert that the length is less than String::kMaxLength, which means that
it can never fail at runtime.
This also converts all found uses of NewFromUtf8 taking a string literal
or a variable initialized from a string literal to use the new API. In
some cases the types of stored string literals are changed from const
char* to const char[] to ensure the size is retained.
This API does introduce a small difference compared to NewFromUtf8. For
a case like "abc\0def", NewFromUtf8 (using length -1 to infer length)
would treat this as a 3 character string, whereas the new API will treat
it as a 7 character string.
As a drive-by fix, this also fixes all redundant uses of
v8::NewStringType::kNormal when passed to any of the String::New*
functions.
Change-Id: Id96a44bc068d9c4eaa634aea688e024675a0e5b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089935
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66622}
Reverting https://chromium-review.googlesource.com/c/v8/v8/+/1741660
This fixed one bug but caused a lot of others and on balance I think
reverting it is the lesser evil.
This also fixed generator-relocation.js because
(function*(){}).constructor is the function constructor and we try to
set a breakpoint on line 3.
Bug: chromium:109362, chromium:1028689
Fixes: v8:9721
Change-Id: I1bfe6ec57ce77ea7292df91266311f5c0194947e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1940259
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65232}
The spec says we have to insert some wrapper code with extra line breaks
in it, but this confuses users when they see stack traces as the line
numbers come from the code with the wrapper, instead of the original.
This CL sets line_offset on the script to indicate that line numbers
should be offset by the 2 extra line breaks when reading them out e.g.
for the purpose of stack traces.
Bug: chromium:109362
Change-Id: Ib608e1043c38b595b1466766f7592e993ee3b996
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741660
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63127}
This CL moves the code responsible for serializing a stack trace frame into
a string, out of messages.cc and into stack-frame-info.cc. Instead of
symbolizing the stack trace frame while serializing, the code is changed to
work on top of StackTraceFrame and StackFrameInfo objects.
The result is that the serialization code no longer cares when a stack trace
frame is symbolized. Symbolization could happen eagerly during capturing, or
lazily the first time any of StackFrameInfo fields are accessed.
Drive-by: Existing users of StackFrameBase::ToString are adapted to the
new SerializeStackTraceFrame API. This includes Isolate::PrintCurrentStackTrace,
which is changed to re-use the existing capturing and serializing mechanism.
Bug: v8:8742
Change-Id: Ic7fd80668c9d993e99d586ef7fe022850104c34f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631414
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62522}
Mechanical change with the exception of one threaded test, that had
to be turned into a normal test to turn green.
R=jgruber@chromium.org
Bug: v8:9183
Change-Id: Ie7c3350415e21f93e8161a3c844cbe165ecd7da5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612899
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61520}
