aggregated remaining patches to correct use of extern "C" #18245
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Consistently place C++ use of extern "C" after all include directives, within the negative branch of _ASMLANGUAGE if used. Background from issue zephyrproject-rtos#17997: Declarations that use C linkage should be placed within extern "C" so the language linkage is correct when the header is included by a C++ compiler. Similarly #include directives should be outside the extern "C" to ensure the language-specific default linkage is applied to any declarations provided by the included header. See: https://en.cppreference.com/w/cpp/language/language_linkage Signed-off-by: Peter Bigot <[email protected]>
Remove extern "C" support from files that don't declare symbols subject to language linkage effects. Background from issue zephyrproject-rtos#17997: Declarations that use C linkage should be placed within extern "C" so the language linkage is correct when the header is included by a C++ compiler. Similarly #include directives should be outside the extern "C" to ensure the language-specific default linkage is applied to any declarations provided by the included header. See: https://en.cppreference.com/w/cpp/language/language_linkage Signed-off-by: Peter Bigot <[email protected]>
Move the tail include file outside the extern "C" block. Background from issue zephyrproject-rtos#17997: Declarations that use C linkage should be placed within extern "C" so the language linkage is correct when the header is included by a C++ compiler. Similarly #include directives should be outside the extern "C" to ensure the language-specific default linkage is applied to any declarations provided by the included header. See: https://en.cppreference.com/w/cpp/language/language_linkage Signed-off-by: Peter Bigot <[email protected]>
This header doesn't define any symbols with linkage. Signed-off-by: Peter Bigot <[email protected]>
Consistently place C++ use of extern "C" after all include directives, within the negative branch of _ASMLANGUAGE if used. In arch.h the extern "C" in the including context is left active during include of target-specific mpu headers to avoid more complex restructuring. Background from issue zephyrproject-rtos#17997: Declarations that use C linkage should be placed within extern "C" so the language linkage is correct when the header is included by a C++ compiler. Similarly #include directives should be outside the extern "C" to ensure the language-specific default linkage is applied to any declarations provided by the included header. See: https://en.cppreference.com/w/cpp/language/language_linkage Signed-off-by: Peter Bigot <[email protected]>
Remove extern "C" support from files that don't declare symbols subject to language linkage effects. Consistently place C++ use of extern "C" after all include directives, within the negative branch of _ASMLANGUAGE if used. Background from issue zephyrproject-rtos#17997: Declarations that use C linkage should be placed within extern "C" so the language linkage is correct when the header is included by a C++ compiler. Similarly #include directives should be outside the extern "C" to ensure the language-specific default linkage is applied to any declarations provided by the included header. See: https://en.cppreference.com/w/cpp/language/language_linkage Signed-off-by: Peter Bigot <[email protected]>
Consistently place C++ use of extern "C" after all include directives, within the negative branch of _ASMLANGUAGE if used. Remove extern "C" support from files that don't declare objects or functions. Background from issue zephyrproject-rtos#17997: Declarations that use C linkage should be placed within extern "C" so the language linkage is correct when the header is included by a C++ compiler. Similarly #include directives should be outside the extern "C" to ensure the language-specific default linkage is applied to any declarations provided by the included header. See: https://en.cppreference.com/w/cpp/language/language_linkage Signed-off-by: Peter Bigot <[email protected]>
Consistently place C++ use of extern "C" after all include directives, within the negative branch of _ASMLANGUAGE if used. Background from issue zephyrproject-rtos#17997: Declarations that use C linkage should be placed within extern "C" so the language linkage is correct when the header is included by a C++ compiler. Similarly #include directives should be outside the extern "C" to ensure the language-specific default linkage is applied to any declarations provided by the included header. See: https://en.cppreference.com/w/cpp/language/language_linkage Signed-off-by: Peter Bigot <[email protected]>
Consistently place C++ use of extern "C" after all include directives, within the negative branch of _ASMLANGUAGE if used. Background from issue zephyrproject-rtos#17997: Declarations that use C linkage should be placed within extern "C" so the language linkage is correct when the header is included by a C++ compiler. Similarly #include directives should be outside the extern "C" to ensure the language-specific default linkage is applied to any declarations provided by the included header. See: https://en.cppreference.com/w/cpp/language/language_linkage Signed-off-by: Peter Bigot <[email protected]>
Consistently place C++ use of extern "C" after all include directives, within the negative branch of _ASMLANGUAGE if used. Remove extern "C" support from files that don't declare objects or functions. Background from issue zephyrproject-rtos#17997: Declarations that use C linkage should be placed within extern "C" so the language linkage is correct when the header is included by a C++ compiler. Similarly #include directives should be outside the extern "C" to ensure the language-specific default linkage is applied to any declarations provided by the included header. See: https://en.cppreference.com/w/cpp/language/language_linkage Signed-off-by: Peter Bigot <[email protected]>
Consistently place C++ use of extern "C" after all include directives, within the negative branch of _ASMLANGUAGE if used. Remove extern "C" support from files that don't declare objects or functions. In arch/arc/arch.h the extern "C" in the including context is left active during an include to avoid more complex restructuring. Background from issue zephyrproject-rtos#17997: Declarations that use C linkage should be placed within extern "C" so the language linkage is correct when the header is included by a C++ compiler. Similarly #include directives should be outside the extern "C" to ensure the language-specific default linkage is applied to any declarations provided by the included header. See: https://en.cppreference.com/w/cpp/language/language_linkage Signed-off-by: Peter Bigot <[email protected]>
pabigot
requested review from
andrewboie,
andyross,
dcpleung and
galak
as code owners
pabigot
requested review from
MaureenHelm,
ioannisg,
nashif,
ruuddw,
vonhust and
wentongwu
as code owners
zephyrbot
added
area: X86
andrewboie
approved these changes
Aug 14, 2019
Contributor
andrewboie
left a comment
andrewboie
left a comment
There was a problem hiding this comment.
What can we do to make this not a constant source of bit-rot?
Contributor
Author
Something like #17997 (comment) could be added to the CI scripts to at least indicate the presence of nested includes. That technique is a bit fragile in the long term as |
ioannisg
approved these changes
Aug 14, 2019
Member
ioannisg
left a comment
ioannisg
left a comment
There was a problem hiding this comment.
I think this is a good cleanup patch, reviewers, pls take a look
carlescufi
approved these changes
Aug 15, 2019
dcpleung
approved these changes
Aug 15, 2019
wentongwu
approved these changes
Aug 15, 2019
ruuddw
requested changes
Aug 16, 2019
Member
ruuddw
left a comment
ruuddw
left a comment
There was a problem hiding this comment.
see comment for arch/arc/include/kernel_arch_data.h
ruuddw
approved these changes
Aug 16, 2019
ioannisg
approved these changes
Aug 19, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR, in combination with #18243 and #18244, should be sufficient to close #17997.
If the complexity is too high it can be broken down into chunks. I figured one big PR was better than the eight smaller ones that fell out of an initial partition.