Recent Posts

Pages: 1 ... 8 9 [10]
91
General Discussion / Re: C2x
« Last post by bas on November 30, 2018, 11:58:49 AM »
I always find it funny that most language seem to do well without all these big formal specification documents.

If you have concrete proposals, just make them, but there is enough work already to make this a priority..
92
Implementation Details / Re: LLVM/C gen
« Last post by bas on November 30, 2018, 11:56:07 AM »
It seems like a good idea, but I haven't really focused on that part yet. What do you think?
93
Implementation Details / Re: Code formatting of C2's c++
« Last post by bas on November 30, 2018, 11:49:42 AM »
You can't protect against stupidity  ;).
If people want to write that code, let them, but don't burden good/normal developers by those restrictions..
94
Implementation Details / Re: Suppress warnings
« Last post by bas on November 30, 2018, 11:48:15 AM »
Yes, but i would want to avoid all the nitty-gritty Warning level tweaking that's part of C/C++. Only unused decls maybe and maybe maybe
some implicit conversions. Otherwise just be strict and generate errors. If you inherit a piece of code, disabling some warnings is okey.

What I'm thinking of is whether these adjustments should be make in code or in the recipe file. I think the recipe file might be better
suited for file-based adjustments.
95
General Discussion / Re: Overwriting fields in init struct.
« Last post by lerno on November 29, 2018, 02:45:24 PM »
/Init/init_field_designator_duplicate.c2
96
General Discussion / Re: C2x
« Last post by lerno 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
97
Implementation Details / Re: LLVM/C gen
« Last post by lerno 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;
  }
}
98
Implementation Details / Re: Code formatting of C2's c++
« Last post by lerno 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. :D 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.
99
Implementation Details / Re: Suppress warnings
« Last post by lerno on November 29, 2018, 02:13:23 PM »
Something like @(nocheck=unused_variable | implicit_conversion)?
100
Ideas / Re: Switch proposal
« Last post by lerno 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)
Pages: 1 ... 8 9 [10]