Update comments

Author: bjorn3

compiler/rustc_codegen_ssa/src/back/linker.rs

@@ -1882,11 +1882,11 @@ pub(crate) fn linked_symbols(
             // We really only need symbols from upstream rlibs to end up in the linked symbols list.
             // The rest are in separate object files which the linker will always link in and
             // doesn't have rules around the order in which they need to appear.
-            // When doing LTO, some of the symbols in the linked symbols list may end up getting
-            // internalized, which then prevents referencing them from symbols.o. When doing LTO,
-            // all object files that get linked in will be local object files rather than pulled in
-            // from rlibs, so an empty linked symbols list works fine to avoid referencing all those
-            // internalized symbols from symbols.o.
+            // When doing LTO, some of the symbols in the linked symbols list happen to be
+            // internalized by LTO, which then prevents referencing them from symbols.o. When doing
+            // LTO, all object files that get linked in will be local object files rather than
+            // pulled in from rlibs, so an empty linked symbols list works fine to avoid referencing
+            // all those internalized symbols from symbols.o.
             return Vec::new();
         }
     }

compiler/rustc_middle/src/middle/exported_symbols.rs

@@ -31,6 +31,9 @@ pub enum SymbolExportKind {
 
 /// The `SymbolExportInfo` of a symbols specifies symbol-related information
 /// that is relevant to code generation and linking.
+///
+/// The difference between `used` and `rustc_std_internal_symbol` is that the
+/// former is exported by LTO while the latter isn't.
 #[derive(Eq, PartialEq, Debug, Copy, Clone, TyEncodable, TyDecodable, HashStable)]
 pub struct SymbolExportInfo {
     pub level: SymbolExportLevel,