[cmake-developers] [PATCH v5 0/4] Add continue keyword

[Ben Boeckel]

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