Spellchecking compiler comments
This PR cleans up the rest of the spelling mistakes in the compiler comments. This PR does not change any literal or code spelling issues.
This commit is contained in:
parent
3e7514670d
commit
5160f8f843
116 changed files with 171 additions and 171 deletions
|
@ -159,7 +159,7 @@ where
|
|||
// Unions and are always treated as a series of 64-bit integer chunks
|
||||
}
|
||||
abi::FieldsShape::Arbitrary { .. } => {
|
||||
// Stuctures with floating point numbers need special care.
|
||||
// Structures with floating point numbers need special care.
|
||||
|
||||
let mut data = parse_structure(
|
||||
cx,
|
||||
|
|
|
@ -49,7 +49,7 @@ pub fn target() -> Target {
|
|||
// setLibcallCallingConv(RTLIB::UREM_I64, CallingConv::X86_StdCall);
|
||||
// setLibcallCallingConv(RTLIB::MUL_I64, CallingConv::X86_StdCall);
|
||||
// }
|
||||
// The compiler intrisics should be implemented by compiler-builtins.
|
||||
// The compiler intrinsics should be implemented by compiler-builtins.
|
||||
// Unfortunately, compiler-builtins has not provided those intrinsics yet. Such as:
|
||||
// i386/divdi3.S
|
||||
// i386/lshrdi3.S
|
||||
|
@ -64,7 +64,7 @@ pub fn target() -> Target {
|
|||
// 2. Implement Intrinsics.
|
||||
// We evaluated all options.
|
||||
// #2 is hard because we need implement the intrinsics (_aulldiv) generated
|
||||
// from the other intrinscis (__udivdi3) implementation with the same
|
||||
// from the other intrinsics (__udivdi3) implementation with the same
|
||||
// functionality (udivmod_inner). If we let _aulldiv() call udivmod_inner!(),
|
||||
// then we are in loop. We may have to find another way to implement udivmod_inner!().
|
||||
// #1.2 may break the existing usage.
|
||||
|
@ -73,7 +73,7 @@ pub fn target() -> Target {
|
|||
// It uses cdecl, EAX/ECX/EDX as volatile register, and EAX/EDX as return value.
|
||||
// We also checked the LLVM X86TargetLowering, the differences between -gnu and -msvc
|
||||
// is fmodf(f32), longjmp() and TLS. None of them impacts the UEFI code.
|
||||
// As a result, we choose -gnu for i686 version before those intrisics are implemented in
|
||||
// As a result, we choose -gnu for i686 version before those intrinsics are implemented in
|
||||
// compiler-builtins. After compiler-builtins implements all required intrinsics, we may
|
||||
// remove -gnu and use the default one.
|
||||
Target {
|
||||
|
|
|
@ -1147,7 +1147,7 @@ pub struct TargetOptions {
|
|||
/// Linker arguments used in addition to `late_link_args` if at least one
|
||||
/// Rust dependency is dynamically linked.
|
||||
pub late_link_args_dynamic: LinkArgs,
|
||||
/// Linker arguments used in addition to `late_link_args` if aall Rust
|
||||
/// Linker arguments used in addition to `late_link_args` if all Rust
|
||||
/// dependencies are statically linked.
|
||||
pub late_link_args_static: LinkArgs,
|
||||
/// Linker arguments that are unconditionally passed *after* any
|
||||
|
@ -1255,7 +1255,7 @@ pub struct TargetOptions {
|
|||
/// handling COFF object files with more than 2<sup>15</sup> sections. Since each weak
|
||||
/// symbol needs its own COMDAT section, weak linkage implies a large
|
||||
/// number sections that easily exceeds the given limit for larger
|
||||
/// codebases. Consequently we want a way to disallow weak linkage on some
|
||||
/// codebase. Consequently we want a way to disallow weak linkage on some
|
||||
/// platforms.
|
||||
pub allows_weak_linkage: bool,
|
||||
/// Whether the linker support rpaths or not. Defaults to false.
|
||||
|
|
|
@ -109,7 +109,7 @@ pub fn options() -> TargetOptions {
|
|||
crt_objects_fallback: Some(CrtObjectsFallback::Wasm),
|
||||
|
||||
// This has no effect in LLVM 8 or prior, but in LLVM 9 and later when
|
||||
// PIC code is implemented this has quite a drastric effect if it stays
|
||||
// PIC code is implemented this has quite a drastic effect if it stays
|
||||
// at the default, `pic`. In an effort to keep wasm binaries as minimal
|
||||
// as possible we're defaulting to `static` for now, but the hope is
|
||||
// that eventually we can ship a `pic`-compatible standard library which
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue