It's defined in `rustc_span::source_map` which doesn't make any sense
because it has nothing to do with source maps. This commit moves it to
the crate root, a more sensible spot for something this basic.
refactor(mgca): Change `DefKind::Const` and `DefKind::AssocConst` to have a `is_type_const` flag
Addresses rust-lang/rust#152940
- Changed `DefKind::Const` and `DefKind::AssocConst` to have a `is_type_const` flag.
- changed `is_type_const` query to check for this flag
- removed `is_rhs_type_const` query
r? @BoxyUwU
* refactor: add `is_type_const` flag to `DefKind::Const` and `AssocConst`
* refactor(cleanup) remove the `rhs_is_type_const` query
* style: fix formatting
* refactor: refactor stuff in librustdoc for new Const and AssocConst
* refactor: refactor clippy for the changes
* chore: formatting
* fix: fix test
* fix: fix suggestions
* Update context.rs
Co-authored-by: Boxy <rust@boxyuwu.dev>
* changed AssocKind::Const to store data about being a type const
`IntoQueryParam` is a trait that lets query callers be a bit sloppy with
the passed-in key.
- Types similar to `DefId` will be auto-converted to `DefId`. Likewise
for `LocalDefId`.
- Reference types will be auto-derefed.
The auto-conversion is genuinely useful; the auto-derefing much less so.
In practice it's only used for passing `&DefId` to queries that accept
`DefId`, which is an anti-pattern because `DefId` is marked with
`#[rustc_pass_by_value]`.
This commit removes the auto-deref impl and makes the necessary sigil
adjustments. (I generally avoid using `*` to deref manually at call
sites, preferring to deref via `&` in patterns or via `*` in match
expressions. Mostly because that way a single deref often covers
multiple call sites.)
skip codegen for intrinsics with big fallback bodies if backend does not need them
This hopefully fixes the perf regression from https://github.com/rust-lang/rust/pull/148478. I only added the intrinsics with big fallback bodies to the list; it doesn't seem worth the effort of going through the entire list.
Fixes https://github.com/rust-lang/rust/issues/149945
Cc @scottmcm @bjorn3
We only use mir_for_ctfe for them anyway in instance_mir. This does
prevent MIR inlining of constructor calls, but constructor calls that
are inlinable during MIR optimizations are rare anyway given that MIR
building already inlines all direct calls to constructors.
Fix ICE: Don't try to evaluate type_consts when eagerly collecting items
This fixes https://github.com/rust-lang/rust/issues/151246
The change is pretty straightforward if the Monomorphization strategy is eager which `-Clink-dead-code=true` sets. This then would lead to the existing code to try and evaluate a `type const` which does not have a body to evaluate leading to an ICE. The change is pretty straight forward just skip over type consts.
This also seems like a sensible choice to me since a MonoItem can only be a Fn, Static, or Asm. A type const is none of the aforementioned.
And even if it was added to the MonoItems list it would then later fail this check:
https://github.com/rust-lang/rust/blob/fe98ddcfcfb6f185dbf4adeaf439d8a756da0273/compiler/rustc_monomorphize/src/collector.rs#L438-L440
Since that explicitly checks that the MonoItem's `DefKind` is static and not anything else.
One more change is the addition of a simple test of the example code from https://github.com/rust-lang/rust/issues/151246 that checks that code compiles successfully with `-Clink-dead-code=true`.
The only other change was to make the guard checks a little easier to read by making the logic more linear instead of one big if statement.
r? @BoxyUwU
@rustbot label +F-associated_const_equality +F-min_generic_const_args
Update compiler/rustc_monomorphize/src/collector.rs
Add FIXME(mgca) comment to potentially re-investigate in the future.
Co-Authored-By: Boxy <rust@boxyuwu.dev>
It's described as a "backwards compatibility hack to keep the diff
small". Removing it requires only a modest amount of churn, and the
resulting code is clearer without the invisible derefs.
Ensure that static initializers are acyclic for NVPTX
NVPTX does not support cycles in static initializers (see rust-lang/rust#146787). LLVM produces an error when attempting to generate code for such constructs, like self-referential structs.
To avoid LLVM UB, we emit a post-monomorphization error on the Rust side before reaching codegen.
This is achieved by analyzing a subgraph of the "mono item graph" that only contains statics.
1. Calculate the strongly connected components (SCCs) of the graph.
2. Check for cycles (more than one node in an SCC or one node that references itself).
NVPTX does not support cycles in static initializers. LLVM produces an error when attempting to codegen such constructs (like self referential structs).
To not produce LLVM UB we instead emit a post-monomorphization error on
Rust side before reaching codegen.
This is achieved by analysing a subgraph of the "mono item graph" that
only contains statics:
1. Calculate the strongly connected components (SCCs) of the graph
2. Check for cycles (more than one node in a SCC or exactly one node
which references itself)
The amdgpu target uses vector types in various places. The vector types
can be used on all architectures, there is no associated target feature
that needs to be enabled.
The largest vector type found in LLVM intrinsics is `v32i32`
(`[32 x i32]`) for mfma intrinsics. Note that while this intrinsic is
only supported on some architectures, the vector type itself is
supported on all architectures.
Externally implementable items
Supersedes https://github.com/rust-lang/rust/pull/140010
Tracking issue: https://github.com/rust-lang/rust/issues/125418
Getting started:
```rust
#![feature(eii)]
#[eii(eii1)]
pub fn decl1(x: u64)
// body optional (it's the default)
{
println!("default {x}");
}
// in another crate, maybe
#[eii1]
pub fn decl2(x: u64) {
println!("explicit {x}");
}
fn main() {
decl1(4);
}
```
- tiny perf regression, underlying issue makes multiple things in the compiler slow, not just EII, planning to solve those separately.
- No codegen_gcc support, they don't have bindings for weak symbols yet but could
- No windows support yet for weak definitions
This PR merges the implementation of EII for just llvm + not windows, doesn't yet contain like a new panic handler implementation or alloc handler. With this implementation, it would support implementing the panic handler in terms of EII already since it requires no default implementation so no weak symbols
The PR has been open in various forms for about a year now, but I feel that having some implementation merged to build upon
rename erase_regions to erase_and_anonymize_regions
I find it consistently confusing that `erase_regions` does more than replacing regions with `'erased`. it also makes some code look real goofy to be writing manual folders to erase regions with a comment saying "we cant use erase regions" :> or code that re-calls erase_regions on types with regions already erased just to anonymize all the bound regions.
r? lcnr
idk how i feel about the name being almost twice as long now
This was done in #145740 and #145947. It is causing problems for people
using r-a on anything that uses the rustc-dev rustup package, e.g. Miri,
clippy.
This repository has lots of submodules and subtrees and various
different projects are carved out of pieces of it. It seems like
`[workspace.dependencies]` will just be more trouble than it's worth.
John Kåre Alsaker