about summary refs log tree commit diff
path: root/compiler/rustc_monomorphize/src
AgeCommit message (Collapse)AuthorLines
2024-02-24Add asm label support to AST and HIRGary Guo-1/+2
2024-02-20Reduce capabilities of `Diagnostic`.Nicholas Nethercote-0/+1
Currently many diagnostic modifier methods are available on both `Diagnostic` and `DiagnosticBuilder`. This commit removes most of them from `Diagnostic`. To minimize the diff size, it keeps them within `diagnostic.rs` but changes the surrounding `impl Diagnostic` block to `impl DiagnosticBuilder`. (I intend to move things around later, to give a more sensible code layout.) `Diagnostic` keeps a few methods that it still needs, like `sub`, `arg`, and `replace_args`. The `forward!` macro, which defined two additional methods per call (e.g. `note` and `with_note`), is replaced by the `with_fn!` macro, which defines one additional method per call (e.g. `with_note`). It's now also only used when necessary -- not all modifier methods currently need a `with_*` form. (New ones can be easily added as necessary.) All this also requires changing `trait AddToDiagnostic` so its methods take `DiagnosticBuilder` instead of `Diagnostic`, which leads to many mechanical changes. `SubdiagnosticMessageOp` gains a type parameter `G`. There are three subdiagnostics -- `DelayedAtWithoutNewline`, `DelayedAtWithNewline`, and `InvalidFlushedDelayedDiagnosticLevel` -- that are created within the diagnostics machinery and appended to external diagnostics. These are handled at the `Diagnostic` level, which means it's now hard to construct them via `derive(Diagnostic)`, so instead we construct them by hand. This has no effect on what they look like when printed. There are lots of new `allow` markers for `untranslatable_diagnostics` and `diagnostics_outside_of_impl`. This is because `#[rustc_lint_diagnostics]` annotations were present on the `Diagnostic` modifier methods, but missing from the `DiagnosticBuilder` modifier methods. They're now present.
2024-02-16Auto merge of #120500 - oli-obk:intrinsics2.0, r=WaffleLapkinbors-5/+10
Implement intrinsics with fallback bodies fixes #93145 (though we can port many more intrinsics) cc #63585 The way this works is that the backend logic for generating custom code for intrinsics has been made fallible. The only failure path is "this intrinsic is unknown". The `Instance` (that was `InstanceDef::Intrinsic`) then gets converted to `InstanceDef::Item`, which represents the fallback body. A regular function call to that body is then codegenned. This is currently implemented for * codegen_ssa (so llvm and gcc) * codegen_cranelift other backends will need to adjust, but they can just keep doing what they were doing if they prefer (though adding new intrinsics to the compiler will then require them to implement them, instead of getting the fallback body). cc `@scottmcm` `@WaffleLapkin` ### todo * [ ] miri support * [x] default intrinsic name to name of function instead of requiring it to be specified in attribute * [x] make sure that the bodies are always available (must be collected for metadata)
2024-02-15Auto merge of #120931 - chenyukang:yukang-cleanup-hashmap, r=michaelwoeristerbors-2/+2
Clean up potential_query_instability with FxIndexMap and UnordMap From https://github.com/rust-lang/rust/pull/120485#issuecomment-1916437191 r? `@michaelwoerister`
2024-02-14clean up potential_query_instability with FxIndexMap and UnordMapyukang-2/+2
2024-02-13Auto merge of #120919 - oli-obk:impl_polarity, r=compiler-errorsbors-7/+6
Merge `impl_polarity` and `impl_trait_ref` queries Hopefully this is perf neutral. I want to finish https://github.com/rust-lang/rust/pull/120835 and stop using the HIR in `coherent_trait`, which should then give us a perf improvement.
2024-02-12Rollup merge of #120958 - ShoyuVanilla:remove-subst, r=oli-obkMatthias Krüger-5/+5
Dejargonize `subst` In favor of #110793, replace almost every occurence of `subst` and `substitution` from rustc codes, but they still remains in subtrees under `src/tools/` like clippy and test codes (I'd like to replace them after this)
2024-02-12Rollup merge of #120950 - compiler-errors:miri-async-closurs, r=RalfJung,oli-obkMatthias Krüger-1/+1
Fix async closures in CTFE First commit renames `is_coroutine_or_closure` into `is_closure_like`, because `is_coroutine_or_closure_or_coroutine_closure` seems confusing and long. Second commit fixes some forgotten cases where we want to handle `TyKind::CoroutineClosure` the same as closures and coroutines. The test exercises the change to `ValidityVisitor::aggregate_field_path_elem` which is the source of #120946, but not the change to `UsedParamsNeedSubstVisitor`, though I feel like it's not that big of a deal. Let me know if you'd like for me to look into constructing a test for the latter, though I have no idea what it'd look like (we can't assert against `TooGeneric` anywhere?). Fixes #120946 r? oli-obk cc ``@RalfJung``
2024-02-12Teach llvm backend how to fall back to default bodiesOli Scherer-5/+10
2024-02-12Stop calling `impl_polarity` when `impl_trait_ref` was also calledOli Scherer-7/+6
2024-02-12Dejargnonize substShoyu Vanilla-5/+5
2024-02-11is_closure_likeMichael Goulet-1/+1
2024-02-11Rollup merge of #120773 - Enselic:copy-vs-move, r=oli-obkMatthias Krüger-1/+9
large_assignments: Allow moves into functions Moves into functions are typically implemented with pointer passing rather than memcpy's at the llvm-ir level, so allow moves into functions. Part of the "Differentiate between Operand::Move and Operand::Copy" step of https://github.com/rust-lang/rust/issues/83518. r? `@oli-obk` (who I think is still E-mentor?)
2024-02-10large_assignments: Allow moves into functionsMartin Nordholts-1/+9
Moves into functions are typically implemented with pointer passing rather than memcpy's at the llvm-ir level, so allow moves into functions.
2024-02-09Rollup merge of #120693 - nnethercote:invert-diagnostic-lints, r=davidtwcoMatthias Krüger-2/+0
Invert diagnostic lints. That is, change `diagnostic_outside_of_impl` and `untranslatable_diagnostic` from `allow` to `deny`, because more than half of the compiler has been converted to use translated diagnostics. This commit removes more `deny` attributes than it adds `allow` attributes, which proves that this change is warranted. r? ````@davidtwco````
2024-02-06Rollup merge of #120602 - klensy:mono-comment, r=nnethercoteMatthias Krüger-1/+1
rustc_monomorphize: fix outdated comment in partition `max_cgu_count` was removed in https://github.com/rust-lang/rust/commit/51821515b3ccd7dd8f42ffd6a2eee536dcf7ddb0, but not comment (usage in `merge_codegen_units` was removed earlier). r? `@nnethercote`
2024-02-06Fix drop shim for AsyncFnOnce closure, AsyncFnMut shim for AsyncFn closureMichael Goulet-3/+3
2024-02-06Construct body for by-move coroutine closure outputMichael Goulet-2/+5
2024-02-06Build a shim to call async closures with different AsyncFn trait kindsMichael Goulet-0/+3
2024-02-06Invert diagnostic lints.Nicholas Nethercote-2/+0
That is, change `diagnostic_outside_of_impl` and `untranslatable_diagnostic` from `allow` to `deny`, because more than half of the compiler has be converted to use translated diagnostics. This commit removes more `deny` attributes than it adds `allow` attributes, which proves that this change is warranted.
2024-02-03rustc_monomorphize: fix outdated comment in partitionklensy-1/+1
2024-01-25Remove unused featuresclubby789-1/+0
2024-01-25Rollup merge of #119895 - oli-obk:track_errors_3, r=matthewjasperMatthias Krüger-3/+10
Remove `track_errors` entirely follow up to https://github.com/rust-lang/rust/pull/119869 r? `@matthewjasper` There are some diagnostic changes adding new diagnostics or not emitting some anymore. We can improve upon that in follow-up work imo.
2024-01-23Rollup merge of #120139 - compiler-errors:fnonce-shim, r=BoxyUwULeón Orell Valerian Liehr-2/+1
Do not normalize closure signature when building `FnOnce` shim It is not necessary to normalize the closure signature when building an `FnOnce` shim for an `Fn`/`FnMut` closure. That closure shim is just calling `FnMut::call_mut(&mut self)` anyways. It's also somewhat sketchy that we were ever doing this to begin with, since we're normalizing with a `ParamEnv::reveal_all()` param-env, which is definitely not right with possibly polymorphic substs. This cuts out a tiny bit of unnecessary work in `Instance::resolve` and simplifies the signature because now we can unconditionally return an `Instance`.
2024-01-23Remove track_errors entirelyOli Scherer-3/+10
2024-01-23Rename `TyCtxt::emit_spanned_lint` as `TyCtxt::emit_node_span_lint`.Nicholas Nethercote-1/+1
2024-01-22Do not normalize closure signature when building FnOnce shimMichael Goulet-2/+1
2024-01-21Rollup merge of #118811 - EbbDrop:is-sorted-by-bool, r=Mark-SimulacrumNadrieril-2/+2
Use `bool` instead of `PartiolOrd` as return value of the comparison closure in `{slice,Iteraotr}::is_sorted_by` Changes the function signature of the closure given to `{slice,Iteraotr}::is_sorted_by` to return a `bool` instead of a `PartiolOrd` as suggested by the libs-api team here: https://github.com/rust-lang/rust/issues/53485#issuecomment-1766411980. This means these functions now return true if the closure returns true for all the pairs of values.
2024-01-20Use bool instead of PartiolOrd in is_sorted_byEbbDrop-2/+2
2024-01-17Make crate_inherent_impls fallible and stop using `track_errors` for itOli Scherer-1/+1
2024-01-15large_assignments: Lint on specific large args passed to functionsMartin Nordholts-39/+65
2024-01-15compiler: Lower fn call arg spans down to MIRMartin Nordholts-2/+2
To enable improved accuracy of diagnostics in upcoming commits.
2024-01-10Stop mentioning internal lang items in no_std binary errorsNilstrieb-2/+9
When writing a no_std binary, you'll be greeted with nonsensical errors mentioning lang items like eh_personality and start. That's pretty bad because it makes you think that you need to define them somewhere! But oh no, now you're getting the `internal_features` lint telling you that you shouldn't use them! But you need a no_std binary! What now? No problem! Writing a no_std binary is super easy. Just use panic=abort and supply your own platform specific entrypoint symbol (like `main`) and you're good to go. Would be nice if the compiler told you that, right? This makes it so that it does do that.
2024-01-10Rename `{create,emit}_warning` as `{create,emit}_warn`.Nicholas Nethercote-1/+1
For consistency with `warn`/`struct_warn`, and also `{create,emit}_err`, all of which use an abbreviated form.
2024-01-05Rollup merge of #119538 - nnethercote:cleanup-errors-5, r=compiler-errorsMichael Goulet-1/+1
Cleanup error handlers: round 5 More rustc_errors cleanups. A sequel to https://github.com/rust-lang/rust/pull/119171. r? ````@compiler-errors````
2024-01-03Rename some `Diagnostic` setters.Nicholas Nethercote-1/+1
`Diagnostic` has 40 methods that return `&mut Self` and could be considered setters. Four of them have a `set_` prefix. This doesn't seem necessary for a type that implements the builder pattern. This commit removes the `set_` prefixes on those four methods.
2023-12-30is_coroutine -> is_coroutine_or_closureMichael Goulet-1/+4
2023-12-24Remove more `Session` methods that duplicate `DiagCtxt` methods.Nicholas Nethercote-1/+1
2023-12-24Remove `Session` methods that duplicate `DiagCtxt` methods.Nicholas Nethercote-10/+10
Also add some `dcx` methods to types that wrap `TyCtxt`, for easier access.
2023-12-19Add `level` arg to `into_diagnostic`.Nicholas Nethercote-8/+5
And make all hand-written `IntoDiagnostic` impls generic, by using `DiagnosticBuilder::new(dcx, level, ...)` instead of e.g. `dcx.struct_err(...)`. This means the `create_*` functions are the source of the error level. This change will let us remove `struct_diagnostic`. Note: `#[rustc_lint_diagnostics]` is added to `DiagnosticBuilder::new`, it's necessary to pass diagnostics tests now that it's used in `into_diagnostic` functions.
2023-12-18Rename many `DiagCtxt` arguments.Nicholas Nethercote-2/+2
2023-12-18Rename `Session::span_diagnostic` as `Session::dcx`.Nicholas Nethercote-2/+2
2023-12-18Rename `Handler` as `DiagCtxt`.Nicholas Nethercote-1/+1
2023-12-15Auto merge of #118770 - saethlin:fix-inline-never-uses, r=nnethercotebors-3/+25
Fix cases where std accidentally relied on inline(never) This PR increases the power of `-Zcross-crate-inline-threshold=always` so that it applies through `#[inline(never)]`. Note that though this is called "cross-crate-inlining" in this case especially it is _just_ lazy per-CGU codegen. The MIR inliner and LLVM still respect the attribute as much as they ever have. Trying to bootstrap with the new `-Zcross-crate-inline-threshold=always` change revealed two bugs: We have special intrinsics `assert_inhabited`, `assert_zero_valid`, and `assert_mem_uniniitalized_valid` which codegen backends will lower to nothing or a call to `panic_nounwind`. Since we may not have any call to `panic_nounwind` in MIR but emit one anyway, we need to specially tell `MirUsedCollector` about this situation. `#[lang = "start"]` is special-cased already so that `MirUsedCollector` will collect it, but then when we make it cross-crate-inlinable it is only assigned to a CGU based on whether `MirUsedCollector` saw a call to it, which of course we didn't. --- I started looking into this because https://github.com/rust-lang/rust/pull/118683 revealed a case where we were accidentally relying on a function being `#[inline(never)]`, and cranking up cross-crate-inlinability seems like a way to find other situations like that. r? `@nnethercote` because I don't like what I'm doing to the CGU partitioning code here but I can't come up with something much better
2023-12-14Fix cases where std accidentally relied on inline(never)Ben Kimock-3/+25
2023-12-13Add unstable `-Zdefault-hidden-visibility` cmdline flag for `rustc`.Lukasz Anforowicz-1/+1
The new flag has been described in the Major Change Proposal at https://github.com/rust-lang/compiler-team/issues/656
2023-12-08Rollup merge of #118693 - saethlin:alignment-check-symbol-reachable, r=bjorn3Matthias Krüger-0/+3
Tell MirUsedCollector that the pointer alignment checks calls its panic symbol Fixes https://github.com/rust-lang/rust/pull/118683 (not an issue, but that PR is a basically a bug report) When we had `panic_immediate_abort` start adding `#[inline]` to this panic function, builds started breaking because we failed to write up the MIR assert terminator to the correct panic shim. Things happened to work before by pure luck because without this feature enabled, the function we're inserting calls to is `#[inline(never)]` so we always generated code for it. r? bjorn3
2023-12-07ctfe interpreter: extend provenance so that it can track whether a pointer ↵Ralf Jung-7/+7
is immutable
2023-12-06Tell MirUsedCollector that the pointer alignment checks calls its panic symbolBen Kimock-0/+3
2023-11-26merge `DefKind::Coroutine` into `DefKind::Closure`bohan-2/+2