fix some typos (#1398)
This commit is contained in:
parent
9cdee34a55
commit
767d2b1135
|
|
@ -101,7 +101,7 @@ pub enum InlineAsmOperand {
|
|||
|
||||
The `asm!` macro is implemented in `rustc_builtin_macros` and outputs an `InlineAsm` AST node. The
|
||||
template string is parsed using `fmt_macros`, positional and named operands are resolved to
|
||||
explicit operand indicies. Since target information is not available to macro invocations,
|
||||
explicit operand indices. Since target information is not available to macro invocations,
|
||||
validation of the registers and register classes is deferred to AST lowering.
|
||||
|
||||
## HIR
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ For better incremental build times, the CGU partitioner creates two CGU for each
|
|||
modules. One is for "stable" i.e. non-generic code and the other is more volatile code i.e.
|
||||
monomorphized/specialized instances.
|
||||
|
||||
For depenencies, consider Crate A and Crate B, such that Crate B depends on Crate A.
|
||||
For dependencies, consider Crate A and Crate B, such that Crate B depends on Crate A.
|
||||
The following table lists different scenarios for a function in Crate A that might be used by one
|
||||
or more modules in Crate B.
|
||||
|
||||
|
|
|
|||
|
|
@ -231,7 +231,7 @@ artifacts into the appropriate place, skipping the cargo invocation.
|
|||
|
||||
### Cross-compiling rustc
|
||||
|
||||
*Cross-compiling* is the process of compiling code that will run on another archicture.
|
||||
*Cross-compiling* is the process of compiling code that will run on another architecture.
|
||||
For instance, you might want to build an ARM version of rustc using an x86 machine.
|
||||
Building stage2 `std` is different when you are cross-compiling.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ exists. The marker is the attribute `#[lang = "..."]`, and there are various dif
|
|||
`...`, i.e. various different 'lang items'.
|
||||
|
||||
Many such lang items can be implemented only in one sensible way, such as `add` (`trait
|
||||
core::ops::Add`) or `future_trait` (`trait core::future::Future`). Others can be overriden to
|
||||
core::ops::Add`) or `future_trait` (`trait core::future::Future`). Others can be overridden to
|
||||
achieve some specific goals; for example, you can control your binary's entrypoint.
|
||||
|
||||
Features provided by lang items include:
|
||||
|
|
@ -45,7 +45,7 @@ if let Some(sized_trait_def_id) = tcx.lang_items().sized_trait() {
|
|||
```
|
||||
|
||||
Note that `sized_trait()` returns an `Option`, not the `DefId` itself.
|
||||
That's because language items are defined in the standard libray, so if someone compiles with
|
||||
That's because language items are defined in the standard library, so if someone compiles with
|
||||
`#![no_core]` (or for some lang items, `#![no_std]`), the lang item may not be present.
|
||||
You can either:
|
||||
|
||||
|
|
|
|||
|
|
@ -196,7 +196,7 @@ struct MyDatabase {
|
|||
runtime : salsa::Runtime<MyDatabase>,
|
||||
}
|
||||
///And this trait has to be implemented
|
||||
impl salsa::Databse for MyDatabase {
|
||||
impl salsa::Database for MyDatabase {
|
||||
fn salsa_runtime(&self) -> &salsa::Runtime<MyDatabase> {
|
||||
&self.runtime
|
||||
}
|
||||
|
|
|
|||
Loading…
Reference in New Issue