[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile

2022-11-05 Thread lhyatt at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971

Lewis Hyatt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |13.0
 Resolution|--- |FIXED

--- Comment #10 from Lewis Hyatt  ---
Fixed for GCC 13.

[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile

2022-11-05 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Lewis Hyatt :

https://gcc.gnu.org/g:3ad2167bbac8ae83b1e91305b105ab5287bdac55

commit r13-3697-g3ad2167bbac8ae83b1e91305b105ab5287bdac55
Author: Lewis Hyatt 
Date:   Wed Jun 15 18:06:53 2022 -0400

c++: libcpp: Support raw strings with newlines in directives [PR55971]

It's not currently possible to use a C++11 raw string containing a newline
as
part of the definition of a macro, or in any other preprocessing directive,
such as:

 #define X R"(two
lines)"

 #error R"(this error has
two lines)"

Add support for that by relaxing the conditions under which
_cpp_get_fresh_line() refuses to get a new line. For the case of lexing a
raw
string, it's OK to do so as long as there is another line within the
current
buffer. The code in cpp_get_fresh_line() was refactored into a new function
get_fresh_line_impl(), so that the new logic is applied only when
processing a
raw string and not any other times.

libcpp/ChangeLog:

PR preprocessor/55971
* lex.cc (get_fresh_line_impl): New function refactoring the code
from...
(_cpp_get_fresh_line): ...here.
(lex_raw_string): Use the new version of get_fresh_line_impl() to
support raw strings containing new lines when processing a
directive.

gcc/testsuite/ChangeLog:

PR preprocessor/55971
* c-c++-common/raw-string-directive-1.c: New test.
* c-c++-common/raw-string-directive-2.c: New test.

gcc/c-family/ChangeLog:

PR preprocessor/55971
* c-ppoutput.cc (adjust_for_newlines): Update comment.

[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile

2022-06-17 Thread lhyatt at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gcc dot gnu.org

--- Comment #8 from Lewis Hyatt  ---
I submitted a patch for this here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596820.html

[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile

2020-02-06 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971

Marek Polacek  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||mpolacek at gcc dot gnu.org

--- Comment #7 from Marek Polacek  ---
An even simpler test:

#define MY_RAW_STRING R"(My raw string
multiline)"

We still don't handle it right.

[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile

2013-01-14 Thread redi at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971



--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-14 
15:39:35 UTC ---

probably another dup of Bug 52852


[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile

2013-01-14 Thread nachms+gcc at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971



--- Comment #2 from Nach nachms+gcc at gmail dot com 2013-01-14 15:47:25 UTC 
---

Does look similar. Although this bug here is in the definition of the macro,

while that bug is in the call of the macro.



I'm sure they're related, but it'd be a shame if one was fixed, and the other

was overlooked.


[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile

2013-01-14 Thread redi at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971



--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-14 
15:56:02 UTC ---

I think basically the preprocessor doesn't support raw strings.



Fix that and both bugs should go away.


[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile

2013-01-14 Thread jakub at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971



Jakub Jelinek jakub at gcc dot gnu.org changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 
16:35:52 UTC ---

That's not the case, because most of the raw string support is in the

preprocessor.


[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile

2013-01-14 Thread redi at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971



Jonathan Wakely redi at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-14

 Ever Confirmed|0   |1



--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-14 
16:43:55 UTC ---

Thanks, Jakub, for some reason I thought it had ben done in the FE.



Let's confirm this then, it's not an exact dup.


[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile

2013-01-14 Thread jakub at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971



Jakub Jelinek jakub at gcc dot gnu.org changed:



   What|Removed |Added



 CC||jason at gcc dot gnu.org,

   ||tromey at gcc dot gnu.org



--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 
17:33:02 UTC ---

This is about:

  if (pfile-state.in_directive

  || pfile-state.parsing_args

  || pfile-state.in_deferred_pragma)

{

  cur--;

  type = CPP_OTHER;

  cpp_error_with_line (pfile, CPP_DL_ERROR, token-src_loc, 0,

   unterminated raw string);

  break;

}

in lex_raw_string, in this case state.in_directive is true, as it is in #define

directive.  But just removing state.in_directive from that condition isn't

enough,

1537  _cpp_process_line_notes (pfile, false);

1538  if (!_cpp_get_fresh_line (pfile))

doesn't handle this case correctly.