autofill_regex_constants.cc(78) : error C2001: newline in constant

[Feng Yangang]

When I compiled chromium, I found the following error：autofill_regex_constants.cc(78) : error C2001: newline in constant.....

System version is windows 8.1, 64bit, system language is chinese. In addition to modifying “the language used in non Unicode programs”, but also how to modify？

[Ilya Sherman]

Hmm, I wonder if that means that one of our Chinese regexes is incorrect.  If you open autofill_regex_constants.cc in a Unicode-aware text editor, does one of the regex constants indeed have a newline in it?  (FWIW, I don't see any obvious errors on line 78.)

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Feng Yangang]

Is it related to system language? If I set it to English, I can compile it. Otherwise, if the file(autofill_regex_constants.cc) is stored in gb181355 format, it also can compile and no error.

I said set the "非 Unicode程序中使用的当前语言" from "中文（简体，中国）" to “英语（美国）”.

在 2015年12月2日星期三 UTC+8下午1:35:00，Ilya Sherman写道：

[PhistucK]

I thought all of the sources are UTF-8 encoded by now.

☆PhistucK

---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Ilya Sherman]

You might try reverting https://codereview.chromium.org/1090373002 locally and seeing if that helps with the compilation.  If so, then perhaps the extra build step is still needed.

[Scott Graham]

I believe this is just cl being dumb. It assumes local code page, not utf8 if there's no BOM.

This comes up occasionally e.g. https://groups.google.com/a/chromium.org/d/msg/chromium-dev/3DV8Huz5C0M/Q-Vs4VIjwq0J and sadly https://connect.microsoft.com/VisualStudio/feedback/details/888437/it-is-impossible-to-use-utf-8-without-bom-in-source-files. The only workaround we have on Windows is to set the system language.

As I suggest on that thread, I believe sticking to [32-126] is the One True Solution, but since most (English-speaking) devs aren't affected, that ship carelessly sailed off a while ago, and left a poop-trail of UTF8.

/blockthatmetaphor

[WC Leung]

I believe that this is a bug in the file in the gyp file. Note that lines 5-7 of autofill_regex_constants.cc

// This file contains UTF8 strings that we want as char arrays. To avoid

// different compilers, we use a script to convert the UTF8 strings into

// numeric literals (\x##).

If the procedure is the comment is carried out correctly, the error should not happen.

Regards,
WC Leung.

[Yuta Kitamura]

On Thu, Dec 3, 2015 at 8:56 AM, Scott Graham <sco...@chromium.org> wrote:

I believe this is just cl being dumb. It assumes local code page, not utf8 if there's no BOM.

This comes up occasionally e.g. https://groups.google.com/a/chromium.org/d/msg/chromium-dev/3DV8Huz5C0M/Q-Vs4VIjwq0J and sadly https://connect.microsoft.com/VisualStudio/feedback/details/888437/it-is-impossible-to-use-utf-8-without-bom-in-source-files. The only workaround we have on Windows is to set the system language.

As I suggest on that thread, I believe sticking to [32-126] is the One True Solution, but since most (English-speaking) devs aren't affected, that ship carelessly sailed off a while ago, and left a poop-trail of UTF8.

/blockthatmetaphor

Yes, this is right. cl always uses the system locale (not even the user's locale), and this behavior isn't overridable AFAIK. These are problematic in developers on a locale using multibyte characters (basically CJK). The only workaround I know is to set the system's locale to US English.

[Daniel Bratell]

On Thu, 03 Dec 2015 00:56:36 +0100, Scott Graham <sco...@chromium.org> wrote:

I believe this is just cl being dumb. It assumes local code page, not utf8 if there's no BOM.

This comes up occasionally e.g. https://groups.google.com/a/chromium.org/d/msg/chromium-dev/3DV8Huz5C0M/Q-Vs4VIjwq0J and sadly https://connect.microsoft.com/VisualStudio/feedback/details/888437/it-is-impossible-to-use-utf-8-without-bom-in-source-files. The only workaround we have on Windows is to set the system language.

As I suggest on that thread, I believe sticking to [32-126] is the One True Solution, but since most (English-speaking) devs aren't affected, that ship carelessly sailed off a while ago, and left a poop-trail of UTF8.

That seems very reasonable and even if we're not there right now, adding some presubmit hooks should be able to bring us there. For files that depend on very specific bytes (test data for instance), storing them as binary files is probably the right thing to do.

(though I'd like some code points below 32 as well. LF for instance. :-) )

/Daniel

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */