The lint definitions use macros heavily. This commit merges some of them
that are split unnecessarily. I find the reduced indirection makes it
easier to imagine what the generated code will look like.
Lower them into a single item with multiple resolutions instead.
This also allows to remove additional `NodId`s and `DefId`s related to those additional items.
`#![custom_mir]`: Various improvements
This PR makes a bunch of improvements to `#![custom_mir]`. Ideally this would be 4 PRs, one for each commit, but those would take forever to get merged and be a pain to juggle. Should still be reviewed one commit at a time though.
### Commit 1: Support arbitrary `let`
Before this change, all locals used in the body need to be declared at the top of the `mir!` invocation, which is rather annoying. We attempt to change that.
Unfortunately, we still have the requirement that the output of the `mir!` macro must resolve, typecheck, etc. Because of that, we can't just accept this in the THIR -> MIR parser because something like
```rust
{
let x = 0;
Goto(other)
}
other = {
RET = x;
Return()
}
```
will fail to resolve. Instead, the implementation does macro shenanigans to find the let declarations and extract them as part of the `mir!` macro. That *works*, but it is fairly complicated and degrades debuginfo by quite a bit. Specifically, the spans for any statements and declarations that are affected by this are completely wrong. My guess is that this is a net improvement though.
One way to recover some of the debuginfo would be to not support type annotations in the `let` statements, which would allow us to parse like `let $stmt:stmt`. That seems quite surprising though.
### Commit 2: Parse consts
Reuses most of the const parsing from regular Mir building for building custom mir
### Commit 3: Parse statics
Statics are slightly weird because the Mir primitive associated with them is a reference/pointer to them, so this is factored out separately.
### Commit 4: Fix some spans
A bunch of the spans were non-ideal, so we adjust them to be much more helpful.
r? `@oli-obk`
This makes sure that ICEing because of def ids created outside of ast lowering will be able to produce a query backtrace and not cause a double panic because of trying to call the `def_span` query
Rollup of 9 pull requests
Successful merges:
- #103065 (rustdoc-json: Document and Test that args can be patterns.)
- #104865 (Don't overwrite local changes when updating submodules)
- #104895 (Avoid Invalid code suggested when encountering unsatisfied trait bounds in derive macro code)
- #105063 (Rustdoc Json Tests: Don't assume that core::fmt::Debug will always have one item.)
- #105064 (rustdoc: add comment to confusing CSS `main { min-width: 0 }`)
- #105074 (Add Nicholas Bishop to `.mailmap`)
- #105081 (Add a regression test for #104322)
- #105086 (rustdoc: clean up sidebar link CSS)
- #105091 (add Tshepang Mbambo to .mailmap)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Async lowering turns async functions and blocks into generators internally.
Though these special kinds of generators should not `impl Generator` themselves.
The other way around, normal generators should not `impl Future`.
Allow to feed a value in another query's cache
Restricted version of https://github.com/rust-lang/rust/pull/96840
A query can create new definitions.
If those definitions are created after HIR lowering, they do not appear in the initial HIR map, and information for them cannot be provided in the normal pull-based way.
In order to make those definitions useful, we allow to feed values as query results for the newly created definition.
The API is as follows:
```rust
let feed = tcx.create_def(<parent def id>, <DefPathData>);
// `feed` is a TyCtxtFeed<'tcx>.
// Access the created definition.
let def_id: LocalDefId = feed.def_id;
// Assign `my_query(def_id) := my_value`.
feed.my_query(my_value).
```
This PR keeps the consistency checks introduced by https://github.com/rust-lang/rust/pull/96840, even if they are not reachable. This allows to extend the behaviour later without forgetting them.
cc `@oli-obk` `@spastorino`
fix universe map in ifcx.instantiate_canonical_*
Previously, `infcx.instantiate_canonical_*` maps the root universe in `canonical` into `ty::UniverseIndex::Root`, I think because it assumes it works with a fresh `infcx` but this is not true for the use cases in mir typeck. Now the root universe is mapped into `infcx.universe()`.
I catched this accidentally while reviewing the code. I'm not sure if this is the right fix or if it is really a bug!
Some initial normalization method changes
1. Rename `AtExt::normalize` to `QueryNormalizeExt::query_normalize` (using the `QueryNormalizer`)
2. Introduce `NormalizeExt::normalize` to replace `partially_normalize_associated_types_in` (using the `AssocTypeNormalizer`)
3. Rename `FnCtxt::normalize_associated_types_in` to `FnCtxt::normalize`
4. Remove some unused other normalization fns in `Inherited` and `FnCtxt`
Also includes one drive-by where we're no longer creating a `FnCtxt` inside of `check_fn`, but passing it in. This means we don't need such weird `FnCtxt` construction logic.
Stacked on top of #104835 for convenience.
r? types
Rollup of 5 pull requests
Successful merges:
- #104697 (Restore control flow on error in EUV)
- #104811 (feat: implement TcpStream shutdown for wasm32-wasi)
- #105039 (Fix an ICE parsing a malformed literal in `concat_bytes!`.)
- #105071 (Add Nicholas Nethercote to `.mailmap`.)
- #105079 (Add bots to `.mailmap`)
Failed merges:
- #105074 (Add Nicholas Bishop to `.mailmap`)
r? `@ghost`
`@rustbot` modify labels: rollup
Restore control flow on error in EUV
cc `@Nilstrieb`
Fix#104649
Since #98574 refactored a piece of scrutinee memory categorization out as a subroutine, there is a subtle change in handling match arms especially when the categorization process faults and bails. In the correct case, it is not supposed to continue to process the arms any more. This PR restores the original control flow in EUV.
I promise to add a compile-fail test to demonstrate that this indeed fixes the issue after coming back from a nap.
codegen-llvm: never combine DSOLocal and DllImport
Prevent DllImport from being attached to DSOLocal definitions in the LLVM IR. The combination makes no sense, since definitions local to the compilation unit will never be imported from external objects.
Additionally, LLVM will refuse the IR if it encounters the combination (introduced in [1]):
```
if (GV.hasDLLImportStorageClass())
Assert(!GV.isDSOLocal(),
"GlobalValue with DLLImport Storage is dso_local!", &GV);
```
Right now, codegen-llvm will only apply DllImport to constants and rely on call-stubs for functions. Hence, we simply extend the codegen of constants to skip DllImport for any local definitions.
This was discovered when switching the EFI targets to the static relocation model [2]. With this fixed, we can start another attempt at this.
[1] 509132b368
[2] https://github.com/rust-lang/rust/issues/101656
Rollup of 14 pull requests
Successful merges:
- #103876 (type alias impl trait: add tests showing that hidden type only outlives lifetimes that occur in bounds)
- #104427 (Explain why `rematch_impl` fails to be infallible)
- #104436 (Add slice to the stack allocated string comment)
- #104523 (Don't use periods in target names)
- #104627 (Print all features with --print target-features)
- #104911 (Make inferred_outlives_crate return Clause)
- #105002 (Add `PathBuf::as_mut_os_string` and `Path::as_mut_os_str`)
- #105023 (Statics used in reachable function's inline asm are reachable)
- #105045 (`rustc_ast_{passes,pretty}`: remove `ref` patterns)
- #105049 (Hermit: Minor build fixes)
- #105051 (Replace a macro with a function)
- #105062 (rustdoc: use shorthand background for rustdoc toggle CSS)
- #105066 (move `candidate_from_obligation` out of assembly)
- #105068 (Run patchelf also on rust-analyzer-proc-macro-srv.)
Failed merges:
- #105050 (Remove useless borrows and derefs)
r? `@ghost`
`@rustbot` modify labels: rollup
Print all features with --print target-features
This fixes `rustc --print target-features` with respect to aliases and tied features.
Before this change, the print command assumed that each LLVM feature corresponds exactly to one rustc feature. In the case of aliases and tied features, this assumption failed and some features (such as aarch64's "pacg") were missing. With this change, every target feature is listed.
type alias impl trait: add tests showing that hidden type only outlives lifetimes that occur in bounds
fixes#103642https://github.com/rust-lang/rust/pull/102417 only made sure that hidden types cannot outlive lifetimes other than the ones mentioned on bounds, but didn't allow us to actually infer anything from that.
cc `@aliemjay`
Also cache the stable hash of interned Predicates
continuation of https://github.com/rust-lang/rust/pull/94299
This is a small perf improvement and shares more code between `Ty` and `Predicate`
Prevent DllImport from being attached to DSOLocal definitions in the
LLVM IR. The combination makes no sense, since definitions local to the
compilation unit will never be imported from external objects.
Additionally, LLVM will refuse the IR if it encounters the
combination (introduced in [1]):
if (GV.hasDLLImportStorageClass())
Assert(!GV.isDSOLocal(),
"GlobalValue with DLLImport Storage is dso_local!", &GV);
Right now, codegen-llvm will only apply DllImport to constants and rely
on call-stubs for functions. Hence, we simply extend the codegen of
constants to skip DllImport for any local definitions.
This was discovered when switching the EFI targets to the static
relocation model [2]. With this fixed, we can start another attempt at
this.
[1] 509132b368
[2] https://github.com/rust-lang/rust/issues/101656
There is code for converting `Attribute` (syntactic) to `MetaItem`
(semantic). There is also code for the reverse direction. The reverse
direction isn't really necessary; it's currently only used when
generating attributes, e.g. in `derive` code.
This commit adds some new functions for creating `Attributes`s directly,
without involving `MetaItem`s: `mk_attr_word`, `mk_attr_name_value_str`,
`mk_attr_nested_word`, and
`ExtCtxt::attr_{word,name_value_str,nested_word}`.
These new methods replace the old functions for creating `Attribute`s:
`mk_attr_inner`, `mk_attr_outer`, and `ExtCtxt::attribute`. Those
functions took `MetaItem`s as input, and relied on many other functions
that created `MetaItems`, which are also removed: `mk_name_value_item`,
`mk_list_item`, `mk_word_item`, `mk_nested_word_item`,
`{MetaItem,MetaItemKind,NestedMetaItem}::token_trees`,
`MetaItemKind::attr_args`, `MetaItemLit::{from_lit_kind,to_token}`,
`ExtCtxt::meta_word`.
Overall this cuts more than 100 lines of code and makes thing simpler.
After https://github.com/llvm/llvm-project/commit/8689f5e landed, LLVM takes the intersection of v8a and v8r as default.
This commit brings back v8a support by explicitly specifying v8a in the feature list.
This should solve #97724.
Clean up pr 104954
UI test filename typo fix and a simple comment rewording. Thanks.
CC `@vincenzopalazzo` (you spelled your name wrongly in the FIXME)
r? `@estebank`
Revert #104269 (to avoid spurious hang/test failure in CI)
Causes hangs/memory overflows in the test suite apparently 😢Reopens#104225Fixes#104957
r? ``@lcnr``
In `Expander::expand` the code currently uses `mk_attr_outer` to convert
a `MetaItem` to an `Attribute`, and then follows that with
`meta_item_list` which converts back. This commit avoids the unnecessary
conversions.
There was one wrinkle: the existing conversions caused the bogus `<>` on
`Default<>` to be removed. With the conversion gone, we get a second
error message about the `<>`. This is a rare case, so I think it
probably doesn't matter much.
`check_builtin_attribute` calls `parse_meta` to convert an `Attribute`
to a `MetaItem`, which it then checks. However, many callers of
`check_builtin_attribute` start with a `MetaItem`, and then convert it
to an `Attribute` by calling `cx.attribute(meta_item)`. This `MetaItem`
to `Attribute` to `MetaItem` conversion is silly.
This commit adds a new function `check_builtin_meta_item`, which can be
called instead from these call sites. `check_builtin_attribute` also now
calls it. The commit also renames `check_meta` as `check_attr` to better
match its arguments.
`mk_const(ty::ConstKind::X(...), ty)` can now be simplified to
`mk_cosnt(..., ty)`.
I searched with the following regex: \mk_const\([\n\s]*(ty::)?ConstKind\
I've left `ty::ConstKind::{Bound, Error}` as-is, they seem clearer this
way.
- Accept `impl Into`
- Implement `From<>` for `ConstKind`
Note: this adds a dependency on `derive_more` (MIT license). It allows
to derive a lot of traits (like `From` here) that would be otherwise
tedious to implement.
stricter alignment enforcement for ScalarPair
`@eddyb` [indicated](https://github.com/rust-lang/rust/pull/103926#discussion_r1033315005) that alignment violating this check might be a bug. So let's see what the test suite says.
(Only the 2nd commit actually changes behavior... but I couldn't not do that other cleanup.^^)
Does the PR CI runner even enable debug assertions though...?
make simple check of prinf function
Fixes https://github.com/rust-lang/rust/issues/92898
With this commit we start to make some simple
check when the name resolution fails, and
we generate some helper messages in case the
name is a C name like in the case of the `printf`
and suggest the correct rust method.
`@rustbot` r? `@pnkfelix`
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Ignore bivariant parameters in test_type_match.
https://github.com/rust-lang/rust/pull/103491 made opaque types bivariant with respect of some of their lifetime parameters. Because of this bivariance, some lifetime variables were not unified to anything during borrowck, and were considered as unequal by borrowck type test.
This PR makes type test ignore the bivariant parameters in test_type_match.
Fixes https://github.com/rust-lang/rust/issues/104815
r? `@oli-obk`
Add documentation for `has_escaping_bound_vars`
Thanks to `@BoxyUwU` for explaining this to me. Adding docs with a helpful link if people get confused.
Remove `SelectionContext::infcx()` in favor of field access
Encapsulation doesn't seem particularly important here, and having two choices is always more confusing than having one.
r? types
Change multiline span ASCII art visual order
Tweak the ASCII art for nested multiline spans so that we minimize line overlaps.
Partially addresses https://github.com/rust-lang/rust/issues/61017.
`Lit::from_included_bytes` calls `Lit::from_lit_kind`, but the two call
sites only need the resulting `token::Lit`, not the full `ast::Lit`.
This commit changes those call sites to use `LitKind::to_token_lit`,
which means `from_included_bytes` can be removed.
Prefer doc comments over `//`-comments in compiler
Doc comments are generally nicer: they show up in the documentation, they are shown in IDEs when you hover other mentions of items, etc. Thus it makes sense to use them instead of `//`-comments.
Rollup of 8 pull requests
Successful merges:
- #95836 (Use `rust_out{exe_suffix}` for doctests)
- #104882 (notify lcnr on changes to `ObligationCtxt`)
- #104892 (Explain how to get the discriminant out of a `#[repr(T)] enum` with payload)
- #104917 (Allow non-org members to label `requires-debug-assertions`)
- #104931 (Pretty-print generators with their `generator_kind`)
- #104934 (Remove redundant `all` in cfg)
- #104944 (Support unit tests for jsondoclint)
- #104946 (rustdoc: improve popover focus handling JS)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove redundant `all` in cfg
This appears to have been accidentally left in after removing the other branches 45bf1ed1a1
(hat tip to kangalioo for the git archaeology)
Pretty-print generators with their `generator_kind`
After removing `GenFuture`, I special-cased async generators to pretty-print as `impl Future<Output = X>` mainly to avoid too much diagnostics changes originally.
This now reverses that change so that async fn/blocks are pretty-printed as `[$async-type@$source-position]` in various diagnostics, and updates the tests that this touches.
Separate lifetime ident from lifetime resolution in HIR
Drive-by: change how suggested generic args are computed.
Fixes https://github.com/rust-lang/rust/issues/103815
I recommend reviewing commit-by-commit.
With this commit we start to make some simple
check when the name resolution fails, and
we generate some helper message in case the
name is a C name like in the case of the `printf`
and suggest the correct rust method.
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
This fixes a number of correctness issues from the previous version. Additionally, we use a new
strategy which has much better performance charactersitics and also finds more opportunities to
apply the optimization.
After removing `GenFuture`, I special-cased async generators to pretty-print as `impl Future<Output = X>` mainly to avoid too much diagnostics changes originally.
This now reverses that change so that async fn/blocks are pretty-printed as `[$movability `async` $something@$source-position]` in various diagnostics, and updates the tests that this touches.
Rollup of 7 pull requests
Successful merges:
- #104786 (Use the power of adding helper function to simplify code w/ `Mutability`)
- #104788 (Do not record unresolved const vars in generator interior)
- #104909 (Rename `normalize_opaque_types` to `reveal_opaque_types_in_bounds`)
- #104921 (Remove unnecessary binder from `get_impl_future_output_ty`)
- #104924 (jsondoclint: Accept trait alias is places where trait expected.)
- #104928 (rustdoc: use flexbox CSS to align sidebar button instead of position)
- #104943 (jsondoclint: Handle using enum variants and glob using enums.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove unnecessary binder from `get_impl_future_output_ty`
We never construct an `async fn` with a higher-ranked `impl Future` bound anyways, and basically all the call-sites already skip the binder.
Rename `normalize_opaque_types` to `reveal_opaque_types_in_bounds`
1. The query name is a bit misleading, since it doesn't do any associated type normalization, and
2. since it only takes a predicate list, it sounds a bit more powerful than it actually is.
Do not record unresolved const vars in generator interior
Don't record types in the generator interior when we see unresolved const variables.
We already do this for associated types -- this is important to avoid unresolved inference variables in the generator results during writeback, since the writeback results get stable hashed in incremental mode.
Fixes#104787
Remove AscribeUserTypeCx
r? ``@compiler-errors``
This basically inlines `AscribeUserTypeCx::relate_mir_and_user_ty` into `type_op_ascribe_user_type_with_span` which is the only place where it's used and makes direct use of `ObligationCtxt` API.
Unsupported query error now specifies if its unsupported for local or external crate
Fixes#101666.
I had to move `keys.rs` from `rustc_query_impl` to `rustc_middle`. I don't know if that is problematic. I couldn't think of any other way to get the needed information inside `rustc_middle`.
r? ```@jyn514```
Refine `instruction_set` MIR inline rules
Previously an exact match of the `instruction_set` attribute was required for an MIR inline to be considered. This change checks for an exact match *only* if the callee sets an `instruction_set` in the first place. When the callee does not declare an instruction set then it is considered to be platform agnostic code and it's allowed to be inline'd into the caller.
cc ``@oli-obk``
[Edit] Zulip Context: https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/What.20exactly.20does.20the.20MIR.20optimizer.20do.3F
Manually implement PartialEq for Option<T> and specialize non-nullable types
This PR manually implements `PartialEq` and `StructuralPartialEq` for `Option`, which seems to produce slightly better codegen than the automatically derived implementation.
It also allows specializing on the `core::num::NonZero*` and `core::ptr::NonNull` types, taking advantage of the niche optimization by transmuting the `Option<T>` to `T` to be compared directly, which can be done in just two instructions.
A comparison of the original, new and specialized code generation is available [here](https://godbolt.org/z/dE4jxdYsa).
Add `ConstKind::Expr`
Starting to implement `ty::ConstKind::Abstract`, most of the match cases are stubbed out, some I was unsure what to add, others I didn't want to add until a more complete implementation was ready.
r? `@lcnr`
Previously an exact match of the `instruction_set` attribute was required for an MIR inline to be considered. This change checks for an exact match *only* if the callee sets an `instruction_set` in the first place. When the callee does not declare an instruction set then it is considered to be platform agnostic code and it's allowed to be inline'd into the caller.
rustc_codegen_ssa: write `.dwp` in a streaming fashion
When writing a `.dwp` file, rustc writes to a Vec first then to a BufWriter-wrapped file. It seems very likely that we can write in a streaming fashion to avoid double buffering in an intermediate Vec.
On my Linux machine, `.dwp` from the latest rust-lang/cargo is 113MiB. It may worth a stream writer, though I didn't do any benchmark 🙇🏾♂️.
