Fix handling of __func__

It's not a string literal, it's a static array

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Fix tab handling in nextchar_slow()

... and streamline it a bit more, now that we get all \t hitting
the damn thing.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Fix ,##__VA_ARGS__ kludge

a) it actually allows any number of ##<arg>##... in between, as long as all
those args are empty.
b) it does *not* allow ## after __VA_ARGS__ - if it's there magic disappears

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Gentler handling of bitwise warnings in unary operations

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
simplify handling of newline/whitespace flags in expand()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
fix handling of -include

-include foo.h will search not only in the current directory...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
massage handling of wide string literals/character constants in tokenizer

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
switch to delayed handling of escape sequences

	#define A(x) #x
	A('\12')

should *not* yield "'\\n'"; the problem is that we are doing the conversion
too early.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
L ## 'a' is valid; so's L ## "a"

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Merge git://git.kernel.org/pub/scm/linux/kernel/git/viro/sparse into marge

Pull preprocessor fix from Al Viro.

1) we really, really shouldn't convert escape sequences too early;
   #define A(x) #x
   A('\12')
   should yield "'\\12'", *not* "'\\n'".

2) literal merging handles all sequences of string/wide string
   literals; result is wide if any of them is wide.  string_expression() is
   handling that wrong - "ab"L"c" is L"abc"

3) with support (no matter how cursory) of wide char constants
   and wide string literals, we really ought to handle
    #define A(x,y)
    A(L,'a')
   properly; it's not that tricky - combine() needs to recognize <IDENT["L"],CHAR>
   and <IDENT["L"],STRING> pairs.

4) '\777' is an error, while L'\777' is valid - the value should fit
   into unsigned char or unsigned counterpart of wchar_t.  Note that for string
   literals this happens *after* phase 6 - what matters is the type of literal
   after joining the adjacent ones (see (2) above).

5) stringifying should only quote \ and " in character constants and
   string literals,
    #define A(x) #x
    A(\n)
   should produce "\n", not "\\n"

6) we are losing L when stringifying wide string literals; that's
   wrong.

I've patches hopefully fixing the above.  Basically, I delay interpreting
escape sequences (past the bare minimum needed to find where the token ends)
until we are handling an expression with character constant or string literal
in it.

For character constants I'm keeping the token body in token->embedded -
4-character array replacing token->character.  That covers practically
all realistic instances; character constant *may* be longer than that,
but it has to be something like '\x000000000000000000000000041' - sure,
that's 100% legitimate C and it's going to be the same as '\x41' on
everything, but when was the last time you've seen something like that?
So I've split TOKEN_CHAR into 5 values - TOKEN_CHAR+1--TOKEN_CHAR+4 meaning
1--4 characters kept in ->embedded[], TOKEN_CHAR itself used for extremely
rare cases longer than that (token->string holds the body in that case).
TOKEN_WIDE_CHAR got the same treatment.

AFAICS, with those fixes we get the same behaviour as in gcc for
silently ignored by cpp if the string/char constant doesn't make it
out of preprocessor.  sparse still warns about those.  The situation
with this one is frustrating; on one hand C99 is saying that e.g.
'\x' is not a token.  Moreover, in a footnote in 6.4.4.4 it flat-out
requires diagnostics for such.  On the other hand... footnotes are
informative-only and having "other character" token match ' would
puts us in nasal daemon country, so gcc is free to do whatever it feels
like doing.  I think we shouldn't play that kind of standard-lawyering
*and* sparse has always warned on that, so I've left that warning
in place.

Note that real wchar_t handling is still not there; at the very least,
we need to decide what type will be used for that sucker (for gcc it's
int on all targets we care about), fix the handling of wide string literals
in initializers and evaluate_string() and stop dropping upper bits in
get_string_constant().  That would probably mean not using struct string
for wide ones, as well...  Hell knows; I don't want to touch that right
now.  If anything, I'd rather wait until we get to C11 support - they've
got much saner variants of wide strings there (char16_t/char32_t with
u and U as token prefix as L is used for wchar_t; there's also u8"..." for
UTF8 strings).