Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

test serialization/deserialization of clang IR with new checked types and new bounds expressions #3

Closed
dtarditi opened this issue Jun 21, 2016 · 0 comments · Fixed by #101
Closed

test serialization/deserialization of clang IR with new checked types and new bounds expressions #3

dtarditi opened this issue Jun 21, 2016 · 0 comments · Fixed by #101
Assignees
@lenary @dtarditi

Comments

@dtarditi
Copy link
Contributor

dtarditi commented Jun 21, 2016 •
edited

We added code for serializing and deserializing clang IR with the new checked types. This is necessary to get the code to compile. However, the serialization and deserialization of IR with these types has no tests. We should add tests before people start using compiler functionality that depends on this.
@dtarditi dtarditi self-assigned this Jun 21, 2016
@dtarditi dtarditi changed the title serialization/deserialization of clang IR with new checked types is untested test serialization/deserialization of clang IR with new checked types and new bounds expressions Jun 28, 2016
@dtarditi dtarditi mentioned this issue Jun 28, 2016
Merged
dtarditi added a commit that referenced this issue Jun 30, 2016
@dtarditi
Extend clang IR with bounds expressions and parse bounds expressions …
6d4d831 
…for parameters. (#8)

This change extends the clang IR to represent Checked C bounds expressions and optional bounds expressions for variable declarations. It also adds support for parsing bounds expressions and modifies parsing of function parameter lists to parse optional bounds expressions.

Bounds expressions are represented in the IR by adding a new abstract class BoundsExpr and subclassing it for count bounds expressions (count(e1) and byte_count(e1)), range bounds expressions (bounds(e1, e2)), and nullary bounds expressions(bounds(none)). AST printing, serialization, traversal, and tree transformations are extended handle the new expressions.

Bounds expressions are attached to variable declarations by adding an additional member to VarDecls. Many VarDecls will not have bounds expressions, so this adds extra space overhead to the representation of VarDecls. We can revisit this later if it becomes an issue.

To test the new bounds expressions, we add parsing of bounds expressions for function parameter lists and attach the parsed bounds expressions to the VarDecls for the parameters.

Bounds expressions for parameters need to be processed in a scope with all the parameters available. They are currently being processed in a scope that contains the parameters seen so far. This is a little complicated to implement in clang. You have to delay parsing of the bounds expressions. I will come back to this after getting basic parsing of bounds expressions working. I've opened issue #7 to track this.

Testing:
•This passes the current test baseline for this snapshot of clang:
•Wrote new feature tests of parsing of parameters with bounds declarations. There will be a separate pull request to the Github CheckedC repo for these tests.
•Passes the existing Checked C tests.
  Expected Passes    : 8942
  Expected Failures  : 21
  Unsupported Tests  : 206
  Unexpected Failures: 3

•We still need to test AST printing, serialization, traversal, and tree transformations. I've opened issues #4 , #3, #5, and #6 to track this.
@lenary lenary self-assigned this Jan 10, 2017
@lenary lenary mentioned this issue Jan 11, 2017
Merged
@lenary lenary mentioned this issue Jan 12, 2017
Merged
lenary added a commit that referenced this issue Jan 12, 2017
@lenary
Add AST Serialization/Deserialization Tests (#102)
ee83760 
This is making sure that we don't break pre-compiled headers at any point.

Not only do we include new PCH tests, but in order to get them to pass, I had to fix the following bugs:

- One of the initializers of PositionalParameterExpr (specifically the Empty one) had a copy/paste bug, which meant it was initializing the wrong kind of expression.
- We were not writing the sub-expressions within bounds expressions correctly. Now they are written in the same way that the visitor writes other sub-expressions of other expression types.
- We were not saving the "type as written" information for the InteropTypeBoundsAnnotationExpr, which meant that we couldn't deserialize it. It is now saved and re-read correctly.

The test compiles a header and source file together, then tests compiling the header separately into a PCH, and then compiling the source file using the PCH. They should have the same set of errors. We use `-verify` and diagnostic annotations as tests. Currently we ignore diagnostic notes, as there seems to be an issue with putting expectations in the header to be compiled into the PCH.

Currently most of the tests are testing that everything works, rather than testing that certain things fail. This could be improved later.

Closes #3
dtarditi pushed a commit that referenced this issue Jun 20, 2017
@zygoloid
[c++1z] Synthesize implicit deduction guides from constructors on dem…
5b38d71 
…and. Rank

such guides below explicit ones, and ensure that references to the class's
template parameters are not treated as forwarding references.

We make a few tweaks to the wording in the current standard:
1) The constructor parameter list is copied faithfully to the deduction guide,
   without losing default arguments or a varargs ellipsis (which the standard
   wording loses by omission).
2) If the class template declares no constructors, we add a T() -> T<...> guide
   (which will only ever work if T has default arguments for all non-pack
   template parameters).
3) If the class template declares nothing that looks like a copy or move
   constructor, we add a T(T<...>) -> T<...> guide.
#2 and #3 follow from the "pretend we had a class type with these constructors"
philosophy for deduction guides.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295007 91177308-0d34-0410-b5e6-96231b3b80d8
@dtarditi dtarditi mentioned this issue Apr 26, 2018
Closed
@AnnaKornfeldSimpson AnnaKornfeldSimpson mentioned this issue Jul 13, 2018
Closed
kkjeer pushed a commit that referenced this issue Sep 23, 2020
@DimitryAndric @zmodem
Instantiate Error in Target::GetEntryPointAddress() only when necessary
6406b6f 
When `Target::GetEntryPointAddress()` calls `exe_module->GetObjectFile()->GetEntryPointAddress()`, and the returned
`entry_addr` is valid, it can immediately be returned.

However, just before that, an `llvm::Error` value has been setup, but in this case it is not consumed before returning, like is done further below in the function.

In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core:

```
* thread #1, name = 'testcase', stop reason = breakpoint 1.1
    frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5
   1	int main(int argc, char *argv[])
   2	{
-> 3	    return 0;
   4	}
(lldb) p argc
Program aborted due to an unhandled Error:
Error value was Success. (Note: Success values must still be checked prior to being destroyed).

Thread 1 received signal SIGABRT, Aborted.
thr_kill () at thr_kill.S:3
3	thr_kill.S: No such file or directory.
(gdb) bt
#0  thr_kill () at thr_kill.S:3
#1  0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#2  0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
#3  0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112
#4  0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267
#5  0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67
#6  0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114
#7  0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97
#8  0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604
#9  0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347
#10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383
#11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301
#12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331
#13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190
#14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372
#15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414
#16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646
#17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003
#18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762
#19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760
#20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548
#21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903
#22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946
#23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169
#24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675
#25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890```

Fix the incorrect error catch by only instantiating an `Error` object if it is necessary.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D86355

(cherry picked from commit 1ce07cd)
dopelsunce pushed a commit to dopelsunce/checkedc-clang that referenced this issue Sep 28, 2020
@dtarditi
Merge pull request microsoft#24 from dtarditi/issue3
bfcc843 
Fix lost highlighting of code and fix typos.

The addresses issue microsoft#3, where highlighting of text was lost when the Word document was converted to LaTex This adds back the missing highlighting to the LaTex document. This also fixes some typos.

The highlighting was used in code examples. The code examples used the verbatim environment. To be able to highlight the code, we need to be able to use LaTex commands, which are not allowed by the verbatim environment. Switching to the alltt environment does not work because the LaTex highlighting package that we are using does not work well with alltt. The solution is to just switch to teletype font and handle line breaking and spacing manually where necessary. This works well with the highlighting package.
@sulekhark sulekhark mentioned this issue Apr 13, 2021
Closed
@secure-sw-dev-bot secure-sw-dev-bot mentioned this issue Jan 16, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lenary lenary

@dtarditi dtarditi

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Adds deserialization of Positional Parameter Expressions lenary/checkedc-clang
2 participants
@lenary @dtarditi