`Res::SelfTy` currently has two `Option`s. When the second one is `Some`
the first one is never consulted. So we can split it into two variants,
`Res::SelfTyParam` and `Res::SelfTyAlias`, reducing the size of `Res`
from 24 bytes to 12. This then shrinks `hir::Path` and
`hir::PathSegment`, which are the HIR types that take up the most space.
Add `#[rustc_safe_intrinsic]`
This PR adds the `#[rustc_safe_intrinsic]` attribute as mentionned on Zulip. The goal of this attribute is to avoid keeping a list of symbols as the source for stable intrinsics, and instead rely on an attribute. This is similar to `#[rustc_const_stable]` and `#[rustc_const_unstable]`, which among other things, are used to mark the constness of intrinsic functions.
Since #72889, the Rust wasm target doesn't use --passive-segments, so
remove the `--export=__wasm_init_memory`.
As documented in the [tool-conventions Linking convention],
`__wasm_init_memory` is not intended to be exported.
[tool-conventions Linking convention]: 7c064f3048/Linking.md (shared-memory-and-passive-segments)
On targets with `default_hidden_visibility` set, which is currrently
just WebAssembly, declare the generated `main` function with visibility
hidden. This makes it consistent with clang's WebAssembly target, where
`main` is just a user function that gets the same visibility as any
other user function, which is hidden on WebAssembly unless explicitly
overridden.
This will help simplify use cases which in the future may want to
automatically wasm-export all visibility-"default" symbols. `main` isn't
intended to be wasm-exported, and marking it hidden prevents it from
being wasm-exported in that scenario.
Do not overwrite lifetime binders for another HirId.
This PR makes higher-ranked bounds in where clauses a bit more principled.
We used to conflate `for<'a> T: Trait` with `(for<'a> T): Trait`.
This PR separates both binders.
This caused issued with fn types, which have their own binder, causing us to overwrite the predicates's binders with `fn`'s binders, ICEing.
Fixes https://github.com/rust-lang/rust/issues/98594
Migrate more of rustc_parse to SessionDiagnostic
Still far from complete, but I thought I'd add a checkpoint here because rebasing was starting to get annoying.
Rollup of 8 pull requests
Successful merges:
- #100747 (Add long description and test for E0311)
- #102232 (Stabilize bench_black_box)
- #102288 (Suggest unwrapping `???<T>` if a method cannot be found on it but is present on `T`.)
- #102338 (Deny associated type bindings within associated type bindings)
- #102347 (Unescaping cleanups)
- #102348 (Tweak `FulfillProcessor`.)
- #102378 (Use already resolved `self_ty` in `confirm_fn_pointer_candidate`)
- #102380 (rustdoc: remove redundant mobile `.source > .sidebar` CSS)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Deny associated type bindings within associated type bindings
Fixes#102335
This was made worse by #100865, which unified the way we generate substs for GATs and non-generic associated types. However, the issue was not _caused_ by #100865, evidenced by the test I added for GATs:
```rust
trait T {
type A: S<C<(), i32 = ()> = ()>;
//~^ ERROR associated type bindings are not allowed here
}
trait Q {}
trait S {
type C<T>: Q;
}
fn main() {}
```
^ which passes on beta (where GATs are stable) and presumably ever since GATs support was added to `create_substs_for_associated_item` in astconv.
Suggest unwrapping `???<T>` if a method cannot be found on it but is present on `T`.
This suggests various ways to get inside wrapper types if the method cannot be found on the wrapper type, but is present on the wrappee.
For this PR, those wrapper types include `Localkey`, `MaybeUninit`, `RefCell`, `RwLock` and `Mutex`.
Stabilize bench_black_box
This PR stabilize `feature(bench_black_box)`.
```rust
pub fn black_box<T>(dummy: T) -> T;
```
The FCP was completed in https://github.com/rust-lang/rust/issues/64102.
`@rustbot` label +T-libs-api -T-libs
Rewrite and refactor format_args!() builtin macro.
This is a near complete rewrite of `compiler/rustc_builtin_macros/src/format.rs`.
This gets rid of the massive unmaintanable [`Context` struct](76531befc4/compiler/rustc_builtin_macros/src/format.rs (L176-L263)), and splits the macro expansion into three parts:
1. First, `parse_args` will parse the `(literal, arg, arg, name=arg, name=arg)` syntax, but doesn't parse the template (the literal) itself.
2. Second, `make_format_args` will parse the template, the format options, resolve argument references, produce diagnostics, and turn the whole thing into a `FormatArgs` structure.
3. Finally, `expand_parsed_format_args` will turn that `FormatArgs` structure into the expression that the macro expands to.
In other words, the `format_args` builtin macro used to be a hard-to-maintain 'single pass compiler', which I've split into a three phase compiler with a parser/tokenizer (step 1), semantic analysis (step 2), and backend (step 3). (It's compilers all the way down. ^^)
This can serve as a great starting point for https://github.com/rust-lang/rust/issues/99012, which will only need to change the implementation of 3, while leaving step 1 and 2 unchanged.
It also makes https://github.com/rust-lang/compiler-team/issues/541 easier, which could then upgrade the new `FormatArgs` struct to an `ast` node and remove step 3, moving that step to later in the compilation process.
It also fixes a few diagnostics bugs.
This also [significantly reduces](https://gist.github.com/m-ou-se/b67b2d54172c4837a5ab1b26fa3e5284) the amount of generated code for cases with arguments in non-default order without formatting options, like `"{1} {0}"` or `"{a} {}"`, etc.
`__heap_base` and `__data_end` are exported for use by wasm-bindgen, which
uses the wasm32-unknown-unknown target. On wasm32-wasi, as a step toward
implementing the Canonical ABI, and as an aid to building speicalized WASI
API polyfill wrappers, don't export `__heap_base` and `__data_end` on
wasm32-wasi.
- Rename `unescape_raw_str_or_raw_byte_str` as
`unescape_raw_str_or_byte_str`, which is more accurate.
- Remove the unused `Mode::in_single_quotes` method.
- Make some assertions more precise, and add a missing one to
`unescape_char_or_byte`.
- Change all the assertions to `debug_assert!`, because this code is
reasonably hot, and the assertions aren't required for memory safety,
and any violations are likely to be sufficiently obvious that normal
tests will trigger them.
`DefId` uses different field orders on 64-bit big-endian vs. others, in
order to optimize its `Hash` implementation. However, that also made it
derive different lexical ordering for `PartialOrd` and `Ord`. That
caused spurious differences wherever `DefId`s are sorted, like the
candidate sources list in `report_method_error`.
Now we manually implement `PartialOrd` and `Ord` on 64-bit big-endian to
match the same lexical ordering as other targets, fixing at least one
test, `src/test/ui/methods/method-ambig-two-traits-cross-crate.rs`.
session: remove now-unnecessary lint `#[allow]`s
In #101230, the internal diagnostic migration lints - `diagnostic_outside_of_impl` and `untranslatable_diagnostic` - were modified so that they wouldn't trigger on functions annotated with `#[rustc_lint_diagnostics]`. However, this change has to make it into the bootstrap compiler before the `#[allow]` annotations that it aims to remove can be removed, which is possible now that #102051 has landed.
Avoid LLVM-deprecated `Optional::hasValue`
LLVM 15 added `Optional::has_value`, and LLVM `main` (16) has deprecated
`hasValue`. However, its `explicit operator bool` does the same thing,
and was added long ago, so we can use that across our full LLVM range of
compatibility.
Sometimes it can happen that invalid code like a TyKind::Error makes
its way through the compiler without triggering any errors (this is
always a bug in rustc but bugs do happen sometimes :)). These ICEs
will manifest in the backend like as cg_llvm not being able to get
the layout of `[type error]`, which makes it hard to debug. By flushing
before codegen, we display all the delayed bugs, making it easier to
trace it to the root of the problem.
In #101230, the internal diagnostic migration lints -
`diagnostic_outside_of_impl` and `untranslatable_diagnostic` - were
modified so that they wouldn't trigger on functions annotated with
`#[rustc_lint_diagnostics]`. However, this change has to make it into
the bootstrap compiler before the `#[allow]` annotations that it aims to
remove can be removed, which is possible now that #102051 has landed.
Signed-off-by: David Wood <david.wood@huawei.com>
macros: diagnostic derive on enums
Part of #100717.
Extends `#[derive(Diagnostic)]` to work on enums too where each variant acts like a distinct diagnostic - being able to represent diagnostics this way can be quite a bit simpler for some parts of the compiler.
r? `@compiler-errors`
cc `@Xiretza`
LLVM 15 added `Optional::has_value`, and LLVM `main` (16) has deprecated
`hasValue`. However, its `explicit operator bool` does the same thing,
and was added long ago, so we can use that across our full LLVM range of
compatibility.
Rollup of 5 pull requests
Successful merges:
- #101875 (Allow more `!Copy` impls)
- #101996 (Don't duplicate region names for late-bound regions in print of Binder)
- #102181 (Add regression test)
- #102273 (Allow `~const` bounds on non-const functions)
- #102286 (Recover some items that expect braces and don't take semicolons)
Failed merges:
- #102314 (Add a label to struct/enum/union ident name)
r? `@ghost`
`@rustbot` modify labels: rollup
Allow more `!Copy` impls
You can already implement `!Copy` for a lot of types (with `#![feature(negative_impls)]`). However, before this PR you could not implement `!Copy` for ADTs whose fields don't implement `Copy` which didn't make any sense. Further, you couldn't implement `!Copy` for types impl'ing `Drop` (equally nonsensical).
``@rustbot`` label T-types F-negative_impls
Fixes#101836.
r? types
Fix lint scoping for let-else.
The scoping for let-else is inconsistent with HIR nesting. This creates cases, in `ui/let-else/let-else-allow-unused.rs` for instance, where an `allow` lint attribute does not apply to the bindings created by `let-else`.
This PR is an attempt to correct this.
As there is no lint that currently relies on this, the test for this behaviour is https://github.com/rust-lang/rust/pull/101500.
cc `@dingxiangfei2009` as you filed https://github.com/rust-lang/rust/pull/101894
Update bootstrap compiler to 1.65.0
This PR updates the bootstrap compiler to Rust 1.65.0, removing the various `cfg(bootstrap)`s.
r? `@Mark-Simulacrum`
Rollup of 5 pull requests
Successful merges:
- #102143 (Recover from struct nested in struct)
- #102178 (bootstrap: the backtrace feature is stable, no need to allow it any more)
- #102197 (Stabilize const `BTree{Map,Set}::new`)
- #102267 (Don't set RUSTC in the bootstrap build script)
- #102270 (Remove benches from `rustc_middle`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove benches from `rustc_middle`
These benches benchmark rust langauge features and not the compiler, so they seem to be in the wrong place here. They also all take <1ns, making them pretty useless. Looking at their git history, they just seem to have been carried around for many, many years. This commit ends their journey.
Stabilize const `BTree{Map,Set}::new`
The FCP was completed in #71835.
Since `len` and `is_empty` are not const stable yet, this also creates a new feature for them since they previously used the same `const_btree_new` feature.
`Cursor` keeps track of the position within the current token. But it
uses confusing names that don't make it clear that the "length consumed"
is just within the current token.
This commit renames things to make this clearer.
`Cursor` is currently hidden, and the main tokenization path uses
`rustc_lexer::first_token` which involves constructing a new `Cursor`
for every single token, which is weird. Also, `first_token` also can't
handle empty input, so callers have to check for that first.
This commit makes `Cursor` public, so `StringReader` can contain a
`Cursor`, which results in a simpler structure. The commit also changes
`StringReader::advance_token` so it returns an `Option<Token>`,
simplifying the the empty input case.
`TokenTreesReader` wraps a `StringReader`, but the `into_token_trees`
function obscures this. This commit moves to a more straightforward
control flow.
The spacing computation is done in two parts. In the first part
`next_token` and `bump` use `Spacing::Alone` to mean "preceded by
whitespace" and `Spacing::Joint` to mean the opposite. In the second
part `parse_token_tree_other` then adjusts the `spacing` value to mean
the usual thing (i.e. "is the following token joinable punctuation?").
This shift in meaning is very confusing and it took me some time to
understand what was going on.
This commit changes the first part to use a bool, and adds some
comments, which makes things much clearer.
Clean up (sub)diagnostic derives
The biggest chunk of this is unifying the parsing of subdiagnostic attributes (`#[error]`, `#[suggestion(...)]`, `#[label(...)]`, etc) between `Subdiagnostic` and `Diagnostic` type attributes as well as `Diagnostic` field attributes.
It also improves a number of proc macro diagnostics.
Waiting for #101558.
Use function pointers instead of macro-unrolled loops in rustc_query_impl
By making these standalone functions, we
a) allow making them extensible in the future with a new `QueryStruct`
b) greatly decrease the amount of code in each individual function, avoiding exponential blowup in llvm
Helps with https://github.com/rust-lang/rust/issues/96524. Based on https://github.com/rust-lang/rust/pull/101173; only the last commit is relevant.
r? `@cjgillot`
`parse_token_tree` is basically a match with four arms: `Eof`,
`OpenDelim`, `CloseDelim`, and "other". It has two call sites, and at
each call site one of the arms is unreachable. It's also not inlined.
This commit removes `parse_token_tree` by splitting it into four
functions and inlining them. This avoids some repeated conditional
tests and also some non-inlined function calls on the hot path.
Neither require nor imply lifetime bounds on opaque type for well formedness
The actual hidden type can live arbitrarily longer than any individual lifetime and arbitrarily shorter than all but one of the lifetimes.
fixes#86218fixes#84305
This is a **breaking change** but it is a necessary soundness fix
These benches benchmark rust langauge features and not the compiler,
so they seem to be in the wrong place here. They also all take <1ns,
making them pretty useless. Looking at their git history, they just
seem to have been carried around for many, many years. This commit
ends their journey.
By making these standalone functions, we
a) allow making them extensible in the future with a new `QueryStruct`
b) greatly decrease the amount of code in each individual function, avoiding exponential blowup in llvm
Rollup of 8 pull requests
Successful merges:
- #98111 (Clarify `[T]::select_nth_unstable*` return values)
- #101431 (Look at move place's type when suggesting mutable reborrow)
- #101800 (Constify slice.split_at_mut(_unchecked))
- #101997 (Remove support for legacy PM)
- #102194 (Note the type when unable to drop values in compile time)
- #102200 (Constify Default impl's for Arrays and Tuples.)
- #102245 (Constify cmp_min_max_by.)
- #102259 (Type-annotate and simplify documentation of Option::unwrap_or_default)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove support for legacy PM
This removes support for optimizing with LLVM's legacy pass manager, as well as the unstable `-Znew-llvm-pass-manager` option. We have been defaulting to the new PM since LLVM 13 (except for s390x that waited for 14), and LLVM 15 removed support altogether. The only place we still use the legacy PM is for writing the output file, just like `llc` does.
cc #74705
r? ``@nikic``
Look at move place's type when suggesting mutable reborrow
Not sure why we are looking at the use site's ty instead of the move site's ty in order to suggest reborrowing the move site, but it was suppressing a perfectly valid reborrow suggestion.
r? `@estebank` who i think touched this last in 520461f1fb, though that was quite a while ago so feel free to reassign.
Don't drop parent substs when we have no generic parameters in `create_substs_for_ast_path`
This bug is being shadowed by an explicit check for `generics.params.is_empty()` in the only parent caller that could trigger it (`create_substs_for_associated_item`). I triggered it on another branch where I'm messing around with astconv stuff.
Also, the second commit simplifies `create_substs_for_associated_item`. Removing that explicit check I mentioned above^ and also the special case call to `Astconv::prohibit_generics` causes the UI test `src/test/ui/structs/struct-path-associated-type.stderr` to change, but I think that it's clearer now. The suggestion to remove the generics is actually useful.
Resolve async fn signature even without body (e.g., in trait)
Fixes#102138
This "bail if no body" behavior was introduced in #69539 to fix#69401, but that ICE does not reproduce any more. The error message changes a bit, but that's all, and I don't think it's a particularly diagnostic bad regression.
implied_bounds: deal with inference vars
fixes#101951
while computing implied bounds for `<<T as ConstructionFirm>::Builder as BuilderFn<'_>>::Output` normalization replaces a projection with an inference var (adding a `Projection` obligation). Until we prove that obligation, this inference var remains unknown, which caused us to miss an implied bound necessary to prove that the unnormalized projection from the trait method signature is wf.
r? types
fix a ui test
use `into`
fix clippy ui test
fix a run-make-fulldeps test
implement `IntoQueryParam<DefId>` for `OwnerId`
use `OwnerId` for more queries
change the type of `ParentOwnerIterator::Item` to `(OwnerId, OwnerNode)`
resolve: Set effective visibilities for imports more precisely
Instead of setting them for all primary and additional IDs of the import, only set them for the binding's true ID.
Always print '_, even for erased lifetimes.
Explicit lifetime arguments are now the recommended syntax in rust 2018 and rust 2021. This PR applies this discipline to rustc itself.
Since `len` and `is_empty` are not const stable yet, this also
creates a new feature for them since they previously used the same
`const_btree_new` feature.
Introduce mir::Unevaluated
Previously the distinction between unevaluated constants in the type-system and in mir was not explicit and a little confusing. Probably better to introduce its own type for that.
r? `@lcnr`
Rollup of 8 pull requests
Successful merges:
- #100734 (Split out async_fn_in_trait into a separate feature)
- #101664 (Note if mismatched types have a similar name)
- #101815 (Migrated the rustc_passes annotation without effect diagnostic infrastructure)
- #102042 (Distribute rust-docs-json via rustup.)
- #102066 (rustdoc: remove unnecessary `max-width` on headers)
- #102095 (Deduplicate two functions that would soon have been three)
- #102104 (Set 'exec-env:RUST_BACKTRACE=0' in const-eval-select tests)
- #102112 (Allow full relro on powerpc64-unknown-linux-gnu)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Improve the help message for an invalid calling convention
Fixes https://github.com/rust-lang/rust/issues/93601
I mostly followed the suggestions of `@nagisa` in that issue, ~~however, I wasn't sure how to check stability for the suggestion of "Do not suggest CCs that cannot be used due to them being unstable and feature not being enabled", so I did not implement that point.~~
I haven't contributed to rustc much, please feel free to point out suggestions! For example, the `.map(|s| Symbol::intern(s)).collect::<Vec<_>>()` seems pretty gross performance-wise, but maybe that's OK in error reporting code.
Allow full relro on powerpc64-unknown-linux-gnu
This was previously limited to partial relro, citing issues on RHEL6,
but that's no longer a supported platform since #95026. We have long
been enabling full relro in RHEL7's own Rust builds for ppc64, without
trouble, so it should be fine to drop this workaround.
