Messages

46

Implementation Details / CTC (partial, full, none)

« on: December 01, 2018, 05:34:50 PM »

I'd like some clarification on how this one works and what the expectation is for each state.

47

Ideas / Typeinfo at runtime

« on: December 01, 2018, 10:59:10 AM »

I want to suggest that type info should be available at runtime. There are various way to implement this. In the end, the type should only be reduced to a number that’s used to access a generated a set of functions that are built during code generation.

To do this we need to introduce another built in type, ”vtype”.

Code: [Select]

vtype x = typeof(a);
bool y = is_struct(x);

What’s interesting here is for scripting and very dynamic plugins.
A function may take a void* plus the vtype and work on the data as if it was the given type, even though the code was built BEFORE the type was written.

The most general use for this is to dump structure data for debugging.
The macro can then be something like:

Code: [Select]

#define DUMP(x) dump_data(typeof(x), (void*)&x)

(Very rough, but hopefully you see what I mean)

dump_data here is a FUNCTION not a macro.

This is just a discussion starter. Add to the idea!

48

Ideas / Re: Switch proposal

« on: November 30, 2018, 06:39:23 PM »

Err... My proposal was to add implicit break.

49

General Discussion / Re: Overwriting fields in init struct.

« on: November 30, 2018, 06:37:46 PM »

Motivation why it should be allowed is in the first post...

50

Implementation Details / Re: Suppress warnings

« on: November 30, 2018, 06:36:53 PM »

For file maybe. I find that I mostly will turn of statement based warnings. It's when I run into a piece of code I know will be safe, but that the compiler think might be unsafe. In java that's usually casting between generics. For Objective-C, using dynamic calls where the compiler can't see the definition, etc. Things that you want to avoid 90% of the cases.

51

Implementation Details / Re: Code formatting of C2's c++

« on: November 30, 2018, 06:33:38 PM »

Oh, it's not about stupidity, it's about grammar ambiguity.

52

Implementation Details / Re: LLVM/C gen

« on: November 30, 2018, 06:32:45 PM »

I don't know. I've looked at IR gen by other languages and it seems they don't have it. It might me that they are not yet heavily invested in debugging. I don't know.

53

General Discussion / Re: Overwriting fields in init struct.

« on: November 29, 2018, 02:45:24 PM »

/Init/init_field_designator_duplicate.c2

54

General Discussion / Re: C2x

« on: November 29, 2018, 02:43:59 PM »

All parts that will be added to C2x since this is part of the "official" evolution of C. If there has been enough need to include this in the next C revision, it should probably go into C2 as well.

For example: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2257.htm#dr_476

Also the ones not yet accepted, like: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2269.pdf

55

Implementation Details / Re: LLVM/C gen

« on: November 29, 2018, 02:38:19 PM »

From Clang:

Code: [Select]

void CodeGenFunction::EmitForStmt(const ForStmt &S,
                                  ArrayRef<const Attr *> ForAttrs) {
  JumpDest LoopExit = getJumpDestInCurrentScope("for.end");

  LexicalScope ForScope(*this, S.getSourceRange());

  // Evaluate the first part before the loop.
  if (S.getInit())
    EmitStmt(S.getInit());

  // Start the loop with a block that tests the condition.
  // If there's an increment, the continue scope will be overwritten
  // later.
  JumpDest Continue = getJumpDestInCurrentScope("for.cond");
  llvm::BasicBlock *CondBlock = Continue.getBlock();
  EmitBlock(CondBlock);

  const SourceRange &R = S.getSourceRange();
  LoopStack.push(CondBlock, CGM.getContext(), ForAttrs,
                 SourceLocToDebugLoc(R.getBegin()),
                 SourceLocToDebugLoc(R.getEnd()));

  // If the for loop doesn't have an increment we can just use the
  // condition as the continue block.  Otherwise we'll need to create
  // a block for it (in the current scope, i.e. in the scope of the
  // condition), and that we will become our continue block.
  if (S.getInc())
    Continue = getJumpDestInCurrentScope("for.inc");

  // Store the blocks to use for break and continue.
  BreakContinueStack.push_back(BreakContinue(LoopExit, Continue));

  // Create a cleanup scope for the condition variable cleanups.
  LexicalScope ConditionScope(*this, S.getSourceRange());

  if (S.getCond()) {
    // If the for statement has a condition scope, emit the local variable
    // declaration.
    if (S.getConditionVariable()) {
      EmitAutoVarDecl(*S.getConditionVariable());
    }

    llvm::BasicBlock *ExitBlock = LoopExit.getBlock();
    // If there are any cleanups between here and the loop-exit scope,
    // create a block to stage a loop exit along.
    if (ForScope.requiresCleanups())
      ExitBlock = createBasicBlock("for.cond.cleanup");

    // As long as the condition is true, iterate the loop.
    llvm::BasicBlock *ForBody = createBasicBlock("for.body");

    // C99 6.8.5p2/p4: The first substatement is executed if the expression
    // compares unequal to 0.  The condition must be a scalar type.
    llvm::Value *BoolCondVal = EvaluateExprAsBool(S.getCond());
    Builder.CreateCondBr(
        BoolCondVal, ForBody, ExitBlock,
        createProfileWeightsForLoop(S.getCond(), getProfileCount(S.getBody())));

    if (ExitBlock != LoopExit.getBlock()) {
      EmitBlock(ExitBlock);
      EmitBranchThroughCleanup(LoopExit);
    }

    EmitBlock(ForBody);
  } else {
    // Treat it as a non-zero constant.  Don't even create a new block for the
    // body, just fall into it.
  }
  incrementProfileCounter(&S);

  {
    // Create a separate cleanup scope for the body, in case it is not
    // a compound statement.
    RunCleanupsScope BodyScope(*this);
    EmitStmt(S.getBody());
  }

  // If there is an increment, emit it next.
  if (S.getInc()) {
    EmitBlock(Continue.getBlock());
    EmitStmt(S.getInc());
  }

  BreakContinueStack.pop_back();

  ConditionScope.ForceCleanup();

  EmitStopPoint(&S);
  EmitBranch(CondBlock);

  ForScope.ForceCleanup();

  LoopStack.pop();

  // Emit the fall-through block.
  EmitBlock(LoopExit.getBlock(), true);
}

Here, "EmitStopPoint" is the part that emits debug information. It's in more places as well.

Code: [Select]

void CodeGenFunction::EmitStopPoint(const Stmt *S) {
  if (CGDebugInfo *DI = getDebugInfo()) {
    SourceLocation Loc;
    Loc = S->getLocStart();
    DI->EmitLocation(Builder, Loc);

    LastStopPoint = Loc;
  }
}


56

Implementation Details / Re: Code formatting of C2's c++

« on: November 29, 2018, 02:30:08 PM »

I'm just in favour for making the dangling else unambiguous always. Code like

Code: [Select]

if (foo) if (bar) baz(); else foobar();


... should never ever be written. Requiring braces for if-else prevents ambiguous code.

Someone might write:

Code: [Select]

if (foo)
  if (bar) baz();
else
  foobar();


But what they get is:

Code: [Select]

if (foo)
  if (bar)
    baz();
  else
    foobar();


This is never ambiguous:

Code: [Select]

if (foo) {
  if (bar) baz();
} else {
  foobar();
}
// or
if (foo)
  if (bar) {
   baz();
  } else {
    foobar();
  }


if we allow if (foo) { ... } else ... / if (goo) ... else { ... } (that is, braces is needed for at least one part), then that would solve ambiguity as well.

We would be allowing if ( ... ) ...; so we're not locking down short ifs. Just preventing ambiguous if-else constructs.

57

Implementation Details / Re: Suppress warnings

« on: November 29, 2018, 02:13:23 PM »

Something like @(nocheck=unused_variable | implicit_conversion)?

58

Ideas / Re: Switch proposal

« on: November 29, 2018, 02:11:28 PM »

I think fallthrough automatically on empty is very inconsistent. Consider this, with impllcit break:

Code: [Select]

func void printTest(i32 foo) {
 switch (foo) {
   case 1:
     printf("A\n");
   case 2:
     printf("B\n");
   default:
     // Do nothing
  }
}
printTest(1);

Prints "A"

Now we decide to comment out printf("A\n");

Code: [Select]

func void printTest(i32 foo) {
 switch (foo) {
   case 1:
     // printf("A\n");
   case 2:
     printf("B\n");
   default:
     // Do nothing
  }
}
printTest(1);

Now this prints "B". Perhaps not what we expected... So I think case 1, is a better suggestion for empty fallthrough (version C)

59

Ideas / Re: Switch proposal

« on: November 28, 2018, 10:43:58 PM »

So, current options:

(A) case 3 | for empty fallthrough, explicit fallthrough when it is non empty.
(B) | case 3 to indicate the previous case was fallthrough, regardless whether it was empty or not.
(C) case 3, for empty fallthrough, explicit fallthrough when it is non empty.

Types of "fallthrough" keyword:

(a) fallthrough
(b) goto next
(c) goto case
(d) goto case 4
(e) continue case
(f) next
(g) nextcase

60

Ideas / Re: Switch proposal

« on: November 28, 2018, 10:36:50 PM »

Yet one more syntax:

Code: [Select]

switch (a) {
  case 1, // Comma to delimit multiple case. Can only be followed by another case
  case 2,
  case 3: // : means we have an explicit break.
    foo(); 
  case 4,
  case 5:
    bar();
    goto next; // Explicit fallthrough (could also be goto case, goto case 6 etc)
  case 6:
    baz();
}