-
Notifications
You must be signed in to change notification settings - Fork 273
goto-cc: also use the linker when processing multiple source files [blocks: #4056] #4297
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.
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
Conversation
57af742
to
d8b4679
Compare
8b3cc17
to
45f4223
Compare
Codecov Report
@@ Coverage Diff @@
## develop #4297 +/- ##
========================================
Coverage 69.45% 69.46%
========================================
Files 1243 1243
Lines 100620 100626 +6
========================================
+ Hits 69887 69895 +8
+ Misses 30733 30731 -2
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems reasonable but I am a little concerned that there aren't any tests for this. Is there any user-visible change of this PR?
There shouldn't be user-visible changes, actually. Testing exists ( |
@tautschnig OK; thanks. |
7ebc1de
to
7f74490
Compare
There is no need to access the goto model stored in compilet as we read the goto binary that compilet wrote anyway. This avoids tight coupling and enables removing public class members from compilet.
The linker is able to do some type sanitisation across translation units, and there is no reason behaviour should be different whether we link previously compiled object files or a set of source files.
7f74490
to
adaefcf
Compare
The linker is able to do some type sanitisation across translation units, and
there is no reason behaviour should be different whether we link previously
compiled object files or a set of source files.