| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=compiler-errors
Cleanup errors handlers even more
A sequel to #118587.
r? `@compiler-errors`
|
|
r=TaKO8Ki,GuillaumeGomez,workingjubilee
Add all known `target_feature` configs to check-cfg
This PR adds all the known `target_feature` from ~~`rustc_codegen_ssa`~~ `rustc_target` to the well known list of check-cfg.
It does so by moving the list from `rustc_codegen_ssa` to `rustc_target` ~~`rustc_session` (I not sure about this, but some of the moved function take a `Session`)~~, then using it the `fill_well_known` function.
This already proved to be useful since portable-simd had a bad cfg.
cc `@nnethercote` (since we discussed it in https://github.com/rust-lang/rust/pull/118494)
|
|
Currently, `emit_diagnostic` takes `&mut self`.
This commit changes it so `emit_diagnostic` takes `self` and the new
`emit_diagnostic_without_consuming` function takes `&mut self`.
I find the distinction useful. The former case is much more common, and
avoids a bunch of `mut` and `&mut` occurrences. We can also restrict the
latter with `pub(crate)` which is nice.
|
|
Compare `Handler::warn` and `Handler::span_warn`. Conceptually they are
almost identical. But their implementations are weirdly different.
`warn`:
- calls `DiagnosticBuilder::<()>::new(self, Warning(None), msg)`, then `emit()`
- which calls `G::diagnostic_builder_emit_producing_guarantee(self)`
- which calls `handler.emit_diagnostic(&mut db.inner.diagnostic)`
`span_warn`:
- calls `self.emit_diag_at_span(Diagnostic::new(Warning(None), msg), span)`
- which calls `self.emit_diagnostic(diag.set_span(sp))`
I.e. they both end up at `emit_diagnostic`, but take very different
routes to get there.
This commit changes `span_*` and similar ones to not use
`emit_diag_at_span`. Instead they just call `struct_span_*` + `emit`.
Some nice side-effects of this:
- `span_fatal` and `span_fatal_with_code` don't need
`FatalError.raise()`, because `emit` does that.
- `span_err` and `span_err_with_code` doesn't need `unwrap`.
- `struct_span_note`'s `span` arg type is changed from `Span` to
`impl Into<MultiSpan>` like all the other functions.
|
|
The `Handler` functions that directly emit diagnostics can be more
easily implemented using `struct_foo(msg).emit()`. This mirrors
`Handler::emit_err` which just does `create_err(err).emit()`.
`Handler::bug` is not converted because of weirdness involving
conflation bugs and fatal errors with `EmissionGuarantee`. I'll fix that
later.
|
|
To `msg: impl Into<DiagnosticMessage>`, like all the other diagnostics.
For consistency.
|
|
Rollup of 4 pull requests
Successful merges:
- #118910 ([rustdoc] Use Map instead of Object for source files and search index)
- #118914 (Unconditionally register alias-relate in projection goal)
- #118935 (interpret: extend comment on the inhabitedness check in downcast)
- #118945 (rustc_codegen_ssa: Remove trailing spaces in Display impl for CguReuse)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustc_codegen_ssa: Remove trailing spaces in Display impl for CguReuse
Otherwise errors will look like this:
error: CGU-reuse for `cgu_invalidated_via_import-bar` is `PreLto ` but should be `PostLto `
### Background
I noticed that error messages looked wonky while investigating if
https://github.com/rust-lang/rust/blob/529047cfc3f4f7b3ea5aaac054408f368d153727/compiler/rustc_codegen_ssa/src/assert_module_sources.rs#L281-L287
should not be wrapped by `sess.emit_err(...)`. Right now it looks like the error is accidentally ignored. It looks like https://github.com/rust-lang/rust/pull/100753/commits/706452eba74026c51e8d0fa30aee2497c69eafc0 might have accidentally started ignoring it (by removing the `diag.span_err()` call). I am still investigating, but regardless of the outcome we should fix the trailing whitespace.
|
|
interpret: extend comment on the inhabitedness check in downcast
Cc https://github.com/rust-lang/rust/issues/115145
r? ``@saethlin``
|
|
Add -Zunpretty=stable-mir output test
As strongly suggested here https://github.com/rust-lang/rust/pull/118364#issuecomment-1827974148 this adds output test for `-Zunpretty=stable-mir`, added test shows almost all the functionality of the current printer.
r? `@compiler-errors`
|
|
|
|
Otherwise errors will look like this:
error: CGU-reuse for `cgu_invalidated_via_import-bar` is `PreLto ` but should be `PostLto `
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
use c literals in compiler and library
Relands refreshed https://github.com/rust-lang/rust/pull/111647
|
|
Add unstable `-Zdefault-hidden-visibility` cmdline flag for `rustc`.
The new flag has been described in the Major Change Proposal at
https://github.com/rust-lang/compiler-team/issues/656
|
|
|
|
fix dynamic size/align computation logic for packed types with dyn trait tail
This logic was never updated to support `packed(N)` where `N > 1`, and it turns out to be wrong for that case.
Fixes https://github.com/rust-lang/rust/issues/80925
`@bjorn3` I have not looked at cranelift; I assume it basically copied the size-of-val logic and hence could use much the same patch.
|
|
It's unclear why this is used here. All entries in the third column of
`UNICODE_ARRAY` are covered by `ASCII_ARRAY`, so if the lookup fails
it's a genuine compiler bug. It was added way back in #29837, for no
clear reason.
This commit changes it to `span_bug`, which is more typical.
|
|
It's necessary for `derive(Diagnostic)`, but is best avoided elsewhere
because there are clearer alternatives.
This required adding `Handler::struct_almost_fatal`.
|
|
It has a single call site.
|
|
|
|
cache param env canonicalization
Canonicalize ParamEnv only once and store it. Then whenever we try to canonicalize `ParamEnvAnd<'tcx, T>` we only have to canonicalize `T` and then merge the results.
Prelimiary results show ~3-4% savings in diesel and serde benchmarks.
Best to review commits individually. Some commits have a short description.
Initial implementation had a soundness bug (https://github.com/rust-lang/rust/pull/117749#issuecomment-1840453387) due to cache invalidation:
- When canonicalizing `Ty<'?0>` we first try to resolve region variables in the current InferCtxt which may have a constraint `?0 == 'static`. This means that we register `Ty<'?0> => Canonical<Ty<'static>>` in the cache, which is obviously incorrect in another inference context.
- This is fixed by not doing region resolution when canonicalizing the query *input* (vs. response), which is the only place where ParamEnv is used, and then in a later commit we *statically* guard against any form of inference variable resolution of the cached canonical ParamEnv's.
r? `@ghost`
|
|
unused!
|
|
This doesn't change behavior.
It should prevent unintentional resolution of inference variables
during canonicalization, which previously caused a soundness bug.
See PR description for more.
|
|
Enable stack probes on aarch64 for LLVM 18
I tested this on `aarch64-unknown-linux-gnu` with LLVM main (~18).
cc #77071, to be closed once we upgrade our LLVM submodule.
|
|
When shortening types and writing them to disk, make `short_ty_string`
capable of reusing the same file, instead of writing a file per
shortened type.
|
|
The new flag has been described in the Major Change Proposal at
https://github.com/rust-lang/compiler-team/issues/656
|
|
Add more suggestions to unexpected cfg names and values
This pull request adds more suggestion to unexpected cfg names and values diagnostics:
- it first adds a links to the [rustc unstable book](https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/check-cfg.html) or the [Cargo reference](https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#check-cfg), depending if rustc is invoked by Cargo
- it secondly adds a suggestion on how to expect the cfg name or value:
*excluding well known names and values*
- for Cargo: it suggest using a feature or `cargo:rust-check-cfg` in build script
- for rustc: it suggest using `--check-cfg` (with the correct invocation)
Those diagnostics improvements are directed towards enabling users to fix the issue if the previous suggestions weren't good enough.
r? `@petrochenkov`
|
|
|
|
r=compiler-errors
Coroutine variant fields can be uninitialized
Wrap coroutine variant fields in MaybeUninit to indicate that they might be uninitialized. Otherwise an uninhabited field will make the entire variant uninhabited and introduce undefined behaviour.
The analogous issue in the prefix of coroutine layout was addressed by 6fae7f807146e400fa2bbd1c44768d9bcaa57c4c.
|
|
Support bare unit structs in destructuring assignments
We should be allowed to use destructuring assignments on *bare* unit structs, not just unit structs that are located within other pattern constructors.
Fixes #118753
r? petrochenkov since you reviewed #95380, reassign if you're busy or don't want to review this.
|
|
|
|
fixes a soundness regression described in the PR description.
|
|
|
|
ParamEnv is canonicalized in *queries input* rather than query response.
In such case we don't "preserve universes" of canonical variable.
This means that `universe_map` always has the default value, which is
wasteful to store in the cache.
|
|
|
|
rustc_passes: Enforce `rustc::potential_query_instability` lint
Stop allowing `rustc::potential_query_instability` in all of `rustc_passes` and instead allow it on a case-by-case basis if it is safe. In this case, all instances of the lint are safe to allow.
Part of https://github.com/rust-lang/rust/issues/84447 which is E-help-wanted.
|
|
Move some methods from `tcx.hir()` to `tcx`
https://github.com/rust-lang/rust/pull/118256#issuecomment-1826442834
Renamed:
- find -> opt_hir_node
- get -> hir_node
- find_by_def_id -> opt_hir_node_by_def_id
- get_by_def_id -> hir_node_by_def_id
|
|
codegen: panic when trying to compute size/align of extern type
The alignment is also computed when accessing a field of extern type at non-zero offset, so we also panic in that case.
Previously `size_of_val` worked because the code path there assumed that "thin pointer" means "sized". But that's not true any more with extern types. The returned size and align are just blatantly wrong, so it seems better to panic than returning wrong results. We use a non-unwinding panic since code probably does not expect size_of_val to panic.
|
|
[`RFC 3086`] Attempt to try to resolve blocking concerns
Implements what is described at https://github.com/rust-lang/rust/issues/83527#issuecomment-1744822345 to hopefully make some progress.
It is unknown if such approach is or isn't desired due to the lack of further feedback, as such, it is probably best to nominate this PR to the official entities.
`@rustbot` labels +I-compiler-nominated
|
|
Actually parse async gen blocks correctly
1. I got the control flow in `parse_expr_bottom` messed up, and obviously forgot a test for `async gen`, so we weren't actually ever parsing it correctly.
2. I forgot to gate the span for `async gen {}`, so even if we did parse it, we wouldn't have correctly denied it in `cfg(FALSE)`.
r? eholk
|
|
more clippy::complexity fixes
redundant_guards
redundant_slicing
filter_next
needless_borrowed_reference
useless_format
|
|
Typo
|
