Documentation on cargo doc

Signed-off-by: georgepisaltu <[email protected]>

substrate/primitives/runtime/src/traits/transaction_extension/dispatch_transaction.rs

@@ -19,9 +19,9 @@
 
 use super::*;
 
-/// Single-function utility trait with a blanket impl over `TransactionExtension` in order to
-/// provide transaction dispatching functionality. We avoid implementing this directly on the
-/// trait since we never want it to be overriden by the trait implementation.
+/// Single-function utility trait with a blanket impl over [TransactionExtension] in order to
+/// provide transaction dispatching functionality. We avoid implementing this directly on the trait
+/// since we never want it to be overriden by the trait implementation.
 pub trait DispatchTransaction<Call: Dispatchable> {
 	/// The origin type of the transaction.
 	type Origin;
@@ -35,8 +35,8 @@ pub trait DispatchTransaction<Call: Dispatchable> {
 	type Pre;
 	/// Just validate a transaction.
 	///
-	/// The is basically the same as `validate`, except that there is no need to supply the
-	/// bond data.
+	/// The is basically the same as [validate](TransactionExtension::validate), except that there
+	/// is no need to supply the bond data.
 	fn validate_only(
 		&self,
 		origin: Self::Origin,
@@ -60,9 +60,9 @@ pub trait DispatchTransaction<Call: Dispatchable> {
 		info: &Self::Info,
 		len: usize,
 	) -> Self::Result;
-	/// Do everything which would be done in a `dispatch_transaction`, but instead of executing the
-	/// call, execute [substitute] instead. Since this doesn't actually dispatch the call, it
-	/// doesn't need to consume it and so `call` can be passed as a reference.
+	/// Do everything which would be done in a [dispatch_transaction](Self::dispatch_transaction),
+	/// but instead of executing the call, execute `substitute` instead. Since this doesn't actually
+	/// dispatch the call, it doesn't need to consume it and so `call` can be passed as a reference.
 	fn test_run(
 		self,
 		origin: Self::Origin,

substrate/primitives/runtime/src/traits/transaction_extension/mod.rs

@@ -139,9 +139,10 @@ pub trait TransactionExtensionBase: TransactionExtensionInterior {
 /// Of the 5 functions in this trait, 3 of them must return a value of an associated type on
 /// success, and none of these types implement [Default] or anything like it. This means that
 /// default implementations cannot be provided for these functions. However, a macro is provided
-/// [impl_tx_ext_default] which is capable of generating default implementations for each of these
-/// 3 functions. If you do not wish to introduce additional logic into the transaction pipeline,
-/// then it is recommended that you use this macro to implement these functions.
+/// [impl_tx_ext_default](crate::impl_tx_ext_default) which is capable of generating default
+/// implementations for each of these 3 functions. If you do not wish to introduce additional logic
+/// into the transaction pipeline, then it is recommended that you use this macro to implement these
+/// functions.
 ///
 /// ## Pipelines, Inherited Implications, and Authorized Origins
 ///
@@ -151,11 +152,14 @@ pub trait TransactionExtensionBase: TransactionExtensionInterior {
 /// pipeline is executed in order, and the output of each extension is aggregated and/or relayed as
 /// the input to the next extension in the pipeline.
 ///
-/// This ordered composition happens with all datatypes ([Val], [Pre] and [Implicit]) as well as
+/// This ordered composition happens with all datatypes ([Val](TransactionExtension::Val),
+/// [Pre](TransactionExtension::Pre) and [Implicit](TransactionExtensionBase::Implicit)) as well as
 /// all functions. There are important consequences stemming from how the composition affects the
 /// meaning of the `origin` and `implication` parameters as well as the results. Whereas the
-/// [prepare] and [post_dispatch] functions are clear in their meaning, the [validate] function is
-/// sfairly sophisticated and warrants further explanation.
+/// [prepare](TransactionExtension::prepare) and
+/// [post_dispatch](TransactionExtension::post_dispatch) functions are clear in their meaning, the
+/// [validate](TransactionExtension::validate) function is sfairly sophisticated and warrants
+/// further explanation.
 ///
 /// Firstly, the `origin` parameter. The `origin` passed into the first item in a pipeline is simply
 /// that passed into the tuple itself. It represents an authority who has authorized the implication
@@ -172,17 +176,18 @@ pub trait TransactionExtensionBase: TransactionExtensionInterior {
 /// following may each imply consequence for this origin. We call this the *inherited implication*.
 ///
 /// The *inherited implication* is the cumulated on-chain effects born by whatever origin is
-/// returned. It is expressed to the [validate] function only as the `implication` argument which
-/// implements the [Encode] trait. A transaction extension may define its own implications through
-/// its own fields and the [implicit] function. This is only utilized by extensions which preceed
-/// it in a pipeline or, if the transaction is an old-school signed trasnaction, the udnerlying
-/// transaction verification logic.
+/// returned. It is expressed to the [validate](TransactionExtension::validate) function only as the
+/// `implication` argument which implements the [Encode] trait. A transaction extension may define
+/// its own implications through its own fields and the
+/// [implicit](TransactionExtensionBase::implicit) function. This is only utilized by extensions
+/// which preceed it in a pipeline or, if the transaction is an old-school signed trasnaction, the
+/// udnerlying transaction verification logic.
 ///
-/// **The inherited implication passed as the `implication` parameter to [validate] does not
-/// include the extension's inner data itself nor does it include the result of the extension's
-/// `implicit` function.** If you both provide an implication and rely on the implication, then you
-/// need to manually aggregate your extensions implication with the aggregated implication passed
-/// in.
+/// **The inherited implication passed as the `implication` parameter to
+/// [validate](TransactionExtension::validate) does not include the extension's inner data itself
+/// nor does it include the result of the extension's `implicit` function.** If you both provide an
+/// implication and rely on the implication, then you need to manually aggregate your extensions
+/// implication with the aggregated implication passed in.
 pub trait TransactionExtension<Call: Dispatchable, Context>: TransactionExtensionBase {
 	/// The type that encodes information that can be passed from validate to prepare.
 	type Val;
@@ -216,8 +221,9 @@ pub trait TransactionExtension<Call: Dispatchable, Context>: TransactionExtensio
 	///
 	/// Returns a [ValidateResult], which is a [Result] whose success type is a tuple of
 	/// [ValidTransaction] (defining useful metadata for the transaction queue), the [Self::Val]
-	/// token of this transaction, which gets passed into [prepare], and the origin of the
-	/// transaction, which gets passed into [prepare] and is ultimately used for dispatch.
+	/// token of this transaction, which gets passed into [prepare](TransactionExtension::prepare),
+	/// and the origin of the transaction, which gets passed into
+	/// [prepare](TransactionExtension::prepare) and is ultimately used for dispatch.
 	fn validate(
 		&self,
 		origin: OriginOf<Call>,
@@ -233,9 +239,10 @@ pub trait TransactionExtension<Call: Dispatchable, Context>: TransactionExtensio
 	///
 	/// This is for actions which do not happen in the transaction queue but only immediately prior
 	/// to the point of dispatch on-chain. This should not return an error, since errors
-	/// should already have been identified during the [validate] call. If an error is returned,
-	/// the transaction will be considered invalid but no state changes will happen and therefore
-	/// work done in [validate] will not be paid for.
+	/// should already have been identified during the [validate](TransactionExtension::validate)
+	/// call. If an error is returned, the transaction will be considered invalid but no state
+	/// changes will happen and therefore work done in [validate](TransactionExtension::validate)
+	/// will not be paid for.
 	///
 	/// Unlike `validate`, this function may consume `self`.
 	///