Adds an unstable `extern "Swift"` ABI behind the `abi_swift` feature
gate, mapping to LLVM's `swiftcc` calling convention. Cranelift and
GCC backends fall back to the platform default since they have no
equivalent.
port `rustc_ast*` crates from `box_` to `deref_patterns`
Part of rust-lang/rust#156110, this ports the first few crates away from `box_patterns` to `deref_patterns`.
Move `feature*` methods from `parse` mod to `errors` mod.
As the FIXME comment says, these no longer use `ParseSess` and so the `parse` mod is not a good place for them. The `errors` mod is a better home.
r? @TaKO8Ki
`rustc_error_messages` currently depends on
`rustc_ast`/`rustc_ast_pretty`. This is odd, because
`rustc_error_messages` feels like a very low-level module but
`rustc_ast`/`rustc_ast_pretty` do not.
The reason is that a few AST types impl `IntoDiagArg` via
pretty-printing. `rustc_error_messages` can define `IntoDiagArg` and
then impl it for the AST types. But if we invert the dependency we hit
a problem with the orphan rule: `rustc_ast` must impl `IntoDiagArg`
for the AST types, but that requires calling pretty-printing code which
is in `rustc_ast_pretty`, a downstream crate.
This commit avoids this problem by just removing the `IntoDiagArg` impls
for these AST types. There aren't that many of them, and we can just use
`String` in the relevant error structs and use the pretty printer in the
downstream crates that construct the error structs. There are plenty of
existing examples where `String` is used in error structs.
There is now no dependency between `rustc_ast*` and
`rustc_error_messages`.
This PR introduces a `#[diagnostic::on_unknown_item]` attribute that
allows crate authors to customize the error messages emitted by
unresolved imports. The main usecase for this is using this attribute as
part of a proc macro that expects a certain external module structure to
exist or certain dependencies to be there.
For me personally the motivating use-case are several derives in diesel,
that expect to refer to a `tabe` module. That is done either
implicitly (via the name of the type with the derive) or explicitly by
the user. This attribute would allow us to improve the error message in
both cases:
* For the implicit case we could explicity call out our
assumptions (turning the name into lower case, adding an `s` in the end)
+ point to the explicit variant as alternative
* For the explicit variant we would add additional notes to tell the
user why this is happening and what they should look for to fix the
problem (be more explicit about certain diesel specific assumptions of
the module structure)
I assume that similar use-cases exist for other proc-macros as well,
therefore I decided to put in the work implementing this new attribute.
I would also assume that this is likely not useful for std-lib internal
usage.
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#154554 (emit error on `#[track_caller]` with `extern fn`)
- rust-lang/rust#154858 (Change api of formatting diagnostic attribute strings.)
- rust-lang/rust#154876 (attr parsing: make sure we pass the right target when errors could be emitted)
Scalable vector types in `core_arch` are cfg'd for aarch64 and for
rustdoc, which can successfully document these types given any `--target`
(`core_arch` CI uses `i686-unknown-linux-gnu`) - this shouldn't trigger
the "scalable vectors not supported on arch" error.
* utilize Kleene `?` two avoid having two macro matchers with almost
identical body
* inline `gate_legacy` since it only has one use and since it shouldn't
be used anywhere else anyway
* remove unnecessary explicit borrows of the visitor
* replace `if let Some(spans) = spans.get(…) { for span in …` with
`for &span in spans.get(…).into_iter().flatten()` to avoid rightward
drift and explicit dereferences
* rename `gate_all_legacy…` to `soft_gate_all_legacy…` since it's not a
"proper" gate that issues an error but merely one that emits a warning
specifically this emits an error when
- a custom target is used
- `RiscV32 if self.llvm_abiname == "ilp32e"` this abi is used for 32-bit
embedded targets, and clang/llvm document that the ABI may change in
the future.
Emit ForbiddenBound fatally if meeting complex bound
Fixes https://github.com/rust-lang/rust/issues/149695
---
Bounds in binders are denied, hir items won't contain and index them. But nested items in the bounds will still be lowered to hir. And their parents, i.e., the block in bounds is not in hir. So that ICE happens when error handling requires visiting hir parents.
~~This PR collects hirless def ids and skips them when iterating parents.~~
~~This PR checks such bounds used in higher ranked binders and emit error `ForbiddenBound` when parsing. And make sure no such bounds appear in hir.~~
This PR emits this error fatally if meeting complex bound.
Move `Spanned`.
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.
r? @JonathanBrouwer
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.
Emit an error when attempting to compile a `#[rustc_scalable_vector]`
type for a architecture that fundamentally doesn't support scalable
vectors. Ultimately this is just a diagnostic improvement for an internal
attribute as users should never be doing this.
Feature gate for defaulted associated type_consts with associated_type_defaults
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/152385)*
This PR for issue rust-lang/rust#130288 extends a feature gate that was already present for defaulted associated types to defaulted type consts under associated_type_defaults.
Code added:
```
if ctxt == AssocCtxt::Trait && rhs.is_some() {
gate!(
&self,
associated_type_defaults,
i.span,
"associated type defaults are unstable"
);
}
```
Error produced:
```
error[E0658]: associated type defaults are unstable
--> $DIR/type-const-associated-default.rs:4:5
|
LL | type const N: usize = 10;
| ^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #29661 <https://github.com/rust-lang/rust/issues/29661> for more information
= help: add `#![feature(associated_type_defaults)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
warning: the feature `min_generic_const_args` is incomplete and may not be safe to use and/or cause compiler crashes
--> $DIR/type-const-associated-default.rs:1:12
|
LL | #![feature(min_generic_const_args)]
| ^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #132980 <https://github.com/rust-lang/rust/issues/132980> for more information
= note: `#[warn(incomplete_features)]` on by default
error: aborting due to 1 previous error; 1 warning emitted
For more information about this error, try `rustc --explain E0658`.
```
Thanks to @BoxyUwU for the guidance on this issue.
Implement RFC 3678: Final trait methods
Tracking: https://github.com/rust-lang/rust/issues/131179
This PR is based on rust-lang/rust#130802, with some minor changes and conflict resolution.
Futhermore, this PR excludes final methods from the vtable of a dyn Trait.
And some excerpt from the original PR description:
> Implements the surface part of https://github.com/rust-lang/rfcs/pull/3678.
>
> I'm using the word "method" in the title, but in the diagnostics and the feature gate I used "associated function", since that's more accurate.
cc @joshtriplett
CoCo-Japan-pan