Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more compilers to CI and increase FMT_PEDANTIC warning levels #736

Merged
merged 18 commits into from
Jun 6, 2018
Merged

Add more compilers to CI and increase FMT_PEDANTIC warning levels #736

merged 18 commits into from
Jun 6, 2018

Conversation

eliaskosunen
Copy link
Contributor

@eliaskosunen eliaskosunen commented May 11, 2018

In reference to #730

This PR contains:

  1. Add the following compilers/environments to Travis (all on Linux with Debug configuration):
  • clang 6.0 with C++14
  • clang 4.0 with C++11
  • g++ 4.8 with C++11
  • g++ 4.4 with C++11
  1. Add Visual Studio 2013 and 2015 to Appveyor, while removing Release builds to decrease build time
  2. Include a lot more warnings in FMT_PEDANTIC, see CMakeLists.txt for more information
  3. Add FMT_WERROR, which is now used on Travis but not on Appveyor
  4. Fix every warning on g++ and clang, either by explicitly ignoring them through compiler pragmas or actually fixing them
  5. Restructure appveyor.yml and remove appveyor-build.py

Rationale behind some of the changes:

  1. Clang is a major compiler on Linux, and is not equivalent to Apple clang. Dismissing it entirely would be silly. g++ 4.8, because it's the default compiler on Trusty. Also, there are now also tests with C++11, which I think is beneficial.
  2. There are now 6 build jobs on Appveyor. That number would increase to 12 should release builds be added back. I think it's more important to test multiple platforms rather than multiple build configurations that really only change the compiler optimization level. Because the free Travis version only allows 4 build jobs to be run in parallel, doing the same thing there would decrease the total number of jobs from 10 to 8 and thus decrease build time significantly, but I'm not sure if we want to do that
  3. -
  4. Not used on Appveyor because there are plenty of warnings yet to be fixed
  5. -
  6. This way we'll see the actual build messages in the dedicated Appveyor interface

(Potentially) blocking issues before merging:

  • The recent ranges-PR Add support for ranges, containers and types tuple interface... #735 doesn't support C++11 and causes build errors
  • Build errors on g++ 4.8 and 4.4
  • Build errors on Visual Studio 2013
  • Test failures on all Visual Studio versions over at Appveyor
  • Warnings on Visual Studio
  • I'm not sure which g++ and clang versions introduced which warnings, so adding/suppressing these could lead to errors on compiler versions that aren't tested

@eliaskosunen
Copy link
Contributor Author

Testing with C++98 could also be useful.

Copy link
Contributor

@vitaut vitaut left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for the PR! I think it's a nice improvement over the old config, but I'm a bit concerned about many new ifdefs to suppress warnings in the code. I suggest removing these for now together with noisy warnings and discuss whether they need to be enabled separately on a one-by-one case. And a few more comments inline.

.travis.yml Outdated

matrix:
exclude:
- os: osx
env: BUILD=Doc
- env: TRAVIS_EMPTY_JOB_WORKAROUND=true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this for?

Copy link
Contributor Author

@eliaskosunen eliaskosunen May 13, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When creating a Travis build matrix, that is sometimes necessary. I just forgot it there. Fixed.

.travis.yml Outdated
# Documentation
- env: CXX_COMPILER=g++-6 BUILD=Doc
sudo: required
compiler: gcc
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CXX_COMPILER and compiler are probably unneeded for building docs

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True.

.travis.yml Outdated
- g++-6
install:
- DEPS_DIR="${TRAVIS_BUILD_DIR}/deps"
- mkdir -p ${DEPS_DIR} && cd ${DEPS_DIR}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is DEPS_DIR used?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing, removed.

@@ -30,10 +30,10 @@
# define FMT_HAS_INCLUDE(x) 0
#endif

#if defined(__GNUC__) && !defined(__clang__)
# define FMT_GCC_VERSION (__GNUC__ * 100 + __GNUC_MINOR__)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please bring FMT_GCC_VERSION back as it is used in this header.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's also used in format.h before the inclusion of core.h, but sure.

#if FMT_GCC_VERSION >= 406
# pragma GCC diagnostic push
# pragma GCC diagnostic ignored "-Wuseless-cast"
#endif
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest either fixing the warning or not setting -Wuseless-cast in CMake config if the warning is too noisy. Similarly in other cases since it's better not to pollute the code with numerous ifdefs for spurious warnings.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not enabling the warning during testing is only ignoring the problem. People may and will have that warning enabled when including fmt, and they'll have to resort to similar pragma-trickery in order to silence the compiler about issues they have no control over. It's better to explicitly disable a single warning for a small piece of code.

For that specific case, though, fixing the warning should be possible with ease. I don't think the same can be said for the other instances.

configuration:
- Debug
- Release
configuration: Debug
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should build both in Debug and Release modes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That'll increase the build time from ~30 mins to an hour (6 -> 12 jobs, 5 min/job), but sure. I think we should look into some ways to decrease this time.


build_script:
- python support/appveyor-build.py
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please keep the Python script, since it's easier to deal with configs in one language and we might want to reintroduce MinGW at some point.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that the Python script was much more pleasant to work with. By using the Appveyor's built-in build functionality, we can have build messages and test results reported in a more aesthetically pleasing (tm) way, as you can see here. I'll look into incorporating the Python script back, prioritizing bringing it back over the PowerShell trickery.

@@ -195,33 +195,39 @@ TEST(ExpectSystemErrorTest, DoesNotGenerateUnreachableCodeWarning) {
}

TEST(AssertionSyntaxTest, ExceptionAssertionBehavesLikeSingleStatement) {
if (::testing::internal::AlwaysFalse())
if (::testing::internal::AlwaysFalse()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's necessary, just adds syntactic noise.

Fix (some) of the compiler errors with them
Increase warning level on MSVC when compiling with FMT_PEDANTIC
Fix some of the MSVC warnings
Implement C++11 integer_sequence
@eliaskosunen
Copy link
Contributor Author

How serious are we about C++98 support or older compilers? Reading the docs I got the impression that C++98 would be dropped for 5.0, is this true? What comes to older compilers, g++ 4.8 and 4.4 and Visual Studio 2013 builds are currently failing.

@mwinterb
Copy link
Contributor

Rvalue references, variadic templates, decltype, trailing return types, and deleted functions all seem unconditionally required in the master branch. Unrestricted unions are sort-of required (there's a fallback to struct for GCC 4.4 only).
Feature-wise it seems like VS2015 (unrestricted unions, 2013 for variadic templates), GCC 4.4 (trailing return types), and Clang 3.0 (deleted functions) are probably the minimum baselines for the "big three".
I doubt supporting a compiler without variadic template support is something that's going to come back in v5.

@eliaskosunen
Copy link
Contributor Author

It looks like that's indeed the case. The documentation should definitely be updated prior to release, as it claims support for VS 2010 and C++98 with minor restrictions.

@vitaut
Copy link
Contributor

vitaut commented May 16, 2018

How serious are we about C++98 support or older compilers? Reading the docs I got the impression that C++98 would be dropped for 5.0, is this true?

C++98 is only supported on the 4.x branch. The master branch and the forthcoming 5.0 release requires some C++11 features such as variadic templates and type traits.

Rvalue references, variadic templates, decltype, trailing return types, and deleted functions all seem unconditionally required in the master branch. Unrestricted unions are sort-of required (there's a fallback to struct for GCC 4.4 only). Feature-wise it seems like VS2015 (unrestricted unions, 2013 for variadic templates), GCC 4.4 (trailing return types), and Clang 3.0 (deleted functions) are probably the minimum baselines for the "big three". I doubt supporting a compiler without variadic template support is something that's going to come back in v5.

You are completely right. I plan to update the docs before the next release.

@eliaskosunen
Copy link
Contributor Author

As of now, ranges.h requires C++14 for its use of generic lambdas. This is breaking the builds using C++11. There should probably be a way to exclude range tests during build configuration or to fix ranges.h to only use C++11 features.

@vitaut
Copy link
Contributor

vitaut commented May 17, 2018

As of now, ranges.h requires C++14 for its use of generic lambdas.

We can temporarily exclude ranges-test.cc from the build until C++11 compatibility is fixed.

@ukreator
Copy link

Is gcc 4.4 support really necessary for 5.0? It's 9 years old already

@eliaskosunen
Copy link
Contributor Author

To me it seems like this would be ready for merging. Are you still concerned of the disabled warnings?

@vitaut
Copy link
Contributor

vitaut commented May 19, 2018

Is gcc 4.4 support really necessary for 5.0? It's 9 years old already

I think gcc 4.4 achieves a good balance between being old enough to be available even on legacy systems, but new enough to provide most important C++11 features that we need.

Are you still concerned of the disabled warnings?

Yes. I'm happy to merge the CI improvements, but IMHO explicitly disabling warnings in the code adds too much noise for little value since warnings not included in -Wall often give too many false positives. Could you remove additional diagnostic #pragmas from the code and corresponding switches that trigger them from CMake? I'm open to discussing enabling specific warnings, but not wholesale and better in separate PRs.

@vitaut
Copy link
Contributor

vitaut commented May 20, 2018

Compilation on gcc 4.4 should be fixed now.

Fix C++ standard setting in CI
template <size_t... Is, class Tuple, class F>
void for_each(std::index_sequence<Is...>, Tuple &&tup, F &&f) noexcept {
// Check for integer_sequence
#if defined(__cpp_lib_integer_sequence) || FMT_MSC_VER >= 1910
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why 1910 for MSVC? cppreference lists that it should be in VS2015, which is 1900. https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros

Copy link
Contributor

@vitaut vitaut left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, but there are some errors on Travis and a few small comments.

appveyor.yml Outdated
@@ -0,0 +1 @@
support/appveyor.yml
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is necessary. appveyor.yml is intentionally placed in support to reduce clutter in the top-level directory.

.travis.yml Outdated
- env: BUILD=Doc
sudo: required
# g++ 6 on Linux with C++14
- env: CXX_COMPILER=g++-6 BUILD=Debug STANDARD=14
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not use CXX instead of CXX_COMPILER and simplify before_script?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Travis exports CXX as g++ in between of matrix and before_script, so the value set in matrix would be lost.


static FMT_CONSTEXPR std::size_t size() {
return sizeof...(N);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use 2-space indent for consistency (https://github.com/fmtlib/fmt/blob/master/CONTRIBUTING.rst).

if platform == 'x64':
generator += ' Win64'
cmake_command.append('-G' + generator)
# build_command = ['msbuild', r'C:\projects\fmt\build\fmt.sln', '/m:4',
# r'/logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"']
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove.

build_command = ['cmake', '--build', '.', '--config', config, '--', '/m:4']
test_command = ['ctest', '-C', config]
test_command = ['ctest', '-C', config, '-T', 'Test']
with open('DartConfiguration.tcl', 'w+') as file:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is it for?

$file = $(ls Testing\*\Test.xml) | Select -first 1
$XSLInputElement.Transform((Resolve-Path $file), (Join-Path (Resolve-Path .) "ctest-to-junit-results.xml"))
$wc = New-Object 'System.Net.WebClient'
$wc.UploadFile("https://ci.appveyor.com/api/testresults/junit/$jobid", (Resolve-Path .\ctest-to-junit-results.xml))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this file a debugging artefact? Does it need to be in the PR?

@eliaskosunen
Copy link
Contributor Author

eliaskosunen commented Jun 5, 2018

Sorry for taking so long with this. I was busy with my finals, but now that my summer vacation has begun, I was able to take another look at this.

Builds are now succeeding, except for VS 2013 and g++ 4.4. I feel like this would now finally be ready for merging.

Re-enable ranges-test
Fix a Visual Studio error about function not returning a value in printf.h
Fix a bug in .travis.yml
@vitaut vitaut merged commit 691a7a9 into fmtlib:master Jun 6, 2018
@vitaut
Copy link
Contributor

vitaut commented Jun 6, 2018

Merged with minor tweaks, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants