On Tue, Nov 18, 2014 at 18:06:30 +0100, Gregor Jasny wrote:
> On 18/11/14 17:19, Ben Boeckel wrote:
> > I wonder if we should
> > fix anything about it and if so, make continue behave in an analogous
> > way
>
> You want to make continue() bug compatible to break()?
There are two parts here:
1) is there something wrong with the break() example (looking closer
at CMP0055 shows that, yes, there is)?
2) if so, do we make continue() act like it before or while fixing
break()?
My concern is that with CMP0055 as-is, there is a case where continue()
works as break() *should* but break() is set to an OLD policy and now
they can have completely different semantics. If we decide that the
example *does* show a problem, I'd like *one* policy for continue() and
break() at the same time. Maybe it's not an issue because continue() is
a completely new command and already basically moves you up to requiring
3.2 anyways in which case the mix-and-match behavior is only a problem
with an explicit-OLD policy setting.
> So the break in the macro worked, the break in the function got ignored.
> This is expected behavior. The macro currently does not form an own
> scope. Also variables set inside escape into the calling scope.
>
> The function forms an own scope (due to the Push/PopScope call).
>
> I think it is sane behavior that a macro does not form a scope / loop
> context behavior. Or do you read macro like "macro function"?
I guess I should have been more clear: the behavior exhibited is what I
expected given my experience with macros and functions. It's more of a
"do we fix it?".
> > without any error messages (e.g., about using break() outside a
>
> This is because CMP0055 defaults to OLD here. If you add
> "cmake_policy(SET CMP0055 NEW)" here you'll get a nice error.
I think that this and the argument rule should be separate policies
(removing arguments is easy; refactoring out a now-unallowed behavior
might be harder depending on how deep down a macro calls break()).
> > loop…which doesn't seem to happen anyways, so maybe this is moot). I
> > don't see any existing tests about break inside of a function or macro
> > having an effect on the caller's logic.
>
> What do you mean with 'effect' here?
Calling a macro mutates your control flow (e.g., calling return()) in
ways functions can't (and there's no distinction between macros and
functions at the callsite).
--Ben
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
