Merge branch 'master' of https://github.com/ridwanabdillahi/rfcs into natvis

ridwanabdillahi · ridwanabdillahi · commit cf1cba042657 · 2022-03-25T11:45:49.000-07:00
diff --git a/text/0048-traits.md b/text/0048-traits.md
@@ -219,7 +219,7 @@ wait till the end then we will have more type information available.
 
 In my proposed solution, we eliminate the phase distinction. Instead,
 we simply track *pending constraints*. We are free to attempt to
-resolve pending constraints whenever desired. In paricular, whenever
+resolve pending constraints whenever desired. In particular, whenever
 we find we need more type information to proceed with some
 type-overloaded operation, rather than reporting an error we can try
 and resolve pending constraints. If that helps give more information,
diff --git a/text/0198-slice-notation.md b/text/0198-slice-notation.md
@@ -222,6 +222,6 @@ There are at least two downsides to doing so, however:
 * The idea of `Vec` as a smart pointer around a slice, and the use of `&*v` as
   above, is somewhat counterintuitive, especially for such a basic type.
 
-Ultimately, notation for slicing seems desireable on its own merits anyway, and
+Ultimately, notation for slicing seems desirable on its own merits anyway, and
 if it can eliminate the need to implement `Deref` for `Vec` and `String`, all
 the better.
diff --git a/text/0213-defaulted-type-params.md b/text/0213-defaulted-type-params.md
@@ -555,7 +555,7 @@ way (mechanical default outside of fn body, inference within).
 An alternative design is to use the `K=V` notation proposed in the
 associated items RFC for specify the values of default type
 parameters. However, this is somewhat odd, because default type
-parameters appear in a positional list, and thus it is suprising that
+parameters appear in a positional list, and thus it is surprising that
 values for the non-defaulted parameters are given positionally, but
 values for the defaulted type parameters are given with labels.
 
diff --git a/text/0216-collection-views.md b/text/0216-collection-views.md
@@ -123,7 +123,7 @@ is when you're *not sure* if you need to insert, in which case you should be pre
 Otherwise, `find_mut` is likely sufficient.
 
 The result is actually an enum, that will either be Occupied or Vacant. These two variants correspond
-to concrete types for when the key matched something in the map, and when the key didn't, repsectively.
+to concrete types for when the key matched something in the map, and when the key didn't, respectively.
 
 If there isn't a match, the user has exactly one option: insert a value using `set`, which will also insert
 the guarantor, and destroy the Entry. This is to avoid the costs of maintaining the structure, which
diff --git a/text/0255-object-safety.md b/text/0255-object-safety.md
@@ -33,10 +33,10 @@ SomeTrait for SomeTrait { ... }`, but that seems weird and confusing and rather
 like boilerplate. Note that the precise mechanism here is out of scope for this
 RFC).
 
-This is only sound if the trait is /object-safe/. We say a method `m` on trait
+This is only sound if the trait is object-safe. We say a method `m` on trait
 `T` is object-safe if it is legal (in current Rust) to call `x.m(...)` where `x`
-has type `&T`, i.e., `x` is a trait object. If all methods in `T` are object-
-safe, then we say `T` is object-safe.
+has type `&T`, i.e., `x` is a trait object. If all methods in `T` are object-safe,
+then we say `T` is object-safe.
 
 If we ignore this restriction we could allow code such as the following:
 
@@ -61,8 +61,8 @@ traits. This makes both method call and using trait objects with generic code
 simpler. The downside is that it makes Rust less flexible, since not all traits
 can be used to create trait objects.
 
-Software evolution is improved with this proposal: imagine adding a non-object-
-safe method to a previously object-safe trait. With this proposal, you would
+Software evolution is improved with this proposal: imagine adding a non-object-safe
+method to a previously object-safe trait. With this proposal, you would
 then get errors wherever a trait-object is created. The error would explain why
 the trait object could not be created and point out exactly which method was to
 blame and why. Without this proposal, the only errors you would get would be
diff --git a/text/0403-cargo-build-command.md b/text/0403-cargo-build-command.md
@@ -413,7 +413,7 @@ would look like with respect to its set of C dependencies.
 
 ## Case study: generated code
 
-As the release of Rust 1.0 comes closer, the use of complier plugins has become
+As the release of Rust 1.0 comes closer, the use of compiler plugins has become
 increasingly worrying over time. It is likely that plugins will not be available
 by default in the stable and beta release channels of Rust. Many core Cargo
 packages in the ecosystem today, such as gl-rs and iron, depend on plugins
diff --git a/text/0507-release-channels.md b/text/0507-release-channels.md
@@ -290,7 +290,7 @@ is added in addition to the existing `staged_stable` attribute, as
 well recording the version in which the deprecation was performed with
 the `since` parameter.
 
-(Occassionally unstable APIs may be deprecated for the sake of easing
+(Occasionally unstable APIs may be deprecated for the sake of easing
 user transitions, in which case they receive both the `staged_stable`
 and `staged_deprecated` attributes at once.)
 
diff --git a/text/0528-string-patterns.md b/text/0528-string-patterns.md
@@ -315,7 +315,7 @@ without a lifetime parameter by making use of higher kinded types in order to si
 string APIs. Eg, instead of `fn starts_with<'a, P>(&'a self, pat: P) -> bool where P: Pattern<'a>;`
 you'd have `fn starts_with<P>(&self, pat: P) -> bool where P: Pattern;`.
 
-In order to not break backwards-compability, these can use the same generic-impl trick to
+In order to not break backwards-compatibility, these can use the same generic-impl trick to
 forward to the old traits, which would roughly look like this:
 
 ```rust
diff --git a/text/0550-macro-future-proofing.md b/text/0550-macro-future-proofing.md
@@ -183,7 +183,7 @@ ensures that a legal macro definition will continue to assign the same
 determination as to where `... tt` ends and `uu ...` begins, even as
 new syntactic forms are added to the language.
 
-The second part says that a separated complex NT must use a seperator
+The second part says that a separated complex NT must use a separator
 token that is part of the predetermined follow set for the internal
 contents of the NT. This ensures that a legal macro definition will
 continue to parse an input fragment into the same delimited sequence
@@ -318,9 +318,9 @@ NT could be empty (i.e. ε ∈ FIRST(interior)). (I overlooked this fact
 in my first round of prototyping.)
 
 NOTE: The above definition for LAST assumes that we keep our
-pre-existing rule that the seperator token in a complex NT is *solely* for
+pre-existing rule that the separator token in a complex NT is *solely* for
 separating elements; i.e. that such NT's do not match fragments that
-*end with* the seperator token. If we choose to lift this restriction
+*end with* the separator token. If we choose to lift this restriction
 in the future, the above definition will need to be revised
 accordingly.
 
diff --git a/text/0587-fn-return-should-be-an-associated-type.md b/text/0587-fn-return-should-be-an-associated-type.md
@@ -179,6 +179,6 @@ type variable).
 
 We could make `FnMut()` desugar to `FnMut<()>`, and hence require an
 explicit `FnMut() -> ()` to bind the return type to unit.  This feels
-suprising and inconsistent.
+surprising and inconsistent.
 
 
diff --git a/text/0592-c-str-deref.md b/text/0592-c-str-deref.md
@@ -43,7 +43,7 @@ for representing borrowed C string data, since:
    to FFI functions without an intermediate allocation in `CString`.
 
 As a pattern of owned/borrowed type pairs has been established
-thoughout other modules (see e.g.
+throughout other modules (see e.g.
 [path reform](https://github.com/rust-lang/rfcs/pull/474)),
 it makes sense that `CString` gets its own borrowed counterpart.
 
diff --git a/text/0599-default-object-bound.md b/text/0599-default-object-bound.md
@@ -111,7 +111,7 @@ expressions, they only include cover those cases where an explicit
 lifetime bound was required today. In function signatures, lifetime
 bounds can always be omitted, and it is impossible to distinguish
 `&SomeTrait` from `&SomeStruct` using only a regular
-expression. However, we belive that the proposed rule would be
+expression. However, we believe that the proposed rule would be
 compatible with the existing defaults for function signatures in all
 or virtually all cases.
 
diff --git a/text/0640-debug-improvements.md b/text/0640-debug-improvements.md
@@ -18,7 +18,7 @@ to implement `Debug` manually.
 
 The conventions for `Debug` format state that output should resemble Rust
 struct syntax, without added line breaks. This can make output difficult to
-read in the presense of complex and deeply nested structures:
+read in the presence of complex and deeply nested structures:
 ```rust
 HashMap { "foo": ComplexType { thing: Some(BufferedReader { reader: FileStream { path: "/home/sfackler/rust/README.md", mode: R }, buffer: 1013/65536 }), other_thing: 100 }, "bar": ComplexType { thing: Some(BufferedReader { reader: FileStream { path: "/tmp/foobar", mode: R }, buffer: 0/65536 }), other_thing: 0 } }
 ```
diff --git a/text/0771-std-iter-once.md b/text/0771-std-iter-once.md
@@ -40,7 +40,7 @@ These wrapper structs exist to allow future backwards-compatible changes, and hi
 
 # Drawbacks
 
-Although a tiny amount of code, it still does come with a testing, maintainance, etc. cost.
+Although a tiny amount of code, it still does come with a testing, maintenance, etc. cost.
 
 It's already possible to do this via `Some(x).into_iter()`, `std::iter::repeat(x).take(1)` (for `x: Clone`), `vec![x].into_iter()`, various contraptions involving `iterate`...
 
diff --git a/text/0809-box-and-in-for-stdlib.md b/text/0809-box-and-in-for-stdlib.md
@@ -383,7 +383,7 @@ pub trait Place<Data: ?Sized> {
 /// intermediate values (e.g. the return value of `Vec::emplace_back`)
 /// or `Copy`, since the `make_place` method takes `self` by value.
 pub trait Placer<Data: ?Sized> {
-    /// `Place` is the intermedate agent guarding the
+    /// `Place` is the intermediate agent guarding the
     /// uninitialized state for `Data`.
     type Place: InPlace<Data>;
 
diff --git a/text/2580-ptr-meta.md b/text/2580-ptr-meta.md
@@ -21,7 +21,7 @@ but tries to stay compatible with future proposals that do.
 [background]: #background
 
 Typical high-level code doesn’t need to worry about fat pointers,
-a reference `&Foo` “just works” wether or not `Foo` is a DST.
+a reference `&Foo` “just works” whether or not `Foo` is a DST.
 But unsafe code such as a custom collection library may want to access a fat pointer’s
 components separately.
 
diff --git a/text/2603-rust-symbol-name-mangling-v0.md b/text/2603-rust-symbol-name-mangling-v0.md
@@ -623,7 +623,8 @@ Mangled names conform to the following grammar:
 
 ```
 // The <decimal-number> specifies the encoding version.
-<symbol-name> = "_R" [<decimal-number>] <path> [<instantiating-crate>]
+<symbol-name> =
+    "_R" [<decimal-number>] <path> [<instantiating-crate>] [<vendor-specific-suffix>]
 
 <path> = "C" <identifier>                    // crate root
        | "M" <impl-path> <type>              // <T> (inherent impl)
@@ -746,6 +747,10 @@ Mangled names conform to the following grammar:
 // We use <path> here, so that we don't have to add a special rule for
 // compression. In practice, only a crate root is expected.
 <instantiating-crate> = <path>
+
+// There are no restrictions on the characters that may be used
+// in the suffix following the `.` or `$`.
+<vendor-specific-suffix> = ("." | "$") <suffix>
 ```
 
 ### Namespace Tags
@@ -801,6 +806,21 @@ With this post-processing in place the Punycode strings can be treated
 like regular identifiers and need no further special handling.
 
 
+### Vendor-specific suffix
+
+Similarly to the [Itanium C++ ABI mangling scheme][itanium-mangling-structure],
+a symbol name containing a period (`.`) or a dollar sign (`$`) represents a
+vendor-specific version of the symbol. There are no restrictions on the
+characters following the period or dollar sign.
+
+This can happen in practice when locally unique names needed to become globally
+unique. For example, LLVM can append a `.llvm.<numbers>` suffix during LTO to
+ensure a unique name, and `$` can be used for thread-local data on Mach-O. In
+these situations it's generally fine to ignore the suffix: the suffixed name has
+the same semantics as the original.
+
+[itanium-mangling-structure]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-structure
+
 ## Compression
 
 Symbol name compression works by substituting parts of the mangled
@@ -1156,3 +1176,4 @@ pub static QUUX: u32 = {
 - Make `<binder>` optional in `<fn-sig>` and `<dyn-bounds>` productions.
 - Extend `<const-data>` to include `bool` values, `char` values, and negative integer values.
 - Remove type from constant placeholders.
+- Allow vendor-specific suffixes.
diff --git a/text/2795-format-args-implicit-identifiers.md b/text/2795-format-args-implicit-identifiers.md
@@ -146,14 +146,14 @@ The following are motivations why this RFC argues this case:
       4 |     println!(concat!("hello {person}"));
         |              ^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
 
-* The expression may expand to a format string which contains new identifiers not written by the users, bypassing macro hygiene in suprising ways. For example, if the `concat!` macro did not have the hygiene issue described above, it could be to "splice together" an implicit named argument like so:
+* The expression may expand to a format string which contains new identifiers not written by the users, bypassing macro hygiene in surprising ways. For example, if the `concat!` macro did not have the hygiene issue described above, it could be to "splice together" an implicit named argument like so:
 
        let person = "Charlie";
        println!(concat!("hello {p", "er", "son", "}"));
 
    The RFC author argues that it appears highly undesirable that implicit capture of the `person` identifier should occur in this example given above.
 
-* Using the hygienic context of the format string for implicit named arguments can have potentially suprising results even just with `macro_rules!` macros.
+* Using the hygienic context of the format string for implicit named arguments can have potentially surprising results even just with `macro_rules!` macros.
 
   For example, the RFC author found that with a proof-of-concept implementation of implicit named arguments the invocation below would print `"Snoopy"`:
 
diff --git a/text/3139-cargo-alternative-registry-auth.md b/text/3139-cargo-alternative-registry-auth.md
