Check for intrinsic to fn ptr casts in unified coercions
Fixesrust-lang/rust#149143 by ensuring that when coercing multiple expressions to a unified type, the same "intrinsic to fn ptr" check is applied as for other coercions.
Exhaustively specify names and stability of `--print` values
While trying to add a new unstable `--print` kind for use by compiletest, I found that the relevant code is quite awkward to work with, for a few reasons:
- It's spread across various parts of a multi-thousand-line source file.
- All newly-added `PrintKind` values are automatically treated as *stable*, unless they are explicitly marked as unstable in a helper function far away.
- Parsing `--print` values relies on a separate table of name/value mappings, but there's no exhaustiveness check for that table.
This PR therefore:
- Extracts the relevant code into its own `print_request` submodule.
- Uses a macro-rules derive to obtain an exhaustive list of values.
- Uses exhaustive matches to associate a name and stability status with each `PrintKind` value.
---
The first commit moves code to a separate module; the second commit contains actual changes.
There should be no change to compiler output.
Reject `async fn` in `const impl` during AST validation
closesrust-lang/rust#149083
Fixes the ICE when using `async fn` inside `const impl` blocks by adding AST validation.
Currently, inherent `impl`s does not perform any checks to verify whether it contains `async fn` declarations. In this PR, I have modified the `visit_assoc_item` function to call `check_async_fn_in_const_trait_or_impl` within the `TraitOrImpl::Impl` case to handle this requirement. Additionally, this change has introduced three possible contexts for the corresponding error messages, so I have updated to properly distinguish between these different contexts when generating messages.
r? oli-obk
autodiff rlib handling
As I learned recently, we now apparently support rlib builds already in some cases.
With the last hint from saethlin this seems to now cover all cases. To be sure I'll add a few more testcases before I mark it as ready.
Once this PR lands, we should to the best of my knowledge, support autodiff in almost code locations, only vtable/dyn ptr remain unsupported for now.
r? ghost
closes: https://github.com/rust-lang/rust/issues/148856
closes: https://github.com/rust-lang/rust/issues/137520
ignore unsized types in mips64 and sparc64 callconvs
Non-rustic calling conventions should not make up an ABI for unsized types (cc https://github.com/rust-lang/rust/pull/148302). The vast majority of our callconv implementations already ignore unsized types, `sparc64` and `mips64` I guess were missed.
r? `````@bjorn3`````
Rust's current mangling scheme depends on compiler internals; loses
information about generic parameters (and other things) which makes for
a worse experience when using external tools that need to interact with
Rust symbol names; is inconsistent; and can contain `.` characters
which aren't universally supported. Therefore, Rust has defined its own
symbol mangling scheme which is defined in terms of the Rust language,
not the compiler implementation; encodes information about generic
parameters in a reversible way; has a consistent definition; and
generates symbols that only use the characters `A-Z`, `a-z`, `0-9`, and
`_`.
Support for the new Rust symbol mangling scheme has been added to
upstream tools that will need to interact with Rust symbols (e.g.
debuggers).
This commit changes the default symbol mangling scheme from the legacy
scheme to the new Rust mangling scheme.
Signed-off-by: David Wood <david.wood@huawei.com>
Add check if span is from macro expansion
The same thing I did in https://github.com/rust-lang/rust/pull/147416, actually the same bug but in another place, I'm not really sure how this method is good for fixing such ICEs, but, it does work and not conflicting with any existing tests, so I guess, it's fine
Fixes https://github.com/rust-lang/rust/issues/147408
r? compiler
recommend using a HashMap if a HashSet's second generic parameter doesn't implement BuildHasher
closesrust-lang/rust#147147
~The suggestion span is wrong, but I'm not sure how to find the right one.~ fixed
I'm relatively new to the diagnostics ecosystem, so I'm not sure if `span_help` is the right choice. `span_suggestion_*` might be better, but the output from `x test` looks weird in that case.
Inherent const impl
Some constifications are annoying because we need to repeat `T: Trait` bounds from an impl block on the individual constified `const fn`s as `T: [const] Trait`. We've brainstormed solutions before, and one would be to have separate `const impl` blocks or sth. However the final syntax will look, I decided to just impl this syntax and either have sth nice on nightly to work with or at least move the discussion along.
Also interacts with the discussion around `impl const Trait for Type` vs `const impl Trait for Type`, as we may want to use the latter to keep inherent and trait impls in sync (unless we come up with even another scheme).
* [ ] rustdoc + tests
* [ ] macro stability /regression tests
r? `@fee1-dead`
cc `@traviscross` `@rust-lang/project-const-traits`
debug-assert FixedSizeEncoding invariant
Something like this? It asserts during encoding that for that type, decoding 0 would give the default.
Preferably, I'd either somehow statically/in const assert it once, instead of every time, but I see no easy way to do so. It'd require us to iterate all types that implement the trait or something. Let me know what you think
No types currently violate this invariant.
r? `@oli-obk`
repr(transparent) check: do not compute check_unsuited more than once
`field_infos` is an iterator that we execute multiple times. However, we usually ignore the `unsuited` field -- we only need it in the last iteration. So move the computation of that field to that iteration to avoid computing it multiple times. Computing `unsuited` involves a recursive traversal over the types of all non-trivial fields, so there can be non-trivial amounts of work here.
(I benchmarked this in https://github.com/rust-lang/rust/pull/148243 and saw no changes, probably because we don't have a benchmark with many repr(transparent) types. But still, computing this each time just seemed silly.)
flush_delayed: add note about stashed diagnostics
r? `@nnethercote`
Is `emit_stashed_diagnostics` the right advice to give? The other option seems to be to call `finish_diagnostics`. That's what I ended up doing (for now) in https://github.com/rust-lang/miri/pull/4702 because it best matches what happens during normal compilation.
Document the `let this = self;` idiom used in MIR building
In `rustc_mir_build` there are a few `Builder` methods that start with `let this = self;`, so that subsequent code can uniformly refer to the builder as `this`, instead of having to choose between `self` at the top level or `this` when nested in closures that need to borrow the builder.
There is some existing documentation of the idiom in `expr_into_dest`:
69d4d5fc0e/compiler/rustc_mir_build/src/builder/expr/into.rs (L32-L35)
But that documentation is brief and hard to find, especially if one is unaware that such documentation even exists.
---
This PR therefore adds a longer explanation of the `let this = self;` idiom in the module documentation for `rustc_mir_build::builder`, and makes that documentation easier to find by adding a searchable tag (“LET_THIS_SELF”) to the documentation and to each occurrence of the idiom.
