'assertion failed: rp.is_none()' during compile #7400
Labels
E-needs-test
Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
Comments
|
@dcolish So it's a valid issue, (I haven't checked for duplicates yet), but that code shouldn't compile anyway. struct BitVector<'self> {
v: &'self [u8]
}That struct is defined to contain a slice that lasts for atleast as long as the struct itself. This is perfectly valid. However, this is wrong (explanation inline): pub fn new(n: u64) -> BitVector<'self> {
// So this constructs a ~[u8] and assigns it to 'f'
let f = vec::with_capacity::<u8>(n);
// This constructs 'BitVector' and gives it 'f', since 'f' is a ~[u8] and
// 'v' is a &[u8], 'f' is "auto-sliced" when you assign it like this.
BitVector {
v: f
}
// This is where the lifetime of 'f' ends, since slicing it doesn't move it,
// the lifetime ends here and the vector is freed.
// Since you are returning a pointer to that vector, this would mean that
// BitVector contains a dangling pointer. If it compiled this would be a use-
// after-free error, something lifetimes are supposed to prevent.
}cc'ing @nikomatsakis |
|
I bumbled across this as well; the problem seems to be that the |
|
Minimal testcase: pub trait NodeBase<'self> {
pub fn base_node(&'self self) -> &'self int;
}
pub fn create<'self, T: NodeBase<'self>>(node: &'self mut T) {
}
fn main() {
} |
|
Closed by #10153, relevant tests already appear to be checked in. |
Are the tests enabled? I didn't check them in, at least. |
|
I was specifically referencing https://github.com/mozilla/rust/blob/master/src/test/compile-fail/regions-undeclared.rs because this is just using an undeclared region. That being said, you know far more about this than I do, so I'll stick to just flagging as |
|
I don't think a special test is needed, there are tests target the named lifetime resolver. |
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Jul 1, 2021
New lint: `disallowed_script_idents` This PR implements a new lint to restrict locales that can be used in the code, as proposed in rust-lang#7376. Current concerns / unresolved questions: - ~~Mixed usage of `script` (as a Unicode term) and `locale` (as something that is easier to understand for the broad audience). I'm not sure whether these terms are fully interchangeable and whether in the current form it is more confusing than helpful.~~ `script` is now used everywhere. - ~~Having to mostly copy-paste `AllowedScript`. Probably it's not a big problem, as the list of scripts is standardized and is unlikely to change, and even if we'd stick to the `unicode_script::Script`, we'll still have to implement custom deserialization, and I don't think that it will be shorter in terms of the amount of LoC.~~ `unicode::Script` is used together with a filtering deserialize function. - Should we stick to the list of "recommended scripts" from [UAX rust-lang#31](http://www.unicode.org/reports/tr31/#Table_Recommended_Scripts) in the configuration? *Please write a short comment explaining your change (or "none" for internal only changes)* changelog: ``[`disallowed_script_idents`]`` r? `@Manishearth`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Code to produce
Backtrace is here https://gist.github.com/5864573
The text was updated successfully, but these errors were encountered: