Commit Graph

5 Commits

Author SHA1 Message Date
Rafael Espindola 16c8cf0e11 Remove the hack that avoided mangling static functions in extern C contexts.
Weather we should give C language linkage to functions and variables with
internal linkage probably depends on how much code assumes it. The standard
says they should have no language linkage, but gcc and msvc assign them
C language linkage.

This commit removes the hack that was preventing the mangling on static
functions declare in extern C contexts. It is an experiment to see if we
can implement the rules in the standard.

If it turns out that many users depend on these functions and variables
having C language linkage, we should change isExternC instead and try
to convince the CWG to change the standard.

llvm-svn: 175937
2013-02-23 00:26:28 +00:00
Rafael Espindola 3e0e33d7e5 Mangle extern "C" functions whose names are not simple identifiers.
llvm-svn: 175166
2013-02-14 15:38:59 +00:00
Rafael Espindola 46d2b6bacf Partially revert r175117 so that we don't break assumptions about how
static functions in extern "C" contexts are mangled. Should fix the
bootstrap.

llvm-svn: 175132
2013-02-14 03:31:26 +00:00
Rafael Espindola f4187658fa Add a getLanguageLinkage method to VarDecls and FunctionDecls. Use it to fix
some cases where functions with no language linkage were being treated as having
C language linkage. In particular, don't warn in

extern "C" {
  static NonPod foo();
}

Since getLanguageLinkage checks the language linkage, the linkage computation
cannot use the language linkage. Break the loop by checking just the context
in the linkage computation.

llvm-svn: 175117
2013-02-14 01:18:37 +00:00
Fariborz Jahanian acdfa7acfe Fixes a code gen. bug by removing an assert.
It is ok to have c++-ness inside extern "C" 
block. Fixes pr6644.

llvm-svn: 101948
2010-04-20 22:02:31 +00:00