@@ -369,12 +369,12 @@ pub fn target_cpu(sess: &Session) -> &str {
369369/// The list of LLVM features computed from CLI flags (`-Ctarget-cpu`, `-Ctarget-feature`, 
370370/// `--target` and similar). 
371371pub ( crate )  fn  global_llvm_features ( sess :  & Session ,  diagnostics :  bool )  -> Vec < String >  { 
372-     // Features that come earlier are overriden  by conflicting features later in the string. 
372+     // Features that come earlier are overridden  by conflicting features later in the string. 
373373    // Typically we'll want more explicit settings to override the implicit ones, so: 
374374    // 
375-     // * Features from -Ctarget-cpu=*; are overriden  by [^1] 
376-     // * Features implied by --target; are overriden  by 
377-     // * Features from -Ctarget-feature; are overriden  by 
375+     // * Features from -Ctarget-cpu=*; are overridden  by [^1] 
376+     // * Features implied by --target; are overridden  by 
377+     // * Features from -Ctarget-feature; are overridden  by 
378378    // * function specific features. 
379379    // 
380380    // [^1]: target-cpu=native is handled here, other target-cpu values are handled implicitly 
@@ -383,7 +383,7 @@ pub(crate) fn global_llvm_features(sess: &Session, diagnostics: bool) -> Vec<Str
383383    // FIXME(nagisa): it isn't clear what's the best interaction between features implied by 
384384    // `-Ctarget-cpu` and `--target` are. On one hand, you'd expect CLI arguments to always 
385385    // override anything that's implicit, so e.g. when there's no `--target` flag, features implied 
386-     // the host target are overriden  by `-Ctarget-cpu=*`. On the other hand, what about when both 
386+     // the host target are overridden  by `-Ctarget-cpu=*`. On the other hand, what about when both 
387387    // `--target` and `-Ctarget-cpu=*` are specified? Both then imply some target features and both 
388388    // flags are specified by the user on the CLI. It isn't as clear-cut which order of precedence 
389389    // should be taken in cases like these. 
0 commit comments