Implementing Weak References in Rust

This challenge focuses on understanding and implementing the concept of weak references in Rust. Weak references are crucial for breaking reference cycles and managing memory efficiently in scenarios where you need to observe a resource without preventing its deallocation. You will build a system that demonstrates how weak references can be used to safely access shared data that might have been dropped.

Problem Description

Your task is to implement a system that utilizes weak references to manage a shared resource, a Document, which can be accessed by multiple Editor instances. An Editor should be able to hold a reference to a Document. However, to prevent memory leaks caused by reference cycles (e.g., if an Editor held a strong reference to a Document and the Document also held references back to its Editors), the Editor should hold a weak reference to the Document.

What needs to be achieved: You need to design and implement data structures that allow for shared ownership of a Document and multiple Editors that can observe the Document.

Key requirements:

Document Structure: A Document should be able to be shared. It needs to track its own state (e.g., a simple string content).
Editor Structure: An Editor should hold a weak reference to a Document. It should have a method to attempt to access the Document.
Weak Reference Management: The Editor's weak reference to the Document should automatically become invalidated when the Document is deallocated.
Safe Access: The Editor's method to access the Document should gracefully handle cases where the Document has been dropped.

Expected behavior:

When a Document is created and Editors are attached, the Editors should be able to access the Document's content.
When the Document is dropped (i.e., its strong reference count reaches zero), any subsequent attempts by an Editor to access the Document should indicate that it's no longer available.

Important edge cases to consider:

What happens if an Editor tries to access a Document after the Document has been dropped?
How does Rust's ownership and borrowing system interact with weak references?

Examples

Example 1:

// Setup
let doc = Rc::new(Document::new("Initial content".to_string()));
let editor1 = Editor::new(Rc::downgrade(&doc));
let editor2 = Editor::new(Rc::downgrade(&doc));

// Accessing content while document is alive
assert_eq!(editor1.get_document_content(), Some("Initial content".to_string()));
assert_eq!(editor2.get_document_content(), Some("Initial content".to_string()));

// Dropping the document (implicitly by going out of scope for Rc)
drop(doc);

// Accessing content after document is dropped
assert_eq!(editor1.get_document_content(), None);
assert_eq!(editor2.get_document_content(), None);

Explanation: Initially, editor1 and editor2 hold weak references to the doc. They can successfully retrieve the document's content. After doc is dropped (its Rc goes out of scope and its strong count becomes zero), the weak references in the editors become invalid, and subsequent access attempts return None.

Example 2:

// Setup
let doc_strong_ref = Rc::new(Document::new("Shared data".to_string()));
let weak_ref_to_doc = Rc::downgrade(&doc_strong_ref);
let editor = Editor::new(weak_ref_to_doc.clone()); // Editor holds a clone of the weak ref

// Document is alive, editor can access it
assert_eq!(editor.get_document_content(), Some("Shared data".to_string()));

// Create another strong reference, the document is still alive
let another_doc_ref = doc_strong_ref.clone();
assert_eq!(another_doc_ref.content, "Shared data");

// Drop the original strong reference
drop(doc_strong_ref);

// Document is still alive because of 'another_doc_ref'
assert_eq!(editor.get_document_content(), Some("Shared data".to_string()));

// Drop the last strong reference
drop(another_doc_ref);

// Now the document should be dropped, and editor access should fail
assert_eq!(editor.get_document_content(), None);

// Dropping the editor itself doesn't affect the document's lifecycle
// The weak reference inside the editor will simply become invalid when its owner (the editor) is dropped,
// but the key is that the document is dropped when all *strong* references are gone.

Explanation: This example demonstrates that the Document is only deallocated when all Rc (strong) references to it are gone, regardless of how many weak references exist. The Editor correctly reports None only after the last strong reference to the Document is dropped.

Constraints

You must use Rust's standard library features for shared ownership and weak references. Specifically, std::rc::Rc and std::rc::Weak should be utilized.
The Document should contain at least a field to hold some arbitrary data (e.g., a String).
The Editor must store a Weak<Document> reference.
The implementation should be thread-safe if using std::sync::Arc and std::sync::Weak (though the primary focus is on Rc for simplicity, consider how it would extend).
The solution should not rely on unsafe code for managing references.

Notes

Think about how Rc and Weak work together. Rc provides shared ownership, incrementing a strong count. Weak provides a non-owning reference, incrementing a weak count.
When you have a Weak reference, you need to "upgrade" it to an Rc (a strong reference) to access the underlying data. This upgrade operation returns an Option<Rc<T>>.
The Option returned by upgrade() is None if the underlying Rc has already been dropped. This is the core mechanism for handling deallocated resources.
Consider the lifetime implications of your data structures.

Success looks like a clean, idiomatic Rust implementation that correctly demonstrates the behavior of weak references in preventing memory leaks and allowing safe observation of potentially deallocated data.