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).
Enable const casting for `f16` and `f128`
I have an open PR to the Miri repo adding tests for this behavior https://github.com/rust-lang/miri/pull/3688, but that unfortunately hits the ICE path here. The changes seem reasonably low risk that it might be okay to merge separately from the tests, and I tested the result locally against an older version of https://github.com/rust-lang/miri/pull/3688.
Cc ``````@RalfJung``````
Fix Markdown tables in platform-support.md
These table entries have wrong number of columns so the "notes" field is missing from the rendered page. Fix by removing excess empty columns.
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.
Update AST validation module docs
Drive-by doc update for AST validation pass:
- Syntax extensions are replaced by proc macros.
- Add rationale for why AST validation pass need to be run
post-expansion and why the pass is needed in the first place.
This was discussed during this week's [rustc-dev-guide reading club](https://rust-lang.zulipchat.com/#narrow/stream/196385-t-compiler.2Fwg-rustc-dev-guide), and the rationale was explained by cc ``````@bjorn3.``````
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.
bump strip-ansi-escapes
This bumps `strip-ansi-escapes` to remove arrayvec from it's deps (https://github.com/luser/strip-ansi-escapes/pull/8)
Should Cargo.lock be commited too to track it's working state?
changelog: none
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.
Currently bootstrap doesn't use any inner paths from rust-analyzer and
bootstrap with `ShouldRun::create_or_deps`.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Fix doc_markdown DevOps false positive
This fixes an issue where the word "DevOps" ends up as a false positive for the `doc_markdown` lint.
In a doc comment like this
```rust
/// Call the Azure DevOps REST API.
pub fn example() {}
```
the word "DevOps" is highlighted as something which should be in backticks.
```
warning: item in documentation is missing backticks
--> src/lib.rs:1:20
|
1 | /// Call the Azure DevOps REST API.
| ^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#doc_markdown
= note: requested on the command line with `-W clippy::doc-markdown`
help: try
|
1 | /// Call the Azure `DevOps` REST API.
| ~~~~~~~~
warning: `example` (lib) generated 1 warning (run `cargo clippy --fix --lib -p example` to apply 1 suggestion)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.00s
```
This could be overriden with the `doc-valid-idents` configuration parameter as noted by the [documentation](https://rust-lang.github.io/rust-clippy/master/index.html#/doc_markdown), but I believe the word "DevOps" is sufficiently common to belong alongside exceptions like "GitHub" and "GitLab".
changelog: [`doc_markdown`]: Fix DevOps false positive.
rustdoc: use current stage if download-rustc enabled
When using download-rustc, using stage 1 rustdoc results in the wrong librustc_driver being used.
```sh
$ ./build/host/stage1/bin/rustdoc --version
./build/host/stage1/bin/rustdoc: error while loading shared libraries: librustc_driver-7ff02ed05016d515.so: cannot open shared object file: No such file or directory
```
This change fixes that by not cutting the stage if download-rustc is enabled.
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```
coverage: Make `#[coverage(..)]` apply recursively to nested functions
This PR makes the (currently-unstable) `#[coverage(off)]` and `#[coverage(on)]` attributes apply recursively to all nested functions/closures, instead of just the function they are directly attached to.
Those attributes can now also be applied to modules and to impl/impl-trait blocks, where they have no direct effect, but will be inherited by all enclosed functions/closures/methods that don't override the inherited value.
---
Fixes#126625.
