Skip to content

/rust

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

Save metadata even with -Z no-trans (e.g. for multi-crate cargo check). #33602

Merged
merged 8 commits into from May 25, 2016

Conversation

Reviewers
No reviews
Assignees

@michaelwoerister michaelwoerister

Labels
None yet
Projects
None yet
Milestone
No milestone
6 participants
@eddyb @rust-highfive @michaelwoerister @bors @alexcrichton @jroesch
@eddyb
Copy link
Member

eddyb commented May 12, 2016 •
edited

Removes the item symbol map in metadata, as we can now generate them in a deterministic manner.
The -Z no-trans change lets the LLVM passes and linking run, but with just metadata and no code.
It fails while trying to link a binary because there's no main function, which is correct but not good UX.

There's also no way to easily throw away all of the artifacts to rebuild with actual code generation.
We might want cargo check to do that using cargo-internal information and then it would just work.

cc @alexcrichton @nikomatsakis @Aatch @michaelwoerister

@rust-highfive rust-highfive assigned jroesch May 12, 2016

@rust-highfive

This comment has been minimized.

Sign in to view
Copy link
Collaborator

rust-highfive commented May 12, 2016

r? @jroesch

(rust_highfive has picked a reviewer for you, use r? to override)

@michaelwoerister michaelwoerister assigned michaelwoerister and unassigned jroesch May 12, 2016

@michaelwoerister

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented May 12, 2016

I'm going to review this right now..
@michaelwoerister

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented May 12, 2016

@bors: r+

Perfect, @eddyb!
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented May 12, 2016

📌 Commit adee551 has been approved by michaelwoerister

@eddyb eddyb referenced this pull request May 13, 2016

Closed

Rollup of 29 pull requests #33610

bors added a commit that referenced this pull request May 13, 2016

@bors
Auto merge of #33610 - eddyb:rollup, r=eddyb 
Rollup of 29 pull requests

- Successful merges: #33342, #33393, #33450, #33491, #33508, #33513, #33517, #33531, #33532, #33533, #33534, #33538, #33541, #33544, #33552, #33553, #33555, #33560, #33563, #33565, #33566, #33572, #33576, #33580, #33590, #33593, #33596, #33598, #33600
- Failed merges: #33578, #33602
1db8651
@eddyb

This comment has been minimized.

Sign in to view
Copy link
Member Author

eddyb commented May 13, 2016

@bors r- Potentially relevant failure
@eddyb

This comment has been minimized.

Sign in to view
Copy link
Member Author

eddyb commented May 13, 2016

@bors r=michaelwoerister d'oh this PR wasn't even in the rollup 😫
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented May 13, 2016

📌 Commit adee551 has been approved by michaelwoerister

eddyb added a commit to eddyb/rust that referenced this pull request May 13, 2016

@eddyb
Rollup merge of rust-lang#33602 - eddyb:no-trans--check, r=michaelwoe… 
…rister

Save metadata even with -Z no-trans (e.g. for multi-crate cargo check).

Removes the item symbol map in metadata, as we can now generate them in a deterministic manner.
The `-Z no-trans` change lets the LLVM passes and linking run, but with just metadata and no code.
It fails while trying to link a binary because there's no `main` function, which is correct but not good UX.

There's also no way to easily throw away all of the artifacts to rebuild with actual code generation.
We might want `cargo check` to do that using cargo-internal information and then it would just work.

cc @alexcrichton @nikomatsakis @Aatch @michaelwoerister
96297ea

bors added a commit that referenced this pull request May 13, 2016

@bors
Auto merge of #33610 - eddyb:rollup, r=eddyb 
Rollup of 29 pull requests

- Successful merges: #33342, #33393, #33450, #33491, #33508, #33513, #33517, #33531, #33532, #33533, #33534, #33538, #33541, #33544, #33552, #33553, #33555, #33560, #33563, #33565, #33566, #33572, #33576, #33580, #33590, #33593, #33596, #33598, #33600
- Failed merges: #33578, #33602
a2831f7
@eddyb

This comment has been minimized.

Sign in to view
Copy link
Member Author

eddyb commented May 13, 2016

@bors rollup-

bors added a commit that referenced this pull request May 13, 2016

@bors
Auto merge of #33610 - eddyb:rollup, r=eddyb 
Rollup of 29 pull requests

- Successful merges: #33342, #33393, #33450, #33491, #33508, #33513, #33517, #33531, #33532, #33533, #33534, #33538, #33541, #33544, #33552, #33553, #33555, #33560, #33563, #33565, #33566, #33572, #33576, #33580, #33590, #33593, #33596, #33598, #33600
- Failed merges: #33578, #33602
244b73d
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented May 14, 2016

☔️ The latest upstream changes (presumably #33632) made this pull request unmergeable. Please resolve the merge conflicts.

@eddyb eddyb referenced this pull request May 14, 2016

Merged

rustc: Add a new crate type, cdylib #33553

@eddyb eddyb force-pushed the eddyb:no-trans--check branch from adee551 to 5087556 May 14, 2016

@eddyb

This comment has been minimized.

Sign in to view
Copy link
Member Author

eddyb commented May 14, 2016

@bors r=michaelwoerister
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented May 14, 2016

📌 Commit 5087556 has been approved by michaelwoerister
@eddyb

This comment has been minimized.

Sign in to view
Copy link
Member Author

eddyb commented May 14, 2016

Oh wait I didn't fix the failure in @alexcrichton's test.

@bors r-
@eddyb

This comment has been minimized.

Sign in to view
Copy link
Member Author

eddyb commented May 14, 2016

@bors r=michaelwoerister
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented May 14, 2016

📌 Commit d2ded31 has been approved by michaelwoerister

eddyb added a commit to eddyb/rust that referenced this pull request May 14, 2016

@eddyb
Rollup merge of rust-lang#33602 - eddyb:no-trans--check, r=michaelwoe… 
…rister

Save metadata even with -Z no-trans (e.g. for multi-crate cargo check).

Removes the item symbol map in metadata, as we can now generate them in a deterministic manner.
The `-Z no-trans` change lets the LLVM passes and linking run, but with just metadata and no code.
It fails while trying to link a binary because there's no `main` function, which is correct but not good UX.

There's also no way to easily throw away all of the artifacts to rebuild with actual code generation.
We might want `cargo check` to do that using cargo-internal information and then it would just work.

cc @alexcrichton @nikomatsakis @Aatch @michaelwoerister
7f812dd

@eddyb eddyb referenced this pull request May 14, 2016

Merged

Rollup of 27 pull requests #33643

bors added a commit that referenced this pull request May 14, 2016

@bors
Auto merge of #33643 - eddyb:rollup, r=eddyb 
Rollup of 27 pull requests

- Successful merges: #33342, #33393, #33415, #33475, #33517, #33533, #33534, #33565, #33580, #33584, #33585, #33588, #33590, #33591, #33593, #33598, #33600, #33602, #33603, #33604, #33605, #33607, #33612, #33620, #33633, #33634, #33635
- Failed merges: #33578
bef9056

bors added a commit that referenced this pull request May 14, 2016

@bors
Auto merge of #33643 - eddyb:rollup, r=eddyb 
Rollup of 27 pull requests

- Successful merges: #33342, #33393, #33415, #33475, #33517, #33533, #33534, #33565, #33580, #33584, #33585, #33588, #33590, #33591, #33593, #33598, #33600, #33602, #33603, #33604, #33605, #33607, #33612, #33620, #33633, #33634, #33635
- Failed merges: #33578
89f8e6a
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented May 15, 2016

⌛️ Testing commit d2ded31 with merge 33a8175...

bors added a commit that referenced this pull request May 15, 2016

@bors
Auto merge of #33602 - eddyb:no-trans--check, r=michaelwoerister 
Save metadata even with -Z no-trans (e.g. for multi-crate cargo check).

Removes the item symbol map in metadata, as we can now generate them in a deterministic manner.
The `-Z no-trans` change lets the LLVM passes and linking run, but with just metadata and no code.
It fails while trying to link a binary because there's no `main` function, which is correct but not good UX.

There's also no way to easily throw away all of the artifacts to rebuild with actual code generation.
We might want `cargo check` to do that using cargo-internal information and then it would just work.

cc @alexcrichton @nikomatsakis @Aatch @michaelwoerister
33a8175

bors added a commit that referenced this pull request May 25, 2016

@bors
Auto merge of #33602 - eddyb:no-trans--check, r=michaelwoerister 
Save metadata even with -Z no-trans (e.g. for multi-crate cargo check).

Removes the item symbol map in metadata, as we can now generate them in a deterministic manner.
The `-Z no-trans` change lets the LLVM passes and linking run, but with just metadata and no code.
It fails while trying to link a binary because there's no `main` function, which is correct but not good UX.

There's also no way to easily throw away all of the artifacts to rebuild with actual code generation.
We might want `cargo check` to do that using cargo-internal information and then it would just work.

cc @alexcrichton @nikomatsakis @Aatch @michaelwoerister
367be6c
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented May 25, 2016

💔 Test failed - auto-linux-64-opt-rustbuild

@eddyb eddyb force-pushed the eddyb:no-trans--check branch from 1bf0829 to a619901 May 25, 2016

@eddyb

This comment has been minimized.

Sign in to view
Copy link
Member Author

eddyb commented May 25, 2016

@bors r=michaelwoerister
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented May 25, 2016

📌 Commit a619901 has been approved by michaelwoerister
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented May 25, 2016

⌛️ Testing commit a619901 with merge 5229e0e...

bors added a commit that referenced this pull request May 25, 2016

@bors
Auto merge of #33602 - eddyb:no-trans--check, r=michaelwoerister 
Save metadata even with -Z no-trans (e.g. for multi-crate cargo check).

Removes the item symbol map in metadata, as we can now generate them in a deterministic manner.
The `-Z no-trans` change lets the LLVM passes and linking run, but with just metadata and no code.
It fails while trying to link a binary because there's no `main` function, which is correct but not good UX.

There's also no way to easily throw away all of the artifacts to rebuild with actual code generation.
We might want `cargo check` to do that using cargo-internal information and then it would just work.

cc @alexcrichton @nikomatsakis @Aatch @michaelwoerister
5229e0e

@bors bors referenced this pull request May 25, 2016

Closed

add more comprehensive tests for incr. comp. #33851

@bors

@bors bors merged commit a619901 into rust-lang:master May 25, 2016
2 checks passed

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@eddyb eddyb deleted the eddyb:no-trans--check branch May 25, 2016

@bors bors referenced this pull request May 25, 2016

Merged

Projection cache and better warnings for #32330 #33816

@michaelwoerister michaelwoerister referenced this pull request May 26, 2016

Merged

Drive trans from the output of the translation item collector #33890

@eddyb eddyb referenced this pull request Jun 4, 2016

Closed

many major compile-time perf regressions in jld-day15-parser #34042

bors added a commit that referenced this pull request Jun 9, 2016

@bors
Auto merge of #33890 - michaelwoerister:collector-driven-trans, r=nik… 
…omatsakis

Drive trans from the output of the translation item collector

This PR changes the way how translation works above the item level. Instead of walking the HIR and calling `trans_item()` on everything encountered (while instantiating monomorphizations on-demand), we now just process the list of translation items generated by the `trans::collector`. Using the collector has the benefit of being able to know the exact set of monomorphizations and symbols before actually running translation, something that is crucial for incremental compilation (but also has [other benefits](#33602)).

The collector has existed for quite a while now, but so far it's output was only used for running some auto-tests. With this PR it becomes the only source of truth about what gets translated.

One modification we had to make, compared to the initial approach, is that closures are not represented as their own `TransItems`. Doing so, while still supporting non-MIR-based translation, would have been prohibitively complex, and not worth the trouble since legacy-trans will disappear sooner or later. Once there is solely MIR-trans, it would be a good idea to make closures `TransItems` again.

This PR removes the most obvious functions and tables that are not needed anymore, but there's definitely still more cleanup possible later on (e.g. `monomorphize::monomorphic_fn()` does very little at this point). Since there are already more than 10 commits in here, doing this in a separate PR seems to be a better idea.

These changes definitely warrant a crater run.

Thanks @Aatch, for taking on one of the more tedious tasks during the dev-sprint!
Thanks @eddyb, for doing some nice refactorings to symbol name generation and making sure these landed so I could use them!

cc @rust-lang/compiler
cc @rust-lang/tools
52f8da2

bors added a commit that referenced this pull request Jun 9, 2016

@bors
Auto merge of #33890 - michaelwoerister:collector-driven-trans, r=nik… 
…omatsakis

Drive trans from the output of the translation item collector

This PR changes the way how translation works above the item level. Instead of walking the HIR and calling `trans_item()` on everything encountered (while instantiating monomorphizations on-demand), we now just process the list of translation items generated by the `trans::collector`. Using the collector has the benefit of being able to know the exact set of monomorphizations and symbols before actually running translation, something that is crucial for incremental compilation (but also has [other benefits](#33602)).

The collector has existed for quite a while now, but so far it's output was only used for running some auto-tests. With this PR it becomes the only source of truth about what gets translated.

One modification we had to make, compared to the initial approach, is that closures are not represented as their own `TransItems`. Doing so, while still supporting non-MIR-based translation, would have been prohibitively complex, and not worth the trouble since legacy-trans will disappear sooner or later. Once there is solely MIR-trans, it would be a good idea to make closures `TransItems` again.

This PR removes the most obvious functions and tables that are not needed anymore, but there's definitely still more cleanup possible later on (e.g. `monomorphize::monomorphic_fn()` does very little at this point). Since there are already more than 10 commits in here, doing this in a separate PR seems to be a better idea.

These changes definitely warrant a crater run.

Thanks @Aatch, for taking on one of the more tedious tasks during the dev-sprint!
Thanks @eddyb, for doing some nice refactorings to symbol name generation and making sure these landed so I could use them!

cc @rust-lang/compiler
cc @rust-lang/tools
67ebd68

bors added a commit that referenced this pull request Jun 9, 2016

@bors
Auto merge of #33890 - michaelwoerister:collector-driven-trans, r=nik… 
…omatsakis

Drive trans from the output of the translation item collector

This PR changes the way how translation works above the item level. Instead of walking the HIR and calling `trans_item()` on everything encountered (while instantiating monomorphizations on-demand), we now just process the list of translation items generated by the `trans::collector`. Using the collector has the benefit of being able to know the exact set of monomorphizations and symbols before actually running translation, something that is crucial for incremental compilation (but also has [other benefits](#33602)).

The collector has existed for quite a while now, but so far it's output was only used for running some auto-tests. With this PR it becomes the only source of truth about what gets translated.

One modification we had to make, compared to the initial approach, is that closures are not represented as their own `TransItems`. Doing so, while still supporting non-MIR-based translation, would have been prohibitively complex, and not worth the trouble since legacy-trans will disappear sooner or later. Once there is solely MIR-trans, it would be a good idea to make closures `TransItems` again.

This PR removes the most obvious functions and tables that are not needed anymore, but there's definitely still more cleanup possible later on (e.g. `monomorphize::monomorphic_fn()` does very little at this point). Since there are already more than 10 commits in here, doing this in a separate PR seems to be a better idea.

These changes definitely warrant a crater run.

Thanks @Aatch, for taking on one of the more tedious tasks during the dev-sprint!
Thanks @eddyb, for doing some nice refactorings to symbol name generation and making sure these landed so I could use them!

cc @rust-lang/compiler
cc @rust-lang/tools
da0b439

bors added a commit that referenced this pull request Jun 10, 2016

@bors
Auto merge of #33890 - michaelwoerister:collector-driven-trans, r=nik… 
…omatsakis

Drive trans from the output of the translation item collector

This PR changes the way how translation works above the item level. Instead of walking the HIR and calling `trans_item()` on everything encountered (while instantiating monomorphizations on-demand), we now just process the list of translation items generated by the `trans::collector`. Using the collector has the benefit of being able to know the exact set of monomorphizations and symbols before actually running translation, something that is crucial for incremental compilation (but also has [other benefits](#33602)).

The collector has existed for quite a while now, but so far it's output was only used for running some auto-tests. With this PR it becomes the only source of truth about what gets translated.

One modification we had to make, compared to the initial approach, is that closures are not represented as their own `TransItems`. Doing so, while still supporting non-MIR-based translation, would have been prohibitively complex, and not worth the trouble since legacy-trans will disappear sooner or later. Once there is solely MIR-trans, it would be a good idea to make closures `TransItems` again.

This PR removes the most obvious functions and tables that are not needed anymore, but there's definitely still more cleanup possible later on (e.g. `monomorphize::monomorphic_fn()` does very little at this point). Since there are already more than 10 commits in here, doing this in a separate PR seems to be a better idea.

These changes definitely warrant a crater run.

Thanks @Aatch, for taking on one of the more tedious tasks during the dev-sprint!
Thanks @eddyb, for doing some nice refactorings to symbol name generation and making sure these landed so I could use them!

cc @rust-lang/compiler
cc @rust-lang/tools
7cfa782

bors added a commit that referenced this pull request Jun 20, 2016

@bors
Auto merge of #33890 - michaelwoerister:collector-driven-trans, r=eddyb 
Drive trans from the output of the translation item collector

This PR changes the way how translation works above the item level. Instead of walking the HIR and calling `trans_item()` on everything encountered (while instantiating monomorphizations on-demand), we now just process the list of translation items generated by the `trans::collector`. Using the collector has the benefit of being able to know the exact set of monomorphizations and symbols before actually running translation, something that is crucial for incremental compilation (but also has [other benefits](#33602)).

The collector has existed for quite a while now, but so far it's output was only used for running some auto-tests. With this PR it becomes the only source of truth about what gets translated.

One modification we had to make, compared to the initial approach, is that closures are not represented as their own `TransItems`. Doing so, while still supporting non-MIR-based translation, would have been prohibitively complex, and not worth the trouble since legacy-trans will disappear sooner or later. Once there is solely MIR-trans, it would be a good idea to make closures `TransItems` again.

This PR removes the most obvious functions and tables that are not needed anymore, but there's definitely still more cleanup possible later on (e.g. `monomorphize::monomorphic_fn()` does very little at this point). Since there are already more than 10 commits in here, doing this in a separate PR seems to be a better idea.

These changes definitely warrant a crater run.

Thanks @Aatch, for taking on one of the more tedious tasks during the dev-sprint!
Thanks @eddyb, for doing some nice refactorings to symbol name generation and making sure these landed so I could use them!

cc @rust-lang/compiler
cc @rust-lang/tools
8cd2f01

bors added a commit that referenced this pull request Jun 22, 2016

@bors
Auto merge of #33890 - michaelwoerister:collector-driven-trans, r=mic… 
…haelwoerister

Drive trans from the output of the translation item collector

This PR changes the way how translation works above the item level. Instead of walking the HIR and calling `trans_item()` on everything encountered (while instantiating monomorphizations on-demand), we now just process the list of translation items generated by the `trans::collector`. Using the collector has the benefit of being able to know the exact set of monomorphizations and symbols before actually running translation, something that is crucial for incremental compilation (but also has [other benefits](#33602)).

The collector has existed for quite a while now, but so far it's output was only used for running some auto-tests. With this PR it becomes the only source of truth about what gets translated.

One modification we had to make, compared to the initial approach, is that closures are not represented as their own `TransItems`. Doing so, while still supporting non-MIR-based translation, would have been prohibitively complex, and not worth the trouble since legacy-trans will disappear sooner or later. Once there is solely MIR-trans, it would be a good idea to make closures `TransItems` again.

This PR removes the most obvious functions and tables that are not needed anymore, but there's definitely still more cleanup possible later on (e.g. `monomorphize::monomorphic_fn()` does very little at this point). Since there are already more than 10 commits in here, doing this in a separate PR seems to be a better idea.

These changes definitely warrant a crater run.

Thanks @Aatch, for taking on one of the more tedious tasks during the dev-sprint!
Thanks @eddyb, for doing some nice refactorings to symbol name generation and making sure these landed so I could use them!

cc @rust-lang/compiler
cc @rust-lang/tools
2a15e96

bors added a commit that referenced this pull request Jun 22, 2016

@bors
Auto merge of #33890 - michaelwoerister:collector-driven-trans, r=mic… 
…haelwoerister

Drive trans from the output of the translation item collector

This PR changes the way how translation works above the item level. Instead of walking the HIR and calling `trans_item()` on everything encountered (while instantiating monomorphizations on-demand), we now just process the list of translation items generated by the `trans::collector`. Using the collector has the benefit of being able to know the exact set of monomorphizations and symbols before actually running translation, something that is crucial for incremental compilation (but also has [other benefits](#33602)).

The collector has existed for quite a while now, but so far it's output was only used for running some auto-tests. With this PR it becomes the only source of truth about what gets translated.

One modification we had to make, compared to the initial approach, is that closures are not represented as their own `TransItems`. Doing so, while still supporting non-MIR-based translation, would have been prohibitively complex, and not worth the trouble since legacy-trans will disappear sooner or later. Once there is solely MIR-trans, it would be a good idea to make closures `TransItems` again.

This PR removes the most obvious functions and tables that are not needed anymore, but there's definitely still more cleanup possible later on (e.g. `monomorphize::monomorphic_fn()` does very little at this point). Since there are already more than 10 commits in here, doing this in a separate PR seems to be a better idea.

These changes definitely warrant a crater run.

Thanks @Aatch, for taking on one of the more tedious tasks during the dev-sprint!
Thanks @eddyb, for doing some nice refactorings to symbol name generation and making sure these landed so I could use them!

cc @rust-lang/compiler
cc @rust-lang/tools
05b1b3e

bors added a commit that referenced this pull request Jun 23, 2016

@bors
Auto merge of #33890 - michaelwoerister:collector-driven-trans, r=eddyb 
Drive trans from the output of the translation item collector

This PR changes the way how translation works above the item level. Instead of walking the HIR and calling `trans_item()` on everything encountered (while instantiating monomorphizations on-demand), we now just process the list of translation items generated by the `trans::collector`. Using the collector has the benefit of being able to know the exact set of monomorphizations and symbols before actually running translation, something that is crucial for incremental compilation (but also has [other benefits](#33602)).

The collector has existed for quite a while now, but so far it's output was only used for running some auto-tests. With this PR it becomes the only source of truth about what gets translated.

One modification we had to make, compared to the initial approach, is that closures are not represented as their own `TransItems`. Doing so, while still supporting non-MIR-based translation, would have been prohibitively complex, and not worth the trouble since legacy-trans will disappear sooner or later. Once there is solely MIR-trans, it would be a good idea to make closures `TransItems` again.

This PR removes the most obvious functions and tables that are not needed anymore, but there's definitely still more cleanup possible later on (e.g. `monomorphize::monomorphic_fn()` does very little at this point). Since there are already more than 10 commits in here, doing this in a separate PR seems to be a better idea.

These changes definitely warrant a crater run.

Thanks @Aatch, for taking on one of the more tedious tasks during the dev-sprint!
Thanks @eddyb, for doing some nice refactorings to symbol name generation and making sure these landed so I could use them!

cc @rust-lang/compiler
cc @rust-lang/tools
0f0a19d

bors added a commit that referenced this pull request Jun 23, 2016

@bors
Auto merge of #33890 - michaelwoerister:collector-driven-trans, r=eddyb 
Drive trans from the output of the translation item collector

This PR changes the way how translation works above the item level. Instead of walking the HIR and calling `trans_item()` on everything encountered (while instantiating monomorphizations on-demand), we now just process the list of translation items generated by the `trans::collector`. Using the collector has the benefit of being able to know the exact set of monomorphizations and symbols before actually running translation, something that is crucial for incremental compilation (but also has [other benefits](#33602)).

The collector has existed for quite a while now, but so far it's output was only used for running some auto-tests. With this PR it becomes the only source of truth about what gets translated.

One modification we had to make, compared to the initial approach, is that closures are not represented as their own `TransItems`. Doing so, while still supporting non-MIR-based translation, would have been prohibitively complex, and not worth the trouble since legacy-trans will disappear sooner or later. Once there is solely MIR-trans, it would be a good idea to make closures `TransItems` again.

This PR removes the most obvious functions and tables that are not needed anymore, but there's definitely still more cleanup possible later on (e.g. `monomorphize::monomorphic_fn()` does very little at this point). Since there are already more than 10 commits in here, doing this in a separate PR seems to be a better idea.

These changes definitely warrant a crater run.

Thanks @Aatch, for taking on one of the more tedious tasks during the dev-sprint!
Thanks @eddyb, for doing some nice refactorings to symbol name generation and making sure these landed so I could use them!

cc @rust-lang/compiler
cc @rust-lang/tools
f099891

bors added a commit that referenced this pull request Jun 23, 2016

@bors
Auto merge of #33890 - michaelwoerister:collector-driven-trans, r=eddyb 
Drive trans from the output of the translation item collector

This PR changes the way how translation works above the item level. Instead of walking the HIR and calling `trans_item()` on everything encountered (while instantiating monomorphizations on-demand), we now just process the list of translation items generated by the `trans::collector`. Using the collector has the benefit of being able to know the exact set of monomorphizations and symbols before actually running translation, something that is crucial for incremental compilation (but also has [other benefits](#33602)).

The collector has existed for quite a while now, but so far it's output was only used for running some auto-tests. With this PR it becomes the only source of truth about what gets translated.

One modification we had to make, compared to the initial approach, is that closures are not represented as their own `TransItems`. Doing so, while still supporting non-MIR-based translation, would have been prohibitively complex, and not worth the trouble since legacy-trans will disappear sooner or later. Once there is solely MIR-trans, it would be a good idea to make closures `TransItems` again.

This PR removes the most obvious functions and tables that are not needed anymore, but there's definitely still more cleanup possible later on (e.g. `monomorphize::monomorphic_fn()` does very little at this point). Since there are already more than 10 commits in here, doing this in a separate PR seems to be a better idea.

These changes definitely warrant a crater run.

Thanks @Aatch, for taking on one of the more tedious tasks during the dev-sprint!
Thanks @eddyb, for doing some nice refactorings to symbol name generation and making sure these landed so I could use them!

cc @rust-lang/compiler
cc @rust-lang/tools
3bd325a

bors added a commit that referenced this pull request Jun 23, 2016

@bors
Auto merge of #33890 - michaelwoerister:collector-driven-trans, r=eddyb 
Drive trans from the output of the translation item collector

This PR changes the way how translation works above the item level. Instead of walking the HIR and calling `trans_item()` on everything encountered (while instantiating monomorphizations on-demand), we now just process the list of translation items generated by the `trans::collector`. Using the collector has the benefit of being able to know the exact set of monomorphizations and symbols before actually running translation, something that is crucial for incremental compilation (but also has [other benefits](#33602)).

The collector has existed for quite a while now, but so far it's output was only used for running some auto-tests. With this PR it becomes the only source of truth about what gets translated.

One modification we had to make, compared to the initial approach, is that closures are not represented as their own `TransItems`. Doing so, while still supporting non-MIR-based translation, would have been prohibitively complex, and not worth the trouble since legacy-trans will disappear sooner or later. Once there is solely MIR-trans, it would be a good idea to make closures `TransItems` again.

This PR removes the most obvious functions and tables that are not needed anymore, but there's definitely still more cleanup possible later on (e.g. `monomorphize::monomorphic_fn()` does very little at this point). Since there are already more than 10 commits in here, doing this in a separate PR seems to be a better idea.

These changes definitely warrant a crater run.

Thanks @Aatch, for taking on one of the more tedious tasks during the dev-sprint!
Thanks @eddyb, for doing some nice refactorings to symbol name generation and making sure these landed so I could use them!

cc @rust-lang/compiler
cc @rust-lang/tools
374b45c

bors added a commit that referenced this pull request Jun 28, 2016

@bors
Auto merge of #33890 - michaelwoerister:collector-driven-trans, r=eddyb 
Drive trans from the output of the translation item collector

This PR changes the way how translation works above the item level. Instead of walking the HIR and calling `trans_item()` on everything encountered (while instantiating monomorphizations on-demand), we now just process the list of translation items generated by the `trans::collector`. Using the collector has the benefit of being able to know the exact set of monomorphizations and symbols before actually running translation, something that is crucial for incremental compilation (but also has [other benefits](#33602)).

The collector has existed for quite a while now, but so far it's output was only used for running some auto-tests. With this PR it becomes the only source of truth about what gets translated.

One modification we had to make, compared to the initial approach, is that closures are not represented as their own `TransItems`. Doing so, while still supporting non-MIR-based translation, would have been prohibitively complex, and not worth the trouble since legacy-trans will disappear sooner or later. Once there is solely MIR-trans, it would be a good idea to make closures `TransItems` again.

This PR removes the most obvious functions and tables that are not needed anymore, but there's definitely still more cleanup possible later on (e.g. `monomorphize::monomorphic_fn()` does very little at this point). Since there are already more than 10 commits in here, doing this in a separate PR seems to be a better idea.

These changes definitely warrant a crater run.

Thanks @Aatch, for taking on one of the more tedious tasks during the dev-sprint!
Thanks @eddyb, for doing some nice refactorings to symbol name generation and making sure these landed so I could use them!

cc @rust-lang/compiler
cc @rust-lang/tools
fa4e100

bors added a commit that referenced this pull request Jul 8, 2016

@bors
Auto merge of #33890 - michaelwoerister:collector-driven-trans, r=eddyb 
Drive trans from the output of the translation item collector

This PR changes the way how translation works above the item level. Instead of walking the HIR and calling `trans_item()` on everything encountered (while instantiating monomorphizations on-demand), we now just process the list of translation items generated by the `trans::collector`. Using the collector has the benefit of being able to know the exact set of monomorphizations and symbols before actually running translation, something that is crucial for incremental compilation (but also has [other benefits](#33602)).

The collector has existed for quite a while now, but so far it's output was only used for running some auto-tests. With this PR it becomes the only source of truth about what gets translated.

One modification we had to make, compared to the initial approach, is that closures are not represented as their own `TransItems`. Doing so, while still supporting non-MIR-based translation, would have been prohibitively complex, and not worth the trouble since legacy-trans will disappear sooner or later. Once there is solely MIR-trans, it would be a good idea to make closures `TransItems` again.

This PR removes the most obvious functions and tables that are not needed anymore, but there's definitely still more cleanup possible later on (e.g. `monomorphize::monomorphic_fn()` does very little at this point). Since there are already more than 10 commits in here, doing this in a separate PR seems to be a better idea.

These changes definitely warrant a crater run.

Thanks @Aatch, for taking on one of the more tedious tasks during the dev-sprint!
Thanks @eddyb, for doing some nice refactorings to symbol name generation and making sure these landed so I could use them!

cc @rust-lang/compiler
cc @rust-lang/tools
df28b57

bors added a commit that referenced this pull request Jul 8, 2016

@bors
Auto merge of #33890 - michaelwoerister:collector-driven-trans, r=eddyb 
Drive trans from the output of the translation item collector

This PR changes the way how translation works above the item level. Instead of walking the HIR and calling `trans_item()` on everything encountered (while instantiating monomorphizations on-demand), we now just process the list of translation items generated by the `trans::collector`. Using the collector has the benefit of being able to know the exact set of monomorphizations and symbols before actually running translation, something that is crucial for incremental compilation (but also has [other benefits](#33602)).

The collector has existed for quite a while now, but so far it's output was only used for running some auto-tests. With this PR it becomes the only source of truth about what gets translated.

One modification we had to make, compared to the initial approach, is that closures are not represented as their own `TransItems`. Doing so, while still supporting non-MIR-based translation, would have been prohibitively complex, and not worth the trouble since legacy-trans will disappear sooner or later. Once there is solely MIR-trans, it would be a good idea to make closures `TransItems` again.

This PR removes the most obvious functions and tables that are not needed anymore, but there's definitely still more cleanup possible later on (e.g. `monomorphize::monomorphic_fn()` does very little at this point). Since there are already more than 10 commits in here, doing this in a separate PR seems to be a better idea.

These changes definitely warrant a crater run.

Thanks @Aatch, for taking on one of the more tedious tasks during the dev-sprint!
Thanks @eddyb, for doing some nice refactorings to symbol name generation and making sure these landed so I could use them!

cc @rust-lang/compiler
cc @rust-lang/tools
d119362

@bluss bluss referenced this pull request Oct 30, 2016

Open

Use no-trans for every crate #16

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.