alarsyo/spot
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

attempt to fix clang++ compilation error

Browse source 
Seen on arch linux when clang++ 3.7.1 uses GCC's 6.1.1 tuple header.

* spot/twaalgos/ltl2tgba_fm.cc (ratexp_to_dfa::succ): Build the return
type explicitly.
* NEWS: Mention the issue.
This commit is contained in:
Alexandre Duret-Lutz 2016-05-09 22:01:57 +02:00
parent 694e485ec2
commit 0278735ebe
2 changed files with 14 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

4
NEWS
View file

@ -60,6 +60,10 @@ New in spot 2.0.1a (not yet released)
So "{:[i]s}".format(f) is the same as
"{:s}".format(f.unabbreviate("i")).
Bug fixes:
* Fix compilation error observed with Clang++ 3.7.1 and GCC 6.1.1
headers.
New in spot 2.0.1 (2016-05-09)

12
spot/twaalgos/ltl2tgba_fm.cc
View file

@ -1047,14 +1047,22 @@ namespace spot
else
a = translate(f);
// Using return std::make_tuple(nullptr, nullptr, nullptr) works
// with GCC 6.1.1, but breaks with clang++ 3.7.1 when using the
// same header file for <tuple>. So let's use the output type
// explicitly.
typedef std::tuple<const_twa_graph_ptr,
const ratexp_to_dfa::namer*,
const state*> res_t;
// If a is null, f has an empty language.
if (!a.first)
return std::forward_as_tuple(nullptr, nullptr, nullptr);
return res_t{nullptr, nullptr, nullptr};
auto namer = a.second;
assert(namer->has_state(f));
auto st = a.first->state_from_number(namer->get_state(f));
return std::forward_as_tuple(a.first, namer, st);
return res_t{a.first, namer, st};
}
// The rewrite rules used here are adapted from Jean-Michel