Migrate `run-make/override-aliased-flags` to `rmake.rs`
Part of https://github.com/rust-lang/rust/issues/121876.
I voluntarily didn't use the helper methods to make it obvious what's tested.
r? `@jieyouxu`
Migrate `pdb-alt-path`, `mismatching-target-triples` and `mingw-export-call-convention` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Needs MSVC try jobs.
try-job: x86_64-mingw
try-job: x86_64-msvc
Rollup of 9 pull requests
Successful merges:
- #126822 (Bootstrap command refactoring: port more `Command` usages to `BootstrapCmd` (step 2))
- #126835 (Simplifications in match lowering)
- #126953 (std: separate TLS key creation from TLS access)
- #127045 (Rename `super_predicates_of` and similar queries to `explicit_*` to note that they're not elaborated)
- #127075 (rustc_data_structures: Explicitly check for 64-bit atomics support)
- #127101 (remove redundant match statement from dataflow const prop)
- #127102 (Rename fuchsia builder and bump Fuchsia)
- #127103 (Move binder and polarity parsing into `parse_generic_ty_bound`)
- #127108 (unify `dylib` and `bin_helpers` and create `shared_helpers::parse_value_from_args`)
r? `@ghost`
`@rustbot` modify labels: rollup
Move binder and polarity parsing into `parse_generic_ty_bound`
Let's pull out the parts of #127054 which just:
1. Make the parsing code less confusing
2. Fix `?use<>` (to correctly be denied)
3. Improve `T: for<'a> 'a` diagnostics
This should have no user-facing effects on stable parsing.
r? fmease
Migrate `unknown-mod-stdin`, `issue-68794-textrel-on-minimal-lib`, `raw-dylib-cross-compilation` and `used-cdylib-macos` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Seriously needs OSX/Windows try-jobs. If it fails, restore `only-linux` in `textrel-on-minimal-lib` and try again.
try-job: x86_64-mingw
try-job: x86_64-msvc
Rollup of 11 pull requests
Successful merges:
- #123714 (Add test for fn pointer duplication.)
- #124091 (Update AST validation module docs)
- #127015 (Switch back `non_local_definitions` lint to allow-by-default)
- #127016 (docs: check if the disambiguator matches its suffix)
- #127029 (Fix Markdown tables in platform-support.md)
- #127032 (Enable const casting for `f16` and `f128`)
- #127055 (Mark Hasher::finish as #[must_use])
- #127068 (Stall computing instance for drop shim until it has no unsubstituted const params)
- #127070 (add () to the marker_impls macro for ConstParamTy)
- #127071 (Remove (deprecated & unstable) {to,from}_bits pointer methods)
- #127078 (Enable full tools and profiler for LoongArch Linux targets)
r? `@ghost`
`@rustbot` modify labels: rollup
Stall computing instance for drop shim until it has no unsubstituted const params
Do not inline the drop shim for types that still have unsubstituted const params.
## Why?
#127030 ICEs because it tries to inline the drop shim for a type with an unsubstituted const param. In order to generate this shim, this requires calling the drop shim builder, which invokes the trait solver to compute whether constituent types need drop (since we compute if a type is copy to disqualify any `Drop` behavior):
9c3bc805dd/compiler/rustc_mir_dataflow/src/elaborate_drops.rs (L378)
However, since we don't keep the param-env of the instance we resolved the item for, we use the wrong param-env:
9c3bc805dd/compiler/rustc_mir_transform/src/shim.rs (L278)
(which is the param-env of `std::ptr::drop_in_place`)
This param-env is notably missing `ConstParamHasTy` predicates, and since we removed the type from consts in https://github.com/rust-lang/rust/pull/125958, we literally cannot prove these predicates in this (relatively) empty param-env. This currently happens in places like the MIR inliner, but may happen elsewhere such as in lints that resolve terminators.
## What?
We force the inliner to not consider calls for `drop_in_place` for types that have unsubstituted const params.
## So what?
This may negatively affect MIR inlining, but I doubt this matters in practice, and fixes a beta regression, so let's fix it. I will look into approaches for fixing this in a more maintainable way, perhaps delaying the creation of drop shim bodies until codegen (like how intrinsics work).
docs: check if the disambiguator matches its suffix
Fixes#126986
This PR makes it will not continue resolving when its disambiguator doesn't match the suffix format.
Switch back `non_local_definitions` lint to allow-by-default
This PR switch back (again) the `non_local_definitions` lint to allow-by-default as T-lang is requesting some (major) changes in the lint inner workings in https://github.com/rust-lang/rust/issues/126768#issuecomment-2192634762.
This PR will need to be beta-backported, as the lint is currently warn-by-default in beta.
ignore `llvm::Lld` if lld is not enabled
People are having trouble ([ref. zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/MSVC.20Runtime.20mismatch.20when.20building.20LLD)) when they don't want to build `lld` for their custom distribution tarballs even with `lld = false` in their config.toml. This is because it is not controlled by `lld_enabled` flag. This change ensures that `llvm:Lld` is controlled by lld configuration.
Additionally, `lld = true` is set by default for dist profile, because we have been building it all along and this maintains that behavior.
try-job: x86_64-mingw
Tighten `fn_decl_span` for async blocks
Tightens the span of `async {}` blocks in diagnostics, and subsequently async closures and async fns, by actually setting the `fn_decl_span` correctly. This is kinda a follow-up on #125078, but it fixes the problem in a more general way.
I think the diagnostics are significantly improved, since we no longer have a bunch of overlapping spans. I'll point out one caveat where I think the diagnostic may get a bit more confusing, but where I don't think it matters.
r? ````@estebank```` or ````@oli-obk```` or someone else on wg-diag or compiler i dont really care lol
Support fetching `Attribute` of items.
Fixes [https://github.com/rust-lang/project-stable-mir/issues/83](https://github.com/rust-lang/project-stable-mir/issues/83)
`rustc_ast::ast::Attribute` doesn't impl `Hash` and `Eq`. Thus it cannot be directly used as key of `IndexMap` in `rustc_smir::rustc_smir::Tables` and we cannot define stable `Attribute` as index to `rustc_ast::ast::Attribute` like `Span` and many other stable definitions.
Since an string (or tokens) and its span contain all info about an attribute, I defined a simple `Attribute` struct on stable side.
I choose to fetch attributes via `tcx::get_attrs_by_path()` due to `get_attrs()` is marked as deprecated and `get_attrs_by_name()` cannot handle name of multiple segments like `rustfmt::skip`.
r? `@celinval`
core: avoid `extern type`s in formatting infrastructure
```@RalfJung``` [said](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Use.20of.20.60extern.20type.60.20in.20formatting.20machinery/near/446552837):
>How attached are y'all to using `extern type` in the formatting machinery?
Seems like this was introduced a [long time ago](34ef8f5441). However, it's also [not really compatible with Stacked Borrows](https://github.com/rust-lang/unsafe-code-guidelines/issues/256), and only works currently because we effectively treat references-to-extern-type almost like raw pointers in Stacked Borrows -- which of course is unsound, it's not how LLVM works. I was planning to make Miri emit a warning when this happens to avoid cases like [this](https://github.com/rust-lang/rust/issues/126814#issuecomment-2183816373) where people use extern type specifically to silence Miri without realizing what happens. but with the formatting machinery using extern type, this warning would just show up everywhere...
>
> The "proper" way to do this in Stacked Borrows is to use raw pointers (or `NonNull`).
This PR does just that.
r? ```@RalfJung```
patchable-function-entry: Add unstable compiler flag and attribute
Tracking issue: #123115
Add the -Z patchable-function-entry compiler flag and the #[patchable_function_entry(prefix_nops = m, entry_nops = n)] attribute.
Rebased and adjusted the canditate implementation to match changes in the RFC.
ast: Standardize visiting order
Order: ID, attributes, inner nodes in source order if possible, tokens, span.
Also always use exhaustive matching in visiting infra, and visit some discovered missing nodes.
Unlike https://github.com/rust-lang/rust/pull/125741 this shouldn't affect anything serious like `macro_rules` scopes.
Remove `__rust_force_expr`.
This was added (with a different name) to improve an error message. It is no longer needed -- removing it changes the error message, but overall I think the new message is no worse:
- the mention of `#` in the first line is a little worse,
- but the extra context makes it very clear what the problem is, perhaps even clearer than the old message,
- and the removal of the note about the `expr` fragment (an internal detail of `__rust_force_expr`) is an improvement.
Overall I think the error is quite clear and still far better than the old message that prompted #61933, which didn't even mention patterns.
The motivation for this is #124141, which will cause pasted metavariables to be tokenized and reparsed instead of the AST node being cached. This change in behaviour occasionally has a non-zero perf cost, and `__rust_force_expr` causes the tokenize/reparse step to occur twice. Removing `__rust_force_expr` greatly reduces the extra overhead for the `deep-vector` benchmark.
r? ```@oli-obk```
bors