Don't require owned data in `MaybeStorageLive`
Small improvement that avoids a clone. I don't expect this to have any noticeable perf effects, but better to have it than not to.
r? ``@tmiasko``
Change pattern borrowing suggestions to be verbose and remove invalid suggestion
Synthesize a more accurate span and use verbose suggestion output to
make the message clearer.
Do not suggest borrowing binding in pattern in let else. Fix#104838.
Move some codegen-y methods from `rustc_hir_analysis::collect` -> `rustc_codegen_ssa`
Unclear if they should live here, but they seem codegen-y enough, and `rustc_hir_analysis::collect` is extremely long, so it should probably lose some methods.
Allow unsafe through inline const
Handle similar to closures.
Address https://github.com/rust-lang/rust/pull/104087#issuecomment-1324173328
Note that this PR does not fix the issue for `unsafe { [0; function_requiring_unsafe()] }`. This is fundamentally unfixable for MIR unsafeck IMO.
This PR also does not fix unsafety checking for inline const in pattern position. It actually breaks it, allowing unsafe functions to be used in inline const in pattern position without unsafe blocks. Inline const in pattern position is not visible in MIR so ignored by MIR unsafety checking (currently it is also not checked by borrow checker, which is the reason why it's considered an incomplete feature).
`@rustbot` label: +T-lang +F-inline_const
Simpler diagnostic when passing arg to closure and missing borrow
fixes#64915
I followed roughly the instructions and the older PR #76362.
The number of references for the expected and the found types will be compared and depending on which has more the diagnostic will be emitted.
I'm not quite sure if my approach with the many `span_bug!`s is good, it could lead to some ICEs. Would it be better if those errors are ignored?
As far as I know the following code works similarly but in a different context. Is this probably reusable since it looks like it would emit better diagnostics?
a688a0305f/compiler/rustc_hir_analysis/src/check/demand.rs (L713-L1061)
When running the tests locally, a codegen test failed. Is there something I can/ should do about that?
If you have some improvements/ corrections please say so and I will happily include them.
r? `@estebank` (as you added the mentoring instructions to the issue)
Remove previously existing fallback that tried to give a good turbofish
suggestion, `need_type_info` is already good enough.
Special case `::<Vec<_>` suggestion for `Iterator::collect`.
use ty::Binder in rustdoc instead of `skip_binder`
r? `@GuillaumeGomez`
this is a preliminary cleanup required to be able to normalize correctly/conveniently in rustdoc
If we have a call such as `foo(&mut buf)` and after reference
collapsing the type is inferred as `&T` where-as the required type is
`&mut T`, don't suggest `foo(&mut mut buf)`. This is wrong syntactically
and the issue lies elsewhere, not in the borrow.
Fixes#105645
Fix cases where the "invalid base prefix for number literal" error arises with
suffixes that look erroneously capitalized but which are in fact invalid.
Inline and remove `place_contents_drop_state_cannot_differ`.
It has a single call site and is hot enough to be worth inlining. And make sure `is_terminal_path` is inlined, too.
r? `@ghost`
Point out the type of associated types in every method call of iterator chains
Partially address #105184 by pointing out the type of associated types in every method call of iterator chains:
```
note: the expression is of type `Map<std::slice::Iter<'_, {integer}>, [closure@src/test/ui/iterators/invalid-iterator-chain.rs:12:18: 12:21]>`
--> src/test/ui/iterators/invalid-iterator-chain.rs:12:14
|
10 | vec![0, 1]
| ---------- this expression has type `Vec<{integer}>`
11 | .iter()
| ------ associated type `std::iter::Iterator::Item` is `&{integer}` here
12 | .map(|x| { x; })
| ^^^^^^^^^^^^^^^ associated type `std::iter::Iterator::Item` is `()` here
```
We also reduce the number of impls we mention when any of the candidates is an "exact match". This benefits the output of cases with numerics greatly.
Outstanding work would be to provide a structured suggestion for appropriate changes, like in this case detecting the spurious `;` in the closure.
Previously, we used spans. This was not good. Sometimes, the span of the
token that failed to match may come from a position later in the file
which has been transcribed into a token stream way earlier in the file.
If precisely this token fails to match, we think that it was the best
match because its span is so high, even though other arms might have
gotten further in the token stream.
We now try to properly use the location in the token stream.
Use struct types during codegen in less places
This makes it easier to use cg_ssa from a backend like Cranelift that doesn't have any struct types at all. After this PR struct types are still used for function arguments and return values. Removing those usages is harder but should still be doable.
Remove `token::Lit` from `ast::MetaItemLit`.
Currently `ast::MetaItemLit` represents the literal kind twice. This PR removes that redundancy. Best reviewed one commit at a time.
r? `@petrochenkov`
Fix lint perf regressions
#104863 caused small but widespread regressions in lint performance. I tried to improve things in #105291 and #105416 with minimal success, before fully understanding what caused the regression. This PR effectively reverts all of #105291 and part of #104863 to fix the perf regression.
r? `@cjgillot`
Make encode_info_for_trait_item use queries instead of accessing the HIR
This change avoids accessing the HIR on `encode_info_for_trait_item` and uses queries. We will need to execute this function for elements that have no HIR and by using queries we will be able to feed for definitions that have no HIR.
r? ``@oli-obk``
This commit partly undoes #104863, which combined the builtin lints pass
with other lints. This caused a slowdown, because often there are no
other lints, and it's faster to do a pass with a single lint directly
than it is to do a combined pass with a `passes` vector containing a
single lint.
I removed these in #105291, and subsequently learned they are necessary
for performance.
This commit reinstates them with the new and more descriptive names
`RuntimeCombined{Early,Late}LintPass`, similar to the existing passes
like `BuiltinCombinedEarlyLintPass`. It also adds some comments,
particularly emphasising how we have ways to combine passes at both
compile-time and runtime. And it moves some comments around.
When encountering an unmet obligation that affects a method chain, like
in iterator chains where one of the links has the wrong associated
type, we point at every method call and mention their evaluated
associated type at that point to give context to the user of where
expectations diverged from the code as written.
```
note: the expression is of type `Map<std::slice::Iter<'_, {integer}>, [closure@$DIR/invalid-iterator-chain.rs:12:18: 12:21]>`
--> $DIR/invalid-iterator-chain.rs:12:14
|
LL | vec![0, 1]
| ---------- this expression has type `Vec<{integer}>`
LL | .iter()
| ------ associated type `std::iter::Iterator::Item` is `&{integer}` here
LL | .map(|x| { x; })
| ^^^^^^^^^^^^^^^ associated type `std::iter::Iterator::Item` is `()` here
```
Don't internalize __llvm_profile_counter_bias
Currently, LLVM profiling runtime counter relocation cannot be used by rust during LTO because symbols are being internalized before all symbol information is known.
This mode makes LLVM emit a __llvm_profile_counter_bias symbol which is referenced by the profiling initialization, which itself is pulled in by the rust driver here [1].
It is enabled with -Cllvm-args=-runtime-counter-relocation for platforms which are opt-in to this mode like Linux. On these platforms there will be no link error, rather just surprising behavior for a user which request runtime counter relocation. The profiling runtime will not see that symbol go on as if it were never there. On Fuchsia, the profiling runtime must have this symbol which will cause a hard link error.
As an aside, I don't have enough context as to why rust's LTO model is how it is. AFAICT, the internalize pass is only safe to run at link time when all symbol information is actually known, this being an example as to why. I think special casing this symbol as a known one that LLVM can emit which should not have it's visbility de-escalated should be fine given how seldom this pattern of defining an undefined symbol to get initilization code pulled in is. From a quick grep, __llvm_profile_runtime is the only symbol that rustc does this for.
[1] 0265a3e93b/compiler/rustc_codegen_ssa/src/back/linker.rs (L598)
compiler: remove unnecessary imports and qualified paths
Some of these imports were necessary before Edition 2021, others were already in the prelude.
I hope it's fine that this PR is so spread-out across files :/
Some method confirmation code nits
1. Make some pick methods take `&self` instead of `&mut` to avoid some cloning
2. Pass some values by reference to avoid some cloning
3. Rename a few variables here and there
Fix invalid codegen during debuginfo lowering
In order for LLVM to correctly generate debuginfo for msvc, we sometimes need to spill arguments to the stack and perform some direct & indirect offsets into the value. Previously, this code always performed those actions, even when not required as LLVM would clean it up during optimization.
However, when MIR inlining is enabled, this can cause problems as the operations occur prior to the spilled value being initialized. To solve this, we first calculate the necessary offsets using just the type which is side-effect free and does not alter the LLVM IR. Then, if we are in a situation which requires us to generate the LLVM IR (and this situation only occurs for arguments, not local variables) then we perform the same calculation again, this time generating the appropriate LLVM IR as we go.
r? `@tmiasko` but feel free to reassign if you want 🙂Fixes#105386
Migrate parts of `rustc_expand` to session diagnostics
This migrates everything but the `mbe` and `proc_macro` modules. It also contains a few cleanups and drive-by/accidental diagnostic improvements which can be seen in the diff for the UI tests.
Rollup of 10 pull requests
Successful merges:
- #98391 (Reimplement std's thread parker on top of events on SGX)
- #104019 (Compute generator sizes with `-Zprint_type_sizes`)
- #104512 (Set `download-ci-llvm = "if-available"` by default when `channel = dev`)
- #104901 (Implement masking in FileType comparison on Unix)
- #105082 (Fix Async Generator ABI)
- #105109 (Add LLVM KCFI support to the Rust compiler)
- #105505 (Don't warn about unused parens when they are used by yeet expr)
- #105514 (Introduce `Span::is_visible`)
- #105516 (Update cargo)
- #105522 (Remove wrong note for short circuiting operators)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
This migrates everything but the `mbe` and `proc_macro` modules. It also
contains a few cleanups and drive-by/accidental diagnostic improvements
which can be seen in the diff for the UI tests.
Add LLVM KCFI support to the Rust compiler
This PR adds LLVM Kernel Control Flow Integrity (KCFI) support to the Rust compiler. It initially provides forward-edge control flow protection for operating systems kernels for Rust-compiled code only by aggregating function pointers in groups identified by their return and parameter types. (See llvm/llvm-project@cff5bef.)
Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by identifying C char and integer type uses at the time types are encoded (see Type metadata in the design document in the tracking issue #89653).
LLVM KCFI can be enabled with -Zsanitizer=kcfi.
Thank you again, `@bjorn3,` `@eddyb,` `@nagisa,` and `@ojeda,` for all the help!
Fix Async Generator ABI
This change was missed when making async generators implement `Future` directly.
It did not cause any problems in codegen so far, as `GeneratorState<(), Output>`
happens to have the same ABI as `Poll<Output>`.
Rollup of 9 pull requests
Successful merges:
- #102406 (Make `missing_copy_implementations` more cautious)
- #105265 (Add `rustc_on_unimplemented` to `Sum` and `Product` trait.)
- #105385 (Skip test on s390x as LLD does not support the platform)
- #105453 (Make `VecDeque::from_iter` O(1) from `vec(_deque)::IntoIter`)
- #105468 (Mangle "main" as "__main_void" on wasm32-wasi)
- #105480 (rustdoc: remove no-op mobile CSS `#sidebar-toggle { text-align }`)
- #105489 (Fix typo in apple_base.rs)
- #105504 (rustdoc: make stability badge CSS more consistent)
- #105506 (Tweak `rustc_must_implement_one_of` diagnostic output)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Mangle "main" as "__main_void" on wasm32-wasi
On wasm, the age-old C trick of having a main function which can either have no arguments or argc+argv doesn't work, because wasm requires caller and callee signatures to match. WASI's current strategy is to have compilers mangle main's name to indicate which signature they're using. Rust uses the no-argument form, which should be mangled as `__main_void`.
This is needed on wasm32-wasi as of #105395.
Make `missing_copy_implementations` more cautious
- Fixes https://github.com/rust-lang/rust/issues/98348
- Also makes the lint not fire on large types and types containing raw pointers. Thoughts?
Shrink `rustc_parse_format::Piece`
This makes both variants closer together in size (previously they were different by 208 bytes -- 16 vs 224). This may make things worse, but it's worth a try.
r? `@nnethercote`
In a scenario like
```
struct Type;
pub trait Trait {
fn function(&mut self)
where
Self: Sized;
}
impl Trait for Type {
fn function(&mut self) {}
}
fn main() {
(&mut Type as &mut dyn Trait).function();
}
```
the problem is Sized, not the mutability of self. Thus don't emit the
"you need &T instead of &mut T" note, or the other way around, as all
it does is just invert the mutability of whatever was supplied.
Fixes#103622.
use the correct `Reveal` during validation
supersedes #105454. Deals with https://github.com/rust-lang/rust/issues/105009#issuecomment-1342395333, not closing #105009 as the ICE may leak into beta
The issue was the following:
- we optimize the mir, using `Reveal::All`
- some optimization relies on the hidden type of an opaque type
- we then validate using `Reveal::UserFacing` again which is not able to observe the hidden type
r? `@jackh726`
Move some queries and methods
Each commit's title should be self-explanatory. Motivated to break up some large, general files and move queries into leaf crates.
In order for LLVM to correctly generate debuginfo for msvc, we sometimes
need to spill arguments to the stack and perform some direct & indirect
offsets into the value. Previously, this code always performed those
actions, even when not required as LLVM would clean it up during
optimization.
However, when MIR inlining is enabled, this can cause problems as the
operations occur prior to the spilled value being initialized. To solve
this, we first calculate the necessary offsets using just the type which
is side-effect free and does not alter the LLVM IR. Then, if we are in a
situation which requires us to generate the LLVM IR (and this situation
only occurs for arguments, not local variables) then we perform the same
calculation again, this time generating the appropriate LLVM IR as we
go.
This commit adds LLVM Kernel Control Flow Integrity (KCFI) support to
the Rust compiler. It initially provides forward-edge control flow
protection for operating systems kernels for Rust-compiled code only by
aggregating function pointers in groups identified by their return and
parameter types. (See llvm/llvm-project@cff5bef.)
Forward-edge control flow protection for C or C++ and Rust -compiled
code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code
share the same virtual address space) will be provided in later work as
part of this project by identifying C char and integer type uses at the
time types are encoded (see Type metadata in the design document in the
tracking issue #89653).
LLVM KCFI can be enabled with -Zsanitizer=kcfi.
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
This change was missed when making async generators implement `Future` directly.
It did not cause any problems in codegen so far, as `GeneratorState<(), Output>`
happens to have the same ABI as `Poll<Output>`.
On wasm, the age-old C trick of having a main function which can either have
no arguments or argc+argv doesn't work, because wasm requires caller and
callee signatures to match. WASI's current strategy is to have compilers
mangle main's name to indicate which signature they're using. Rust uses the
no-argument form, which should be mangled as `__main_void`.
This is needed on wasm32-wasi as of #105395.
Add help for `#![feature(impl_trait_in_fn_trait_return)]`
This adds a new variant `ImplTraitContext::FeatureGated`, so we can
generalize the help for `return_position_impl_trait_in_trait` to also
work for `impl_trait_in_fn_trait_return`.
cc #99697
Stop passing -export-dynamic to wasm-ld.
-export-dynamic was a temporary hack added in the early days of the Rust wasm32 target when Rust didn't have a way to specify wasm exports in the source code. This flag causes all global symbols, and some compiler-internal symbols, to be exported, which is often more than needed.
Rust now does have a way to specify exports in the source code: `#[export_name = "..."]`.
So as the original comment suggests, -export-dynamic can now be removed, allowing users to have smaller binaries and better encapsulation in their wasm32-unknown-unknown modules.
It's possible that this change will require existing wasm32-unknown-unknown users will to add explicit `#[export_name = "..."]` directives to exporrt the symbols that their programs depend on having exported.
make retagging work even with 'unstable' places
This is based on top of https://github.com/rust-lang/rust/pull/105301. Only the last two commits are new.
While investigating https://github.com/rust-lang/unsafe-code-guidelines/issues/381 I realized that we would have caught this issue much earlier if the add_retag pass wouldn't bail out on assignments of the form `*ptr = ...`.
So this PR changes our retag strategy:
- When a new reference is created via `Rvalue::Ref` (or a raw ptr via `Rvalue::AddressOf`), we do the retagging as part of just executing that address-taking operation.
- For everything else, we still insert retags -- these retags basically serve to ensure that references stored in local variables (and their fields) are always freshly tagged, so skipping this for assignments like `*ptr = ...` is less egregious.
r? ```@oli-obk```
Detect long types in E0308 and write them to disk
On type error with long types, print an abridged type and write the full type to disk.
Print the widest possible short type while still fitting in the terminal.
Currently, LLVM profiling runtime counter relocation cannot be
used by rust during LTO because symbols are being internalized
before all symbol information is known.
This mode makes LLVM emit a __llvm_profile_counter_bias symbol
which is referenced by the profiling initialization, which itself
is pulled in by the rust driver here [1].
It is enabled with -Cllvm-args=-runtime-counter-relocation for
platforms which are opt-in to this mode like Linux. On these
platforms there will be no link error, rather just surprising
behavior for a user which request runtime counter relocation.
The profiling runtime will not see that symbol go on as if it
were never there. On Fuchsia, the profiling runtime must have
this symbol which will cause a hard link error.
As an aside, I don't have enough context as to why rust's LTO
model is how it is. AFAICT, the internalize pass is only safe
to run at link time when all symbol information is actually
known, this being an example as to why. I think special casing
this symbol as a known one that LLVM can emit which should not
have it's visbility de-escalated should be fine given how
seldom this pattern of defining an undefined symbol to get
initilization code pulled in is. From a quick grep,
__llvm_profile_runtime is the only symbol that rustc does this
for.
[1] 0265a3e93b/compiler/rustc_codegen_ssa/src/back/linker.rs (L598)
normalize before handling simple checks for evaluatability of `ty::Const`
`{{{{{{{ N }}}}}}}` is desugared into a `ConstKind::Unevaluated` for an anonymous `const` item so when calling `is_const_evaluatable` on it we skip the `ConstKind::Param(_) => Ok(())` arm which is incorrect.
Simplify attribute handling in rustc_ast_lowering
Given that attributes is stored in a separate BTreeMap, it's not necessary to pass it in when constructing `hir::Expr`. We can just construct `hir::Expr` and then call `self.lower_attrs` later if it needs attributes.
As most desugaring code don't use attributes, this allows some code cleanup.
Remove `{Early,Late}LintPassObjects`.
`EarlyContextAndPass` wraps a single early lint pass. We aggregate multiple passes into that single pass by using `EarlyLintPassObjects`.
This commit removes `EarlyLintPassObjects` by changing `EarlyContextAndPass` into `EarlyContextAndPasses`. I.e. it just removes a level of indirection. This makes the code simpler and slightly faster.
The commit does likewise for late lints.
r? `@cjgillot`
This adds a new variant `ImplTraitContext::FeatureGated`, so we can
generalize the help for `return_position_impl_trait_in_trait` to also
work for `impl_trait_in_fn_trait_return`.
-export-dynamic was a temporary hack added in the early days of the Rust
wasm32 target when Rust didn't have a way to specify wasm exports in the
source code. This flag causes all global symbols, and some compiler-internal
symbols, to be exported, which is often more than needed.
Rust now does have a way to specify exports in the source code:
`#[export_name = "..."]`.
So as the original comment suggests, -export-dynamic can now be removed,
allowing users to have smaller binaries and better encapsulation in
their wasm32-unknown-unknown modules.
It's possible that this change will require existing wasm32-unknown-unknown
users will to add explicit `#[export_name = "..."]` directives to
exporrt the symbols that their programs depend on having exported.
Rollup of 9 pull requests
Successful merges:
- #104898 (Put all cached values into a central struct instead of just the stable hash)
- #105004 (Fix `emit_unused_delims_expr` ICE)
- #105174 (Suggest removing struct field from destructive binding only in shorthand scenario)
- #105250 (Replace usage of `ResumeTy` in async lowering with `Context`)
- #105286 (Add -Z maximal-hir-to-mir-coverage flag)
- #105320 (rustdoc: simplify CSS selectors on top-doc and non-exhaustive toggles)
- #105349 (Point at args in associated const fn pointers)
- #105362 (Cleanup macro-expanded code in `rustc_type_ir`)
- #105370 (Remove outdated syntax from trait alias pretty printing)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove outdated syntax from trait alias pretty printing
Given the following program:
```rust
#![feature(trait_alias)]
trait A = ?Sized;
fn main() {}
```
Old output of `rustc +nightly ./t.rs -Zunpretty=normal`:
```rust
#![feature(trait_alias)]
trait A for ? Sized ;
fn main() {}
```
New output of `rustc +a ./t.rs -Zunpretty=normal`:
```rust
#![feature(trait_alias)]
trait A = ?Sized;
fn main() {}
```
cc `@durka` (you've written the `FIXME` in #45047, see https://github.com/rust-lang/rust/pull/45047#discussion_r144960751)
Cleanup macro-expanded code in `rustc_type_ir`
We could of course just leave this as-is, but every time I go-to-def to this file it's painful to see all this `(&A(ref __self_1_0),)` stuff.
Point at args in associated const fn pointers
Tiny follow-up to #105201, not so sure it's worth it but 🤷
The UI test example is a bit more compelling when it's `GlUniformScalar::FACTORY`
r? `@cjgillot`
Add -Z maximal-hir-to-mir-coverage flag
This PR adds a new unstable flag `-Z maximal-hir-to-mir-coverage` that changes the behavior of `maybe_lint_level_root_bounded`, pursuant to [a discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Mapping.20MIR.20to.20HIR). When enabled, this function will not search upwards for a lint root, but rather immediately return the provided HIR node ID. This change increases the granularity of the mapping between MIR locations and HIR nodes inside the `SourceScopeLocalData` data structures. This increase in granularity is useful for rustc consumers like [Flowistry](https://github.com/willcrichton/flowistry) that rely on getting source-mapping information about the MIR CFG that is as precise as possible.
A test `maximal_mir_to_hir_coverage.rs` has been added to verify that this flag does not break anything.
r? `@cjgillot`
cc `@gavinleroy`
Replace usage of `ResumeTy` in async lowering with `Context`
Replaces using `ResumeTy` / `get_context` in favor of using `&'static mut Context<'_>`.
Usage of the `'static` lifetime here is technically "cheating", and replaces the raw pointer in `ResumeTy` and the `get_context` fn that pulls the correct lifetimes out of thin air.
fixes https://github.com/rust-lang/rust/issues/104828 and https://github.com/rust-lang/rust/pull/104321#issuecomment-1336363077
r? `@oli-obk`
Put all cached values into a central struct instead of just the stable hash
cc `@nnethercote`
this allows re-use of the type for Predicate without duplicating all the logic for the non-hash cached fields
Re-enable removal of ZST writes to unions
This was previously disabled because Miri was lazily allocating unsized locals. But we aren't doing that anymore since https://github.com/rust-lang/rust/pull/98831, so we can have this optimization back.
Make `note_obligation_cause_code` take a `impl ToPredicate` for predicate
The only usecase that wasn't `impl ToPredicate` was noting overflow errors while revealing opaque types, which passed in an `Obligation<'tcx, Ty<'tcx>>`... Since this only happens in a `RevealAll` environment, which is after typeck (and probably primarily within `normalize_erasing_regions`) we're unlikely to display anything useful while noting this code, evidenced by the lack of UI test changes.
support `ConstKind::Expr` in `is_const_evaluatable` and `WfPredicates::compute`
Fixes#105205
Currently we haven't implemented a way to evaluate `ConstKind::Expr(Expr::Binop(Add, 1, 2))` so I just left that with a `FIXME` and a `delay_span_bug` since I have no idea how to do that and it would make this a much larger (and more complicated) PR :P
Synthesize substitutions for bad auto traits in dyn types
Auto traits are stored as just `DefId`s inside a `dyn Trait`'s existential predicates list. This is usually fine, since auto traits are forbidden to have generics -- but this becomes a problem for an ill-formed auto trait.
But since this will always result in an error, just synthesize some dummy (error) substitutions which are used at least to keep trait selection code happy about the number of substs in a trait ref.
Fixes#104808
propagate the error from parsing enum variant to the parser and emit out
While parsing enum variant, the error message always disappear
Because the error message that emit out is from main error of parser
The information of enum variant disappears while parsing enum variant with error
We only check the syntax of expecting token, i.e, in case https://github.com/rust-lang/rust/issues/103869
It will error it without telling the message that this error is from pasring enum variant.
Propagate the sub-error from parsing enum variant to the main error of parser by chaining it with map_err
Check the sub-error before emitting the main error of parser and attach it.
Fix https://github.com/rust-lang/rust/issues/103869
This makes both variants closer together in size (previously they were
different by 208 bytes -- 16 vs 224). This may make things worse, but
it's worth a try.
Add StableOrd trait as proposed in MCP 533.
The `StableOrd` trait can be used to mark types as having a stable sort order across compilation sessions. Collections that sort their items in a stable way can safely implement HashStable by hashing items in sort order.
See https://github.com/rust-lang/compiler-team/issues/533 for more information.
Replaces using `ResumeTy` / `get_context` in favor of using `&'static mut Context<'_>`.
Usage of the `'static` lifetime here is technically "cheating", and replaces
the raw pointer in `ResumeTy` and the `get_context` fn that pulls the
correct lifetimes out of thin air.
Tweak "the following other types implement trait"
When *any* of the suggested impls is an exact match, *only* show the exact matches. This is particularly relevant for integer types.
r? `@compiler-errors`
interpret: clobber return place when calling function
Makes sure the callee cannot observe the previous contents of the return place, and the caller cannot read any of the old return place contents even if the function unwinds.
I don't think we can test for this though, that would require some strange hand-written MIR.
r? `````@oli-obk`````
feed resolver_for_lowering instead of storing it in a field
r? `@cjgillot`
opening this as
* a discussion for `no_hash` + `feedable` queries. I think we'll want those, but I don't quite understand why they are rejected beyond a double check of the stable hashes for situations where the query is fed but also read from incremental caches.
* and a discussion on removing all untracked fields from TyCtxt and setting it up so that they are fed queries instead
Given that attributes is stored in a separate BTreeMap, it's not necessary
to pass it in when constructing `hir::Expr`. We can just construct
`hir::Expr` and then call `self.lower_attrs` later if it needs attributes.
As most desugaring code don't use attributes, this allows some code cleanup.
Disable top down MIR inlining
The current MIR inliner has exponential behavior in some cases: <https://godbolt.org/z/7jnWah4fE>. The cause of this is top-down inlining, where we repeatedly do inlining like `call_a() => { call_b(); call_b(); }`. Each decision on its own seems to make sense, but the result is exponential.
Disabling top-down inlining fundamentally prevents this. Each call site in the original, unoptimized source code is now considered for inlining exactly one time, which means that the total growth in MIR size is limited to number of call sites * inlining threshold.
Top down inlining may be worth re-introducing at some point, but it needs to be accompanied with a principled way to prevent this kind of behavior.
This ensures that the error is printed even for unused variables,
as well as unifying the handling between the LLVM and GCC backends.
This also fixes unusual behavior around exported Rust-defined variables
with linkage attributes. With the previous behavior, it appears to be
impossible to define such a variable such that it can actually be imported
and used by another crate. This is because on the importing side, the
variable is required to be a pointer, but on the exporting side, the
type checker rejects static variables of pointer type because they do
not implement `Sync`. Even if it were possible to import such a type, it
appears that code generation on the importing side would add an unexpected
additional level of pointer indirection, which would break type safety.
This highlighted that the semantics of linkage on Rust-defined variables
is different to linkage on foreign items. As such, we now model the
difference with two different codegen attributes: linkage for Rust-defined
variables, and import_linkage for foreign items.
This change gives semantics to the test
src/test/ui/linkage-attr/auxiliary/def_illtyped_external.rs which was
previously expected to fail to compile. Therefore, convert it into a
test that is expected to successfully compile.
The update to the GCC backend is speculative and untested.
`EarlyContextAndPass` wraps a single early lint pass. We aggregate
multiple passes into that single pass by using `EarlyLintPassObjects`.
This commit removes `EarlyLintPassObjects` by changing
`EarlyContextAndPass` into `EarlyContextAndPasses`. I.e. it just removes
a level of indirection. This makes the code simpler and slightly faster.
The commit does likewise for late lints.
It has a single call site in the HIR pretty printer, where the resulting
token lit is immediately converted to a string.
This commit replaces `LitKind::synthesize_token_lit` with a `Display`
impl for `LitKind`, which can be used by the HIR pretty printer.
These two methods both produce a `MetaItemLit`, and then some of the
call sites convert the `MetaItemLit` to a `token::Lit` with
`as_token_lit`.
This commit parameterises these two methods with a `mk_lit_char`
closure, which can be used to produce either `MetaItemLit` or
`token::Lit` directly as necessary.
Avoid some `InferCtxt::build` calls
Either because we're inside of an `InferCtxt` already, or because we're not in a place where we'd ever see inference vars.
r? types
There are better ways to create the meta items.
- In the rustdoc tests, the commit adds `dummy_meta_item_name_value`,
which matches the existing `dummy_meta_item_word` function and
`dummy_meta_item_list` macro.
- In `types.rs` the commit clones the existing meta item and then
modifies the clone.
Make sure async constructs do not `impl Generator`
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`.
This was discovered in https://github.com/rust-lang/rust/pull/105082#issuecomment-1332210907 and is a regression from https://github.com/rust-lang/rust/pull/104321.
r? `@compiler-errors`
rustc_codegen_ssa: Fix for codegen_get_discr
When doing the optimized implementation of getting the discriminant, the arithmetic needs to be done in the tag type so wrapping behavior works correctly.
Fixes#104519
Rollup of 6 pull requests
Successful merges:
- #101975 (Suggest to use . instead of :: when accessing a method of an object)
- #105141 (Fix ICE on invalid variable declarations in macro calls)
- #105224 (Properly substitute inherent associated types.)
- #105236 (Add regression test for #47814)
- #105247 (Use parent function WfCheckingContext to check RPITIT.)
- #105253 (Update a couple of rustbuild deps)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix ICE on invalid variable declarations in macro calls
This fixes ICE that happens with invalid variable declarations in macro calls like:
```rust
macro_rules! m { ($s:stmt) => {} }
m! { var x }
m! { auto x }
m! { mut x }
```
Found this is because of not collecting tokens on recovery, so I changed to force collect them.
Fixes https://github.com/rust-lang/rust/issues/103529.
Remove drop order twist of && and || and make them associative
Previously a short circuiting binop chain (chain of && or ||s) would drop the temporaries created by the first element after all the other elements, and otherwise follow evaluation order. So `f(1).g() && f(2).g() && f(3).g() && f(4).g()` would drop the temporaries in the order `2,3,4,1`. This made `&&` and `||` non-associative regarding drop order. In other words, adding ()'s to the expression would change drop order: `f(1).g() && (f(2).g() && f(3).g()) && f(4).g()` for example would drop in the order `3,2,4,1`.
As, except for the bool result, there is no data returned by the sub-expressions of the short circuiting binops, we can safely discard of any temporaries created by the sub-expr. Previously, code was already putting the rhs's into terminating scopes, but missed it for the lhs's.
This commit addresses this "twist". We now also put the lhs into a terminating scope. The drop order of the above expressions becomes `1,2,3,4`.
There might be code relying on the current order, and therefore I'd recommend doing a crater run to gauge the impact. I'd argue that such code is already quite wonky as it is one `foo() &&` addition away from breaking. ~~For the impact, I don't expect any *build* failures, as the compiler gets strictly more tolerant: shortening the lifetime of temporaries only expands the list of programs the compiler accepts as valid. There might be *runtime* failures caused by this change however.~~ Edit: both build and runtime failures are possible, e.g. see the example provided by dtolnay [below](https://github.com/rust-lang/rust/pull/103293#issuecomment-1285341113). Edit2: the crater run has finished and [results](https://github.com/rust-lang/rust/pull/103293#issuecomment-1292275203) are that there is only one build failure which is easy to fix with a +/- 1 line diff.
I've included a testcase that now compiles thanks to this patch.
The breakage is also limited to drop order relative to conditionals in the && chain: that is, in code like this:
```Rust
let hello = foo().hi() && bar().world();
println!("hi");
```
we already drop the temporaries of `foo().hi()` before we reach "hi".
I'd ideally have this PR merged before let chains are stabilized. If this PR is taking too long, I'd love to have a more restricted version of this change limited to `&&`'s in let chains: the `&&`'s of such chains are quite special anyways as they accept `let` bindings, in there the `&&` is therefore more a part of the "if let chain" construct than a construct of its own.
Fixes#103107
Status: waiting on [this accepted FCP](https://github.com/rust-lang/rust/pull/103293#issuecomment-1293411354) finishing.
Fix passing MACOSX_DEPLOYMENT_TARGET to the linker
I messed up in https://github.com/rust-lang/rust/pull/103929 when merging the two base files together and as a result, started ignoring `MACOSX_DEPLOYMENT_TARGET` at the linker level. This ended up being the cause of nighty builds not running on older macOS versions.
My original hope with the previous PR was that CI would have caught something like that but there were only tests checking the compiler target definitions in codegen tests. Because of how badly this sucks to break, I put together a new test via `run-make` that actually confirms the deployment target set makes it to the linker instead of just LLVM.
Closes https://github.com/rust-lang/rust/issues/104570 (for real this time)
This avoids creation of a terminating scope in
chains that contain both && and ||, because
also there we know that a terminating scope is
not neccessary: all the chain members are already
in such terminating scopes.
Also add a mixed && / || test.
Previously a short circuiting && chain would drop the
first element after all the other elements, and otherwise
follow evaluation order, so code like:
f(1).g() && f(2).g() && f(3).g() && f(4).g()
would drop the temporaries in the order 2,3,4,1. This made
&& and || non-associative regarding drop order, so
adding ()'s to the expression would change drop order:
f(1).g() && (f(2).g() && f(3).g()) && f(4).g()
for example would drop in the order 3,2,4,1.
As, except for the bool result, there is no data returned
by the sub-expressions of the short circuiting binops,
we can safely discard of any temporaries created by the
sub-expr. Previously, code was already putting the rhs's
into terminating scopes, but missed it for the lhs's.
This commit addresses this "twist". In the expression,
we now also put the lhs into a terminating scope.
The drop order for the above expressions is 1,2,3,4
now.
Rollup of 9 pull requests
Successful merges:
- #104199 (Keep track of the start of the argument block of a closure)
- #105050 (Remove useless borrows and derefs)
- #105153 (Create a hacky fail-fast mode that stops tests at the first failure)
- #105164 (Restore `use` suggestion for `dyn` method call requiring `Sized`)
- #105193 (Disable coverage instrumentation for naked functions)
- #105200 (Remove useless filter in unused extern crate check.)
- #105201 (Do not call fn_sig on non-functions.)
- #105208 (Add AmbiguityError for inconsistent resolution for an import)
- #105214 (update Miri)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Restore `use` suggestion for `dyn` method call requiring `Sized`
Add the suggestion back that I accidentally removed in 88f2140d87 because I didn't understand that suggestion was actually useful...
Fixes#105159
Remove useless borrows and derefs
They are nothing more than noise.
<sub>These are not all of them, but my clippy started crashing (stack overflow), so rip :(</sub>
Previously, the `recover_local_after_let` function was called from the
body of the `recover_stmt_local` function. Unifying these two functions
make it more simple and more readable.
Don't elide type information when printing E0308 with `-Zverbose`
When we pass `-Zverbose`, we kinda expect for all `_` to be replaced with more descriptive information, for example --
```
= note: expected fn pointer `fn(_, u32)`
found fn item `fn(_, i32) {foo}`
```
Where `_` is the "identical" part of the fn signatures, now gets rendered as:
```
= note: expected fn pointer `fn(i32, u32)`
found fn item `fn(i32, i32) {foo}`
```
Check lifetime param count in `collect_trait_impl_trait_tys`
We checked the type and const generics count, but not the lifetimes, which were handled in a different function.
Fixes#105154
The StableOrd trait can be used to mark types as having a stable
sort order across compilation sessions. Collections that sort their
items in a stable way can safely implement HashStable by
hashing items in sort order.
Add `type_ascribe!` macro as placeholder syntax for type ascription
This makes it still possible to test the internal semantics of type ascription even once the `:`-syntax is removed from the parser. The macro now gets used in a bunch of UI tests that test the semantics and not syntax of type ascription.
I might have forgotten a few tests but this should hopefully be most of them. The remaining ones will certainly be found once type ascription is removed from the parser altogether.
Part of #101728
Because the error message that emit out is from main error of parser
The information of enum variant disappears while parsing enum variant with error
We only check the syntax of expecting token, i.e, in case #103869
It will error it without telling the message that this error is from pasring enum variant.
Propagate the sub-error from parsing enum variant to the main error of parser by chaining it with map_err
Check the sub-error before emitting the main error of parser and attach it.
Fix#103869
rustc_ast_lowering: Stop lowering imports into multiple items
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.
This avoids calling `early_lint_node` twice.
Note: one `early_lint_node` call had `!pre_expansion` for the second
argument and the other had `false`. The new single call just has
`!pre_expansion`. This results in a reduction of duplicate error
messages in some `ui-fulldeps` tests. The order of some `ui-fulldeps`
output also changes, but that doesn't matter.
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.
`token::Lit` contains a `kind` field that indicates what kind of literal
it is. `ast::MetaItemLit` currently wraps a `token::Lit` but also has
its own `kind` field. This means that `ast::MetaItemLit` encodes the
literal kind in two different ways.
This commit changes `ast::MetaItemLit` so it no longer wraps
`token::Lit`. It now contains the `symbol` and `suffix` fields from
`token::Lit`, but not the `kind` field, eliminating the redundancy.
This is required to distinguish between cooked and raw byte string
literals in an `ast::LitKind`, without referring to an adjacent
`token::Lit`. It's a prerequisite for the next commit.
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.
On type error with long types, print an abridged type and write the full
type to disk.
Print the widest possible short type while still fitting in the
terminal.
`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 🙇🏾♂️.
Initial pass at expr/abstract const/s
Address comments
Switch to using a list instead of &[ty::Const], rm `AbstractConst`
Remove try_unify_abstract_consts
Update comments
Add edits
Recurse more
More edits
Prevent equating associated consts
Move failing test to ui
Changes this test from incremental to ui, and mark it as failing and a known bug.
Does not cause the compiler to ICE, so should be ok.
privacy: Fix more (potential) issues with effective visibilities
Continuation of https://github.com/rust-lang/rust/pull/103965.
See individual commits for more detailed description of the changes.
The shortcuts removed in 4eb63f618e and c7c7d16727 could actually be correct (or correct after some tweaks), but they used global reasoning like "we can skip this update because if the code compiles then some other update should do the same thing eventually".
I have some expertise in this area, but I still have doubt whether such global reasoning was correct or not, especially in presence of all possible exotic cases with imports.
After this PR all table changes should be "locally correct" after every update, even if it may be overcautious.
If similar optimizations are introduced again they will need detailed comments explaining why it's legal to do what they do and providing proofs.
Fixes https://github.com/rust-lang/rust/issues/104249.
Fixes https://github.com/rust-lang/rust/issues/104539.
make `error_reported` check for delayed bugs
Fixes#104768
`error_reported()` was only checking if there were errors emitted, not for `delay_bug`s which can also be a source of `ErrorGuaranteed`. I assume the same is true of `lint_err_count` but i dont know
resolve: Don't use constructor def ids in the map for field names
Also do some minor cleanup to insertion of those field names.
Addresses a FIXME left in https://github.com/rust-lang/rust/pull/103578.
Make rustc_target usable outside of rustc
I'm working on showing type size in rust-analyzer (https://github.com/rust-lang/rust-analyzer/pull/13490) and I currently copied rustc code inside rust-analyzer, which works, but is bad. With this change, I would become able to use `rustc_target` and `rustc_index` directly in r-a, reducing the amount of copy needed.
This PR contains some feature flag to put nightly features behind them to make crates buildable on the stable compiler + makes layout related types generic over index type + removes interning of nested layouts.
Avoid `GenFuture` shim when compiling async constructs
Previously, async constructs would be lowered to "normal" generators, with an additional `from_generator` / `GenFuture` shim in between to convert from `Generator` to `Future`.
The compiler will now special-case these generators internally so that async constructs will *directly* implement `Future` without the need to go through the `from_generator` / `GenFuture` shim.
The primary motivation for this change was hiding this implementation detail in stack traces and debuginfo, but it can in theory also help the optimizer as there is less abstractions to see through.
---
Given this demo code:
```rust
pub async fn a(arg: u32) -> Backtrace {
let bt = b().await;
let _arg = arg;
bt
}
pub async fn b() -> Backtrace {
Backtrace::force_capture()
}
```
I would get the following with the latest stable compiler (on Windows):
```
4: async_codegen:🅱️:async_fn$0
at .\src\lib.rs:10
5: core::future::from_generator::impl$1::poll<enum2$<async_codegen:🅱️:async_fn_env$0> >
at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\future\mod.rs:91
6: async_codegen:🅰️:async_fn$0
at .\src\lib.rs:4
7: core::future::from_generator::impl$1::poll<enum2$<async_codegen:🅰️:async_fn_env$0> >
at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\future\mod.rs:91
```
whereas now I get a much cleaner stack trace:
```
3: async_codegen:🅱️:async_fn$0
at .\src\lib.rs:10
4: async_codegen:🅰️:async_fn$0
at .\src\lib.rs:4
```
Previously, async constructs would be lowered to "normal" generators,
with an additional `from_generator` / `GenFuture` shim in between to
convert from `Generator` to `Future`.
The compiler will now special-case these generators internally so that
async constructs will *directly* implement `Future` without the need
to go through the `from_generator` / `GenFuture` shim.
The primary motivation for this change was hiding this implementation
detail in stack traces and debuginfo, but it can in theory also help
the optimizer as there is less abstractions to see through.
Pass `InferCtxt` to `DropRangeVisitor` so we can resolve vars
The types that we encounter in the `TypeckResults` that we pass to the `DropRangeVisitor` are not yet fully resolved, since that only happens in writeback after type checking is complete.
Instead, pass down the whole `InferCtxt` so that we can resolve any inference vars that have been constrained since they were written into the results. This is similar to how the `MemCategorizationContext` in the `ExprUseVisitor` also needs to pass down both typeck results _and_ the inference context.
Fixes an ICE mentioned in this comment: https://github.com/rust-lang/rust/issues/104382#issuecomment-1324410781
Properly handle `Pin<&mut dyn* Trait>` receiver in codegen
This ensures we can actually await a `dyn* Future`, which seems important for async fn in dyn trait.
Also, disable `dyn*` trait upcasting. It's not exactly complete right now, and can cause strange ICEs for no reason -- nobody's using it either. I thought it was cute to implement when I did it, but I didn't think about how it interacts structurally with `CoerceUnsized` correctly.
Fixes#104794, presumably removing `dyn*` upcasting and its `CoerceUnsized` issues does the trick.
Throw error on failure in loading llvm-plugin
The following code silently ignores the error as the `LLVMRustSetLastError` only tracks one error at a time. At all other places where `LLVMRustSetLastError` is used the code immediately returns.
251831ece9/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp (L801-L804)
Use `as_deref` in compiler (but only where it makes sense)
This simplifies some code :3
(there are some changes that are not exacly `as_deref`, but more like "clever `Option`/`Result` method use")
Previously if the parent was not in the table, and there was nothing to inherit from, the child's private visibility was used, but that's not correct - the parent may have a larger visibility so we should set it to at least the parent's private visibility.
That parent's private visibility is also inserted into the table for caching, so it's not recalculated later if used again.
Optimizations removed in the previous commit required this function to behave incorrectly, but now those optimizations are gone so we can fix the bug.
Fixes https://github.com/rust-lang/rust/issues/104249
First, they require eagerly calculating private visibility (current normal module), which is somewhat expensive.
Private visibilities are also lost once calculated, instead of being cached in the table.
Second, I cannot prove that the optimizations are correct.
Maybe they can be partially reinstated in the future in cases when it's cheap and provably correct to do them.
They will also probably be merged into `fn update` in that case.
Partially fixes https://github.com/rust-lang/rust/issues/104249
Fixes https://github.com/rust-lang/rust/issues/104539
Fix hang in where-clause suggestion with `predicate_can_apply`
Using `predicate_may_hold` during error reporting causes an evaluation overflow, which (because we use `evaluate_obligation_no_overflow`) then causes the predicate to need to be re-evaluated locally, which results in a hang.
... but since the "add a where clause" suggestion is best-effort, just throw any overflow errors. No need for 100% accuracy.
r? `@lcnr` who has been thinking about overflows... Let me know if you want more context about this issue, and as always, feel free to reassign.
Fixes#104225
optimize field ordering by grouping m*2^n-sized fields with equivalently aligned ones
```rust
use std::ptr::addr_of;
use std::mem;
struct Foo {
word: u32,
byte: u8,
ary: [u8; 4]
}
fn main() {
let foo: Foo = unsafe { mem::zeroed() };
println!("base: {:p}\nword: {:p}\nbyte: {:p}\nary: {:p}", &foo, addr_of!(foo.word), addr_of!(foo.byte), addr_of!(foo.ary));
}
```
prints
```
base: 0x7fffc1a8a668
word: 0x7fffc1a8a668
byte: 0x7fffc1a8a66c
ary: 0x7fffc1a8a66d
```
I.e. the `u8` in the middle causes the array to sit at an odd offset, which might prevent optimizations, especially on architectures where unaligned loads are costly.
Note that this will make field ordering niche-dependent, i.e. a `Bar<T>` with `T=char` and `T=u32` may result in different field order, this may break some code that makes invalid assumptions about `repr(Rust)` types.
Lower return type outside async block creation
This allows feeding a different output type to async blocks with a different `ImplTraitContext`. Spotted this while working on #104321
Refactor must_use lint into two parts
Before, the lint did the checking for `must_use` and pretty printing the types in a special format in one pass, causing quite complex and untranslatable code.
Now the collection and printing is split in two. That should also make it easier to translate or extract the type pretty printing in the future.
Also fixes an integer overflow in the array length pluralization
calculation.
fixes#104352
Use `tcx.require_lang_item` instead of unwrapping lang items
I clearly remember esteban telling me that there is `require_lang_item` but he was from a phone atm and I couldn't find it, so I didn't use it. Stumbled on it today, so here we are :)
