Skip to content
New issue

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

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

Already on GitHub? # to your account

Put #[unsafe_destructor] behind a feature gate #14937

Closed
pcwalton opened this issue Jun 16, 2014 · 3 comments
Closed

Put #[unsafe_destructor] behind a feature gate #14937

pcwalton opened this issue Jun 16, 2014 · 3 comments
Labels
A-destructors Area: Destructors (`Drop`, …)
Milestone

Comments

@pcwalton
Copy link
Contributor

I propose putting #[unsafe_destructor] behind a feature gate because it's definitely not what we want to do long-term. This would also essentially solve #8142.

Nominating for 1.0, P-backcompat-lang.

@alexcrichton
Copy link
Member

I think that type parameters may only be half the problem, this is still a problem with all RAII-like structures with lifetimes, which are liberally used in the standard library. For example, this innocuous looking code triggers valgrind errors:

use std::cell::RefCell;
fn main() {
    let b = {
        let a = box RefCell::new(4);
        *a.borrow() + 1
    };
    println!("{}", b);
}
$ valgrind ./foo
==9880== Memcheck, a memory error detector
==9880== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==9880== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==9880== Command: ./foo
==9880== 
==9880== Invalid read of size 8
==9880==    at 0x403AC2: cell::Cell$LT$T$GT$::get::h14749520627650063431::v0.0 (in /home/alex/foo)
==9880==    by 0x403C2A: cell::Ref$LT$$x27b$C$$x20T$GT$.Drop::drop::h5517615880807730945::v0.0 (in /home/alex/foo)
==9880==    by 0x40406A: core..cell..Ref$LT$$x27_$C$int$GT$::glue_drop.1537::h7a74728680c53b3a (in /home/alex/foo)
==9880==    by 0x4031E1: main::hfd2b07b8610388fafaa::v0.0 (in /home/alex/foo)
==9880==    by 0x447512: start::closure.7199 (in /home/alex/foo)
==9880==    by 0x463862: task::Task::run::closure.5303 (in /home/alex/foo)
==9880==    by 0x466C4B: rust_try (in /home/alex/foo)
==9880==    by 0x465565: unwind::try::h7d720262cba71fd0fGd::v0.11.0.pre (in /home/alex/foo)
==9880==    by 0x463714: task::Task::run::hac578e5b353eedcbVVc::v0.11.0.pre (in /home/alex/foo)
==9880==    by 0x4472CD: start::h0149aeff7c3a4b69Jme::v0.11.0.pre (in /home/alex/foo)
==9880==    by 0x447098: lang_start::h3e00b03c17efac073le::v0.11.0.pre (in /home/alex/foo)
==9880==    by 0x40332E: main (in /home/alex/foo)
==9880==  Address 0x6014058 is 8 bytes inside a block of size 16 free'd
==9880==    at 0x471379: je_dallocx (in /home/alex/foo)
==9880==    by 0x40371F: heap::deallocate::h7bc897bb314e6fc3Bfa::v0.0 (in /home/alex/foo)
==9880==    by 0x403699: heap::exchange_free::h3a6062ae495b91fcefa::v0.0 (in /home/alex/foo)
==9880==    by 0x403FA0: _$UP$i8::glue_drop.1534::h08c160eb1ce0fd99 (in /home/alex/foo)
==9880==    by 0x4031D4: main::hfd2b07b8610388fafaa::v0.0 (in /home/alex/foo)
==9880==    by 0x447512: start::closure.7199 (in /home/alex/foo)
==9880==    by 0x463862: task::Task::run::closure.5303 (in /home/alex/foo)
==9880==    by 0x466C4B: rust_try (in /home/alex/foo)
==9880==    by 0x465565: unwind::try::h7d720262cba71fd0fGd::v0.11.0.pre (in /home/alex/foo)
==9880==    by 0x463714: task::Task::run::hac578e5b353eedcbVVc::v0.11.0.pre (in /home/alex/foo)
==9880==    by 0x4472CD: start::h0149aeff7c3a4b69Jme::v0.11.0.pre (in /home/alex/foo)
==9880==    by 0x447098: lang_start::h3e00b03c17efac073le::v0.11.0.pre (in /home/alex/foo)
==9880== 
==9880== Invalid write of size 8
==9880==    at 0x403B4A: cell::Cell$LT$T$GT$::set::h11020375487951902910::v0.0 (in /home/alex/foo)
==9880==    by 0x403DA8: cell::Ref$LT$$x27b$C$$x20T$GT$.Drop::drop::h5517615880807730945::v0.0 (in /home/alex/foo)
==9880==    by 0x40406A: core..cell..Ref$LT$$x27_$C$int$GT$::glue_drop.1537::h7a74728680c53b3a (in /home/alex/foo)
==9880==    by 0x4031E1: main::hfd2b07b8610388fafaa::v0.0 (in /home/alex/foo)
==9880==    by 0x447512: start::closure.7199 (in /home/alex/foo)
==9880==    by 0x463862: task::Task::run::closure.5303 (in /home/alex/foo)
==9880==    by 0x466C4B: rust_try (in /home/alex/foo)
==9880==    by 0x465565: unwind::try::h7d720262cba71fd0fGd::v0.11.0.pre (in /home/alex/foo)
==9880==    by 0x463714: task::Task::run::hac578e5b353eedcbVVc::v0.11.0.pre (in /home/alex/foo)
==9880==    by 0x4472CD: start::h0149aeff7c3a4b69Jme::v0.11.0.pre (in /home/alex/foo)
==9880==    by 0x447098: lang_start::h3e00b03c17efac073le::v0.11.0.pre (in /home/alex/foo)
==9880==    by 0x40332E: main (in /home/alex/foo)
==9880==  Address 0x6014058 is 8 bytes inside a block of size 16 free'd
==9880==    at 0x471379: je_dallocx (in /home/alex/foo)
==9880==    by 0x40371F: heap::deallocate::h7bc897bb314e6fc3Bfa::v0.0 (in /home/alex/foo)
==9880==    by 0x403699: heap::exchange_free::h3a6062ae495b91fcefa::v0.0 (in /home/alex/foo)
==9880==    by 0x403FA0: _$UP$i8::glue_drop.1534::h08c160eb1ce0fd99 (in /home/alex/foo)
==9880==    by 0x4031D4: main::hfd2b07b8610388fafaa::v0.0 (in /home/alex/foo)
==9880==    by 0x447512: start::closure.7199 (in /home/alex/foo)
==9880==    by 0x463862: task::Task::run::closure.5303 (in /home/alex/foo)
==9880==    by 0x466C4B: rust_try (in /home/alex/foo)
==9880==    by 0x465565: unwind::try::h7d720262cba71fd0fGd::v0.11.0.pre (in /home/alex/foo)
==9880==    by 0x463714: task::Task::run::hac578e5b353eedcbVVc::v0.11.0.pre (in /home/alex/foo)
==9880==    by 0x4472CD: start::h0149aeff7c3a4b69Jme::v0.11.0.pre (in /home/alex/foo)
==9880==    by 0x447098: lang_start::h3e00b03c17efac073le::v0.11.0.pre (in /home/alex/foo)
==9880== 
5
==9880== 
==9880== HEAP SUMMARY:
==9880==     in use at exit: 0 bytes in 0 blocks
==9880==   total heap usage: 18 allocs, 18 frees, 2,016 bytes allocated
==9880== 
==9880== All heap blocks were freed -- no leaks are possible
==9880== 
==9880== For counts of detected and suppressed errors, rerun with: -v
==9880== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

As much as I'd love to punt on things for 1.0, this seems like a serious issue we need to fix.

@brson brson added this to the 1.0 milestone Jun 19, 2014
@brson
Copy link
Contributor

brson commented Jun 19, 2014

1.0, P-backcompat-lang

@pcwalton
Copy link
Contributor Author

Closed by dcbf4ec.

matthiaskrgr pushed a commit to matthiaskrgr/rust that referenced this issue Feb 5, 2024
feat: Support for GOTO def from *inside* files included with include! macro

close rust-lang#14937
Try to implement goto def from *inside* files included with include! macro.
This implementation has two limitations:
1. Only **one** file which calls include! will be tracked. (I think multiple file be included is a rare case and we may let it go for now)
2. Mapping token from included file to macro call file (semantics.rs:646~658) works fine but I am not sure is this the correct way to implement.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-destructors Area: Destructors (`Drop`, …)
Projects
None yet
Development

No branches or pull requests

3 participants