Don't pass --dynamic-linker for Fuchsia dylibs
This was causing a PT_INTERP header in Fuchsia dylibs (implying that
they're executable when they're not).
r? @Mark-Simulacrum
cc @frobtech @petrhosek
Rustup with git subtree
The commits from the last rustup #5587, are again included in this rustup, since I rebased the rustup. Lesson learned: never rebase, only merge when working with git subtree.
changelog: none
emphasize that ManuallyDrop is safe-to-access and unsafe-to-drop
This seems to sometimes confused people, and generally seems reasonable to state in the top-level summary of the type.
Consistently use LLVM lifetime markers during codegen
Ensure that inliner inserts lifetime markers if they have been emitted during
codegen. Otherwise if allocas from inlined functions are merged together,
lifetime markers from one function might invalidate load & stores performed
by the other one.
Fixes#72154.
Merge some lints together
This PR merges following lints:
- `block_in_if_condition_expr` and `block_in_if_condition_stmt` → `blocks_in_if_conditions`
- `option_map_unwrap_or`, `option_map_unwrap_or_else` and `result_map_unwrap_or_else` → `map_unwrap`
- `option_unwrap_used` and `result_unwrap_used` → `unwrap_used`
- `option_expect_used` and `result_expect_used` → `expect_used`
- `wrong_pub_self_convention` into `wrong_self_convention`
- `for_loop_over_option` and `for_loop_over_result` → `for_loops_over_fallibles`
Lints that have already been merged since the issue was created:
- [x] `new_without_default` and `new_without_default_derive` → `new_without_default`
Need more discussion:
- `string_add` and `string_add_assign`: do we agree to merge them or not? Is there something more to do? → **not merge finally**
- `identity_op` and `modulo_one` → `useless_arithmetic`: seems outdated, since `modulo_arithmetic` has been created.
fixes#1078
changelog: Merging some lints together:
- `block_in_if_condition_expr` and `block_in_if_condition_stmt` → `blocks_in_if_conditions`
- `option_map_unwrap_or`, `option_map_unwrap_or_else` and `result_map_unwrap_or_else` → `map_unwrap_or`
- `option_unwrap_used` and `result_unwrap_used` → `unwrap_used`
- `option_expect_used` and `result_expect_used` → `expect_used`
- `for_loop_over_option` and `for_loop_over_result` → `for_loops_over_fallibles`
Rollup of 5 pull requests
Successful merges:
- #72045 (Incomplete features can also be unsound)
- #72047 (Literal error reporting cleanup)
- #72060 (move `ty::List` into a new submodule)
- #72094 (cmdline: Make target features individually overridable)
- #72254 (Remove redundant backtick in error message.)
Failed merges:
r? @ghost
cmdline: Make target features individually overridable
Fixes https://github.com/rust-lang/rust/issues/56527
Previously `-C target-feature=+avx2 -C target-feature=+fma` was equivalent to `-C target-feature=+fma` because the later `-C target-feature` option fully overridden previous `-C target-feature`.
With this PR `-C target-feature=+avx2 -C target-feature=+fma` is equivalent to `-C target-feature=+avx2,+fma` and the options are combined.
I'm not sure where the comma-separated features in a single option came from (clang uses a scheme with single feature per-option), but logically these features are entirely independent options.
So they should be overridable individually as well to be more useful in hierarchical build system, and more consistent with other rustc options and clang behavior as well.
Target feature options have a few other issues (https://github.com/rust-lang/rust/issues/44815), but fixing those is going to be a bit more invasive.
