Re: [VOTE] 2.8.0 release candidate 1

2017-01-09 Thread John Russell
> On Jan 9, 2017, at 4:44 PM, Jim Apple wrote: > >> A procedural question. I would recommend getting the documentation changes >> from gerrits # 5644, 5646, and 5649 into the 2.8 release. That will give us >> some solidity w.r.t. the Impala + Kudu changes and other new features. What >> ar

Upcoming RPC changes - sequencing of patches

2017-01-09 Thread Henry Robinson
Hi - I've been making a lot of good progress on IMPALA-2567 - replacing our Thrift RPC stack with one based on Apache Kudu's. You can see the progress I'm making on my personal branch here: http://github.com/HenryR/Impala/tree/krpc It's time to start merging some of these changes to master, to p

Re: [VOTE] 2.8.0 release candidate 1

2017-01-09 Thread Jim Apple
> A procedural question. I would recommend getting the documentation changes > from gerrits # 5644, 5646, and 5649 into the 2.8 release. That will give us > some solidity w.r.t. the Impala + Kudu changes and other new features. What > are the prospects for that if it takes, say, to the end of

Re: [VOTE] 2.8.0 release candidate 1

2017-01-09 Thread John Russell
A procedural question. I would recommend getting the documentation changes from gerrits # 5644, 5646, and 5649 into the 2.8 release. That will give us some solidity w.r.t. the Impala + Kudu changes and other new features. What are the prospects for that if it takes, say, to the end of the wee

Re: [VOTE] 2.8.0 release candidate 1

2017-01-09 Thread Tim Armstrong
+1 (binding) I was able to follow the steps, build the artifacts on my machine and run some queries. The RAT and other checks also looked good. I ran the full core tests, which passed. On Mon, Jan 9, 2017 at 11:34 AM, Jim Apple wrote: > I have improved >

Re: [VOTE] 2.8.0 release candidate 1

2017-01-09 Thread Jim Apple
I have improved with a more comprehensive script showing the steps to download and check some basic facts about a release. Additionally, I have created an experimental Jenki

Re: Preferred syntax for warning about ignored Status returns

2017-01-09 Thread Zachary Amsden
Yes Jim, exactly. I also sent the wrong link at least once, but this was my point. In the absence of compiler support I think it is actually possible to implement this anyway using syntax 1 but that is left as an exercise to the reader. On Mon, Jan 9, 2017 at 10:20 AM, Jim Apple wrote: > Thoug

Re: Preferred syntax for warning about ignored Status returns

2017-01-09 Thread Jim Apple
Though the attribute is "on" the definition, it can't appear in that location (after parameters, before curly braces). I don't know why. I think I now understand what you were saying above: if we use WARN_UNUSED_RESULT, then it can go after the function for functions with prototypes but must go ea

Re: Preferred syntax for warning about ignored Status returns

2017-01-09 Thread Tim Armstrong
Zach - looks like you're right, GCC seems to allow the second syntax only on function forward declarations, not definitions. On Mon, Jan 9, 2017 at 10:11 AM, Zachary Amsden wrote: > Maybe I'm just being dense but I couldn't get it to work with syntax 2 on a > function definition without having a

Re: Preferred syntax for warning about ignored Status returns

2017-01-09 Thread Zachary Amsden
Maybe I'm just being dense but I couldn't get it to work with syntax 2 on a function definition without having a separate forward declaration: https://godbolt.org/g/ODtoQC vs. https://godbolt.org/g/WCxDZv (non-functional) - Zach On Mon, Jan 9, 2017 at 10:00 AM, Jim Apple wrote: > That's appl

Re: Preferred syntax for warning about ignored Status returns

2017-01-09 Thread Jim Apple
That's applying it to the type definition. At the type use: https://godbolt.org/g/RMYVW7 On Mon, Jan 9, 2017 at 9:56 AM, Zachary Amsden wrote: > GCC doesn't catch this when optimization is enabled and the result is > discarded: > > https://godbolt.org/g/4b0BQC > > I think that means a type wrapp

Re: Preferred syntax for warning about ignored Status returns

2017-01-09 Thread Zachary Amsden
GCC doesn't catch this when optimization is enabled and the result is discarded: https://godbolt.org/g/4b0BQC I think that means a type wrapper approach is needed, which probably necessitates option 1. - Zach On Mon, Jan 9, 2017 at 9:17 AM, Jim Apple wrote: > My vote, as I mentioned on the p

Re: Preferred syntax for warning about ignored Status returns

2017-01-09 Thread Jim Apple
My vote, as I mentioned on the patch, is option 1. I see MUST_USE(T) as a property of T, like const T or volatile T. I think it is dual to move semantics or to Rust's ability to temporarily or permanently consume values so that /only/ one copy is in use rather than MUST_USE's /at least one/. https