MIR inlining does not handle SourceScopeLocalData #66137

Activity

1. Aaron1011

   changed the title [-]MIR inlinging does not handle `SourceScopeLocalData`[/-] [+]MIR inlining does not handle `SourceScopeLocalData`[/+] on Nov 5, 2019
2. jonas-schievink

   added

   A-MIRArea: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.htmlArea: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html

   C-bugCategory: This is a bug.Category: This is a bug.

   T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.

   on Nov 5, 2019
3. RalfJung

   added

   A-debuginfoArea: Debugging information in compiled programs (DWARF, PDB, etc.)Area: Debugging information in compiled programs (DWARF, PDB, etc.)

   on Nov 6, 2019
4. eddyb

   added

   E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

   on Nov 6, 2019
5. eddyb commented on Nov 6, 2019

   

   eddyb

   on Nov 6, 2019

   Contributor

   More actions

   Sounds like a simple enough omission, but I'm surprised this doesn't break any of our mir-opt tests.
6. Aaron1011 commented on Nov 6, 2019

   

   Aaron1011

   on Nov 6, 2019

   ContributorAuthor

   More actions

   I don't think this is E-Easy - source_scope_local_data is crate local, and it's not immediately obvious to me what the correct beehvaior is for cross-crate inlining.
7. Dylan-DPC-zz commented on Nov 13, 2019

   

   Dylan-DPC-zz

   on Nov 13, 2019

   More actions

   @rustbot assign @Aaron1011
8. rustbot

   assigned

   Aaron1011

   on Nov 13, 2019
9. Aaron1011

   added a commit that references this issue on Nov 13, 2019

   Fix generating CTFE backtrace on optimized MIR

   ...

   This issue will close once commit dadd817 is merged into the 'master' branch.

   dadd817
10. eddyb commented on Nov 13, 2019

    

    eddyb

    on Nov 13, 2019

    Contributor

    More actions

    @Aaron1011 Oh, I thought the concern was entirely about same-crate, sorry!

    I think the fix in that case is to move the ClearCrossCrate inward, i.e. change SourceScopeData to contain a ClearCrossCrate<SourceScopeLocalData> - I don't think the size of SourceScopeData is critical (but we should run perf anyway).
11. Aaron1011 commented on Nov 14, 2019

    

    Aaron1011

    on Nov 14, 2019

    ContributorAuthor

    More actions

    @eddyb: SourceScopeData doesn't contain SourceScopeLocalData. Your change would require wrapping both fields of SourceScopeLocalData in ClearCrossCrate, since SourceScopeLocalData is stored in an IndexVec in Body.source_scope_local_data
12. Aaron1011 commented on Nov 14, 2019

    

    Aaron1011

    on Nov 14, 2019

    ContributorAuthor

    More actions

    Oops, I misread your proposal - you were talking about changing SourceScopeData to contain a SourceScopeLocalData. I'll try that.

    👍React with 👍1Reacted by Eduard-Mihai Burtescu
13. oli-obk commented on Dec 29, 2019

    

    oli-obk

    on Dec 29, 2019

    Contributor

    More actions

    This was fixed in #66789 as far as I can tell
14. oli-obk

    closed this as completedon Dec 29, 2019