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.
move `ty::List` into a new submodule
`rustc_middle/ty` is currently right below the 3000 lines tidy file length limit.
Moves `rustc_middle::ty::List` to the private module `rustc_middle::ty::list` and adds
a `pub use self::list::List` at its previous location.
Literal error reporting cleanup
While doing some performance work, I noticed some code duplication in `librustc_parser/lexer/mod.rs`, so I cleaned it up.
This PR is probably best reviewed commit by commit.
I'm not sure what the API stability practices for `librustc_lexer` are. Four public methods in `unescape.rs` can be removed, but two are used by clippy, so I left them in for now.
I could open a PR for Rust-Analyzer when this one lands.
But how do I open a PR for clippy? (Git submodules are frustrating to work with)
Literal error reporting cleanup
While doing some performance work, I noticed some code duplication in `librustc_parser/lexer/mod.rs`, so I cleaned it up.
This PR is probably best reviewed commit by commit.
I'm not sure what the API stability practices for `librustc_lexer` are. Four public methods in `unescape.rs` can be removed, but two are used by clippy, so I left them in for now.
I could open a PR for Rust-Analyzer when this one lands.
But how do I open a PR for clippy? (Git submodules are frustrating to work with)
Incomplete features can also be unsound
Some incomplete features do not just ICE, they are also currently unsound (e.g. https://github.com/rust-lang/rust/pull/72029, and also `specialization` -- which is not yet marked incomplete but [should be](https://github.com/rust-lang/rust/pull/71420)). This makes the message reflect that.
While at it I also added a link to the tracking issue, which hopefully should explain what is incomplete/unsound about the feature.
This way the hir is "valid" and we can remove one more call to
`opt_node_id_to_hir_id` but an error is still emitted.
This is another partial fix for #71104
Implement Default for proc_macro::TokenStream
Hopefully this is uncontroversial. The only reason we've made it this far without is that proc-macro2 snuck this in for their TokenStream.
Updated documentation of Prefix::VerbatimDisk
PrefixComponent with Prefix::VerbatimDisk does not contain the trailing slash. The documentation here is also inconsistent with the documentation on other variants that reflect the `PrefixComponent::as_os_str()` return value.
Remove `lang_items\(\).*\.unwrap\(\)`
Follows up #72170 to remove the remaining uses of `lang_items\(\).*\.unwrap\(\)` (avoids a bunch of potential ICEs when working in `#![no_core]`).
Resolves#72195
Be less aggressive with `DroplessArena`/`TypedArena` growth.
`DroplessArena` and `TypedArena` use an aggressive growth strategy: the first chunk is 4 KiB, the second is 8 KiB, and it keeps on doubling indefinitely. DHAT profiles show that sometimes this results in large chunks (e.g. 16-128 MiB) that are barely filled.
This commit changes things so that the doubling stops at 2 MiB. This is large enough that chunk allocations are still rare (you might get 100s instead of 10s of them) but avoids lots of unused space in the worst case. It makes the same change to `TypedArena`, too.
