This also repros with the dangi calendar, since they seem to both report the year as wu-xu

Able to reproduce the issue on the latest canary: 67.0.3382.0 on Windows-10, Mac OS 10.13.3 and Linux Ubuntu 14.04. Pasting 'new Intl.DateTimeFormat("en-u-ca-chinese", { year: "numeric" }).formatToParts()' in console crashes the tab. Seeing similar behavior on older chrome version: 60.0.3312.20 as well hence triaging this as Non regression issue.

Crash id: 61b94750d7cdf575

Stack trace:
============
Thread 0 (id: 4684154) CRASHED [EXC_BAD_INSTRUCTION / EXC_I386_INVOP @ 0x0000000110895472 ] MAGIC SIGNATURE THREAD
Stack Quality52%Show frame trust levels
0x0000000110895472	(Google Chrome Framework -platform-posix.cc:381 )	v8::base::OS::Abort()
0x000000010d43881b	(Google Chrome Framework -runtime-intl.cc:329 )	v8::internal::(anonymous namespace)::AddElement(v8::internal::Handle<v8::internal::JSArray>, int, int, icu_60::UnicodeString const&, int, int, v8::internal::Isolate*)
0x000000010d432007	(Google Chrome Framework -runtime-intl.cc:403 )	v8::internal::Runtime_InternalDateFormatToParts(int, v8::internal::Object**, v8::internal::Isolate*)
0x00000039a0e897a5		
0x00000039a0f09b56		
0x00000039a0e92557		
0x00000039a0e8c662		
0x00000039a0e92557		
0x00000039a0e90c34		
0x00000039a0e89fa0		
0x000000010d18a2d4	(Google Chrome Framework -simulator.h:110 )	v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, bool, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*, v8::internal::Handle<v8::internal::Object>, v8::internal::Execution::MessageHandling, v8::internal::Execution::Target)
0x000000010d189eb7	(Google Chrome Framework -execution.cc:189 )	v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*)
0x000000010d110da3	(Google Chrome Framework -debug-evaluate.cc:42 )	v8::internal::DebugEvaluate::Global(v8::internal::Isolate*, v8::internal::Handle<v8::internal::String>, bool)
0x000000010ce6c966	(Google Chrome Framework -api.cc:9795 )	v8::debug::EvaluateGlobal(v8::Isolate*, v8::Local<v8::String>, bool)
0x000000010d60e93a	(Google Chrome Framework -v8-runtime-agent-impl.cc:263 )	v8_inspector::V8RuntimeAgentImpl::evaluate(v8_inspector::String16 const&, v8_inspector::protocol::Maybe<v8_inspector::String16>, v8_inspector::protocol::Maybe<bool>, v8_inspector::protocol::Maybe<bool>, v8_inspector::protocol::Maybe<int>, v8_inspector::protocol::Maybe<bool>, v8_inspector::protocol::Maybe<bool>, v8_inspector::protocol::Maybe<bool>, v8_inspector::protocol::Maybe<bool>, v8_inspector::protocol::Maybe<bool>, std::__1::unique_ptr<v8_inspector::protocol::Runtime::Backend::EvaluateCallback, std::__1::default_delete<v8_inspector::protocol::Runtime::Backend::EvaluateCallback> >)
0x000000010d5c41b9	(Google Chrome Framework -Runtime.cpp:1652 )	v8_inspector::protocol::Runtime::DispatcherImpl::evaluate(int, std::__1::unique_ptr<v8_inspector::protocol::DictionaryValue, std::__1::default_delete<v8_inspector::protocol::DictionaryValue> >, v8_inspector::protocol::ErrorSupport*)
0x000000010d5c2203	(Google Chrome Framework -Runtime.cpp:1313 )	v8_inspector::protocol::Runtime::DispatcherImpl::dispatch(int, v8_inspector::String16 const&, std::__1::unique_ptr<v8_inspector::protocol::DictionaryValue, std::__1::default_delete<v8_inspector::protocol::DictionaryValue> >)
0x000000010d59e331	(Google Chrome Framework -Protocol.cpp:822 )	v8_inspector::protocol::UberDispatcher::dispatch(std::__1::unique_ptr<v8_inspector::protocol::Value, std::__1::default_delete<v8_inspector::protocol::Value> >, int*, v8_inspector::String16*)
0x000000010d60915c	(Google Chrome Framework -v8-inspector-session-impl.cc:316 )	v8_inspector::V8InspectorSessionImpl::dispatchProtocolMessage(v8_inspector::StringView const&)
0x00000001110cd881	(Google Chrome Framework -InspectorSession.cpp:80 )	blink::InspectorSession::DispatchProtocolMessage(WTF::String const&, WTF::String const&)
0x000000010d688d7f	(Google Chrome Framework -devtools_agent.mojom-blink.cc:394 )	blink::mojom::blink::DevToolsSessionStubDispatch::Accept(blink::mojom::blink::DevToolsSession*, mojo::Message*)
0x000000010df5cbe4	(Google Chrome Framework -ipc_mojo_bootstrap.cc:865 )	IPC::(anonymous namespace)::ChannelAssociatedGroupController::AcceptOnProxyThread(mojo::Message)
0x000000010df5b51e	(Google Chrome Framework -bind_internal.h:447 )	base::internal::Invoker<base::internal::BindState<void (IPC::(anonymous namespace)::ChannelAssociatedGroupController::*)(mojo::Message), scoped_refptr<IPC::(anonymous namespace)::ChannelAssociatedGroupController>, base::internal::PassedWrapper<mojo::Message> >, void ()>::Run(base::internal::BindStateBase*)
0x000000010dc14ba7	(Google Chrome Framework -callback.h:95 )	base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)
0x000000010d70ce51	(Google Chrome Framework -thread_controller_impl.cc:162 )	blink::scheduler::internal::ThreadControllerImpl::DoWork(blink::scheduler::internal::SequencedTaskSource::WorkType)
0x000000010dc14ba7	(Google Chrome Framework -callback.h:95 )	base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)
0x000000010dc39423	(Google Chrome Framework -message_loop.cc:391 )	base::MessageLoop::RunTask(base::PendingTask*)
0x000000010dc39907	(Google Chrome Framework -message_loop.cc:403 )	base::MessageLoop::DoWork()
0x000000010dc3b8b9	(Google Chrome Framework -message_pump_mac.mm:462 )	base::MessagePumpCFRunLoopBase::RunWork()
0x000000010dc2d339	(Google Chrome Framework + 0x020fc339 )	base::mac::CallWithEHFrame(void () block_pointer)
0x000000010dc3b1de	(Google Chrome Framework -message_pump_mac.mm:438 )	base::MessagePumpCFRunLoopBase::RunWorkSource(void*)
0x00007fff2a918720	(CoreFoundation + 0x000a3720 )	__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
0x00007fff2a9d20ab	(CoreFoundation + 0x0015d0ab )	__CFRunLoopDoSource0
0x00007fff2a8fb25f	(CoreFoundation + 0x0008625f )	__CFRunLoopDoSources0
0x00007fff2a8fa6dc	(CoreFoundation + 0x000856dc )	__CFRunLoopRun
0x00007fff2a8f9f42	(CoreFoundation + 0x00084f42 )	CFRunLoopRunSpecific
0x00007fff2c9cbc15	(Foundation + 0x00020c15 )	-[NSRunLoop(NSRunLoop) runMode:beforeDate:]
0x000000010dc3bf2d	(Google Chrome Framework -message_pump_mac.mm:736 )	base::MessagePumpNSRunLoop::DoRun(base::MessagePump::Delegate*)
0x000000010dc3acfd	(Google Chrome Framework -message_pump_mac.mm:189 )	base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*)
0x000000010dc5f804	(Google Chrome Framework -run_loop.cc:130 )	<name omitted>
0x0000000111c1ed45	(Google Chrome Framework -renderer_main.cc:247 )	content::RendererMain(content::MainFunctionParams const&)
0x000000010d82ed58	(Google Chrome Framework -content_main_runner.cc:703 )	content::ContentMainRunnerImpl::Run()
0x000000010f038eef	(Google Chrome Framework -main.cc:453 )	service_manager::Main(service_manager::MainParams const&)
0x000000010d82e2a3	(Google Chrome Framework -content_main.cc:19 )	content::ContentMain(content::ContentMainParams const&)
0x000000010bb35572	(Google Chrome Framework -chrome_main.cc:101 )	ChromeMain
0x000000010b9e839b	(Google Chrome Helper -chrome_exe_main_mac.cc:165 )	main
0x00007fff5220d114	(libdyld.dylib + 0x00001114 )	start

Users experienced this crash on the following builds:

Linux Beta 66.0.3359.66 -  1.45 CPM, 1 reports, 1 clients (signature v8::internal::`anonymous namespace'::AddElement)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

d8> new Intl.DateTimeFormat("en-u-ca-chinese", { year: "numeric" }).format()
"2018(wu-xu)"

d8> new Intl.DateTimeFormat("zh-u-ca-chinese", { year: "numeric" }).format()
"2018戊戌年"


So, v8 behaves like Chakra when formatting. 

With , https://chromium-review.googlesource.com/#/c/v8/v8/+/1002735 (to treat UDAT_RELATED_YEAR (=34) as 'year' [1]),   I got 

d8>  new Intl.DateTimeFormat("en-u-ca-chinese", { year: "numeric" }).formatToParts()
[{type: "year", value: "2018"}, {type: "literal", value: "("}, {type: "year", value: "wu-xu"}, {type: "literal", value: ")"}]

d8>  new Intl.DateTimeFormat("en-u-ca-chinese", { year: "numeric" }).formatToParts()
[{type: "year", value: "2018"}, {type: "year", value: "戊戌"}, {type: "literal", value: "年"}]


[1] This is not quite right. We may need a spec revision to handle this case (related year field). In the meantime, we may have to live with this 'hack'.  

I brought this up to TC39 at https://github.com/tc39/ecma402/issues/225, and anba's comment that the calendar should not be taken into account when picking the format seems correct, though I don't agree that its the fundamentally most correct choice. I vote that if we handle related years, they should get their own "type" string so that there is only one "year"

Thanks a lot, Jack !  (just for my own record: marginally related to this - it's a different issue - is  bug v8:5299  ). 

> I vote that if we handle related years, they should get their own "type" string so that there is only one "year"

I agree with you. 

> anba's comment that the calendar should not be taken into account when picking the format seems correct, though I don't agree that its the fundamentally most correct choice.

I also second your "though ..." part. 

According to the current spec, that's what to do, but I'm not sure what was the motivation for the current spec. CLDR has different lists of patterns for different calendar (Gregorian, Chinese, Islamic* etc), but the current Ecma 402 spec dictates that the default calendar for a given locale (in most cases, Gregorian) be used to pick the best matching pattern for a given 'skeleton' (options) while still using the calendar to calculate year, month, day, etc. 

That part of the spec seems relatively new (I don't remember seeing that before) but could surprise Ecma 402 users. 

https://chromium-review.googlesource.com/1006915 is kinda hack, but works. 

d8> new Intl.DateTimeFormat("en-u-ca-chinese").format()
"2/26/35"
d8> new Intl.DateTimeFormat("en-u-ca-chinese").formatToParts()
[{type: "month", value: "2"}, {type: "literal", value: "/"}, {type: "day", value: "26"}, {type: "literal", value: "/"}, {type: "year", value: "35"}]

Will add a test. 

A test was added to the CL. 

d8> new Intl.DateTimeFormat("en-u-ca-chinese", {year: 'numeric').format()
"35"
d8> new Intl.DateTimeFormat("en-u-ca-chinese", {year: 'numeric').formatToParts()
[{type: "year", value: "35"}]

> This also repros with the dangi calendar, since they seem to both report the year as wu-xu

off-topic: Korean dangi calendar was incorrectly named. 'dangi' should be identical to Gregorian calendar except for year has to be shifted by 2333.  
For Korean luni-solar calendar (like Chinese calendar), a different name should be used.  

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/98c0cd9f8f353e3457f15e394435e4a1931aae77

commit 98c0cd9f8f353e3457f15e394435e4a1931aae77
Author: Jungshik Shin <jshin@chromium.org>
Date: Thu Apr 12 06:14:47 2018

Use the base locale when getting the best match pattern

This is to fix an assertion failure in formatToParts when
Chinese calendar is specified with 'u-ca-chinese'.

See https://github.com/tc39/ecma402/issues/225 . This CL
is a temporary work-around to get v8 match the spec in terms
of the external behavior, but it's not taking the steps in
the spec, yet.

Moreover, the spec may have to be revised as to how to pick the best
match pattern when the default calendar for a locale is different from
the calendar specified via 'u-ca'. How to handle 'related year' part
also needs to be specified.

Bug:  chromium:826549 
Test: intl/date-format/format-with-extensions
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I1f9a2467e86e71e024bc9babe18f16e49746008e
Reviewed-on: https://chromium-review.googlesource.com/1006915
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52556}
[modify] https://crrev.com/98c0cd9f8f353e3457f15e394435e4a1931aae77/src/objects/intl-objects.cc
[add] https://crrev.com/98c0cd9f8f353e3457f15e394435e4a1931aae77/test/intl/date-format/format-with-extensions.js

About the dangi calendar, I feel like that is a CLDR or ICU issue? I know fairly little about non-Gregorian calendars, but if I remember correctly, if you run `udatpg_getBestPattern("en@calendar=dangi", "yy", …) it will return "r(U)" and print "2018(wu-xu)" exactly like the Chinese calendar. If http://cldr.unicode.org/development/development-process/design-proposals/chinese-calendar-support is to be believed, there are a number of calendars that this behavior could impact.

> About the dangi calendar, I feel like that is a CLDR or ICU issue?

That's a CLDR issue. I should have intervened when it's added, but I didn't pay enough attention to that. Anyway, I filed a CLDR ticket ( https://unicode.org/cldr/trac/ticket/11054 ). 

I guess it missed v8's 6.7 branch cut [1]  I'm making a request to merging to v8's 6.7 branch (that is used with Chrome 67 branch). 

To merge approver/reviewer:

  The actual code change is a simple 2-liner and covered by a new test added. 
(the CL is recorded in comment 14). 

Merging to earlier branches will be considered after some baking in dev/canary.

[1] A branch was made a few hours after I landed the CL in comment 14, but perhaps, the branching point is earlier than that.
 
https://chromium.googlesource.com/v8/v8.git/+log/13bb09294f054ec3a5ef10fdb285d4550f01a0c4/src/objects/intl-objects.cc

Your change meets the bar and is auto-approved for M67. Please go ahead and merge the CL to branch 3396 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Pls merge your change to M67 branch 3396 by 1:00 PM PT Monday (04/16/18) so we can pick it up for next M67 dev release. Thank you.

+hablich@ for V8 merge approval

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/358483e6c01cc6c1849efcbc0045bce234cbd4fd

commit 358483e6c01cc6c1849efcbc0045bce234cbd4fd
Author: Jungshik Shin <jshin@chromium.org>
Date: Tue Apr 17 04:14:24 2018

[Merge to 6.7] Use the base locale when getting the best match pattern

This is to fix an assertion failure in formatToParts when
Chinese calendar is specified with 'u-ca-chinese'.

See https://github.com/tc39/ecma402/issues/225 . This CL
is a temporary work-around to get v8 match the spec in terms
of the external behavior, but it's not taking the steps in
the spec, yet.

Moreover, the spec may have to be revised as to how to pick the best
match pattern when the default calendar for a locale is different from
the calendar specified via 'u-ca'. How to handle 'related year' part
also needs to be specified.

NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true

Bug:  chromium:826549 
Test: intl/date-format/format-with-extensions
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I1f9a2467e86e71e024bc9babe18f16e49746008e
Reviewed-on: https://chromium-review.googlesource.com/1006915
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#52556}(cherry picked from commit 98c0cd9f8f353e3457f15e394435e4a1931aae77)
Reviewed-on: https://chromium-review.googlesource.com/1014277
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/branch-heads/6.7@{#16}
Cr-Branched-From: 8457e810efd34381448d51d93f50079cf1f6a812-refs/heads/6.7.288@{#2}
Cr-Branched-From: e921be5c4f2c6407936bde750992dedbf47c1016-refs/heads/master@{#52547}
[modify] https://crrev.com/358483e6c01cc6c1849efcbc0045bce234cbd4fd/src/objects/intl-objects.cc
[add] https://crrev.com/358483e6c01cc6c1849efcbc0045bce234cbd4fd/test/intl/date-format/format-with-extensions.js

Per comment #21, this is already merged to M67. If nothing is pending, pls remove "Merge-Approved-67" & "Merge-Request-6.7" labels. Thank you.

hablich@, this merge got auto approved at #18. Hope you're ok with it.

We're considering adding specific relatedYear support in ECMA-402 at https://github.com/tc39/ecma402/pull/227 . So far the response is positive, so this patch may be merged soon following review in the Intl call.

See https://github.com/tc39/ecma402/issues/231 .