Making ICEs and test them in incremental
This adds:
- A way to make the compiler ICE
- A way to check for ICE in `cfail` tests with `should-ice`
- A regression test for issue #65401
I am not sure the attribute added `should-ice` is the best for this job
Generate DWARF address ranges for faster lookups
This adds a new option `-Zgenerate-arange-section`, enabled by default,
corresponding to LLVM's `-generate-arange-section`. This creates a
`.debug_aranges` section with DWARF address ranges, which some tools
depend on to optimize address lookups (elfutils [22288], [25173]).
This only has effect when debuginfo is enabled, and the additional data
is small compared to the other debug sections. For example, libstd.so
with full debuginfo is about 11MB, with just 61kB in aranges.
[22288]: https://sourceware.org/bugzilla/show_bug.cgi?id=22288
[25173]: https://sourceware.org/bugzilla/show_bug.cgi?id=25173Closes#45246.
r? @michaelwoerister
Generic arg disambiguation
Using the tactic suggested by @petrochenkov in https://github.com/rust-lang/rust/issues/60804#issuecomment-516769465 and on [zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/generic.20argument.20disambiguation), this change checks type arguments to see if they are really incorrectly-parsed const arguments.
it should be noted that `segments.len() == 1 && segments[0].arg.is_none()` was reduced to `segments.len() == 1` as suggested by @petrochenkov in [zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/generic.20argument.20disambiguation/near/177848002). This change allowed a few more existing tests to have their braces removed.
There are a couple of "problems" with these changes that I should note. First, there was a regression in the error messages found in "src/test/ui/privacy-ns1.rs" and "src/test/ui/privacy-ns1.rs". Second, some braces were unable to be removed from "src/test/ui/const-generics/fn-const-param-infer.rs". Those on line 24 caused the statement to stop equating when removed, and those on line 20 cause a statement that should not equate to produce no error when removed.
I have not looked further into any of these issues yet, though I would be willing to look into them before landing this. I simply wanted to get some other eyes on this before going further.
Fixes#60804
cc @varkor @jplatte
Fix 'type annotations needed' error with opaque types
Related: #66426
This commit adds handling for opaque types during inference variable
fallback. Type variables generated from the instantiation of opaque
types now fallback to the opaque type itself.
Normally, the type variable for an instantiated opaque type is either
unified with the concrete type, or with the opaque type itself (e.g when
a function returns an opaque type by calling another function).
However, it's possible for the type variable to be left completely
unconstrained. This can occur in code like this:
```rust
pub type Foo = impl Copy;
fn produce() -> Option<Foo> {
None
}
```
Here, we'll instantatiate the `Foo` in `Option<Foo>` to a fresh type
variable, but we will never unify it with anything due to the fact
that we return a `None`.
This results in the error message:
```
type annotations needed: cannot resolve `_: std::marker::Copy
```
pointing at `pub type Foo = impl Copy`.
This message is not only confusing, it's incorrect. When an opaque type
inference variable is completely unconstrained, we can always fall back
to using the opaque type itself. This effectively turns that particular
use of the opaque type into a non-defining use, even if it appears in a
defining scope.
Suggest calling async closure when needed
When using an async closure as a value in a place that expects a future,
suggest calling the closure.
Fix#65923.
This adds a new option `-Zgenerate-arange-section`, enabled by default,
corresponding to LLVM's `-generate-arange-section`. This creates a
`.debug_aranges` section with DWARF address ranges, which some tools
depend on to optimize address lookups (elfutils [22288], [25173]).
This only has effect when debuginfo is enabled, and the additional data
is small compared to the other debug sections. For example, libstd.so
with full debuginfo is about 11MB, with just 61kB in aranges.
[22288]: https://sourceware.org/bugzilla/show_bug.cgi?id=22288
[25173]: https://sourceware.org/bugzilla/show_bug.cgi?id=25173Closes#45246.
Related: #66426
This commit adds handling for opaque types during inference variable
fallback. Type variables generated from the instantiatino of opaque
types now fallback to the opque type itself.
Normally, the type variable for an instantiated opaque type is either
unified with the concrete type, or with the opaque type itself (e.g when
a function returns an opaque type by calling another function).
However, it's possible for the type variable to be left completely
unconstrained. This can occur in code like this:
```rust
pub type Foo = impl Copy;
fn produce() -> Option<Foo> {
None
}
```
Here, we'll instantatiate the `Foo` in `Option<Foo>` to a fresh type
variable, but we will never unify it with anything due to the fact
that we return a `None`.
This results in the error message:
`type annotations needed: cannot resolve `_: std::marker::Copy``
pointing at `pub type Foo = impl Copy`.
This message is not only confusing, it's incorrect. When an opaque type
inference variable is completely unconstrained, we can always fall back
to using the opaque type itself. This effectively turns that particular
use of the opaque type into a non-defining use, even if it appears in a
defining scope.
Suggest borrowing when it would satisfy an unmet trait bound
When there are multiple implementors for the same trait that is present
in an unmet binding, modify the E0277 error to refer to the parent
obligation and verify whether borrowing the argument being passed in
would satisfy the unmet bound. If it would, suggest it.
Fix#56368.
Make dataflow-based const qualification the canonical one
For over a month, dataflow-based const qualification has been running in parallel with `qualify_consts` to check the bodies of `const` and `static`s. This PR removes the old qualification pass completely in favor of the dataflow-based one.
**edit:**
This PR also stops checking `QUALIF_ERROR_BIT` during promotion. This check appears to no longer serve a purpose now that the CTFE engine is more robust.
As a side-effect, this resolves#66167.
r? @eddyb
Derive TypeFoldable using a proc-macro
A new proc macro is added in librustc_macros.
It is used to derive TypeFoldable inside librustc and librustc_traits.
For now, the macro uses the `'tcx` lifetime implicitly, and does not allow for a more robust selection of the adequate lifetime.
The Clone-based TypeFoldable implementations are not migrated.
Closes#65674
Move `DIAGNOSTICS` usage to `rustc_driver`
Remove `rustc_interface`'s dependency on `rustc_error_codes` and centralize all usages of `DIAGNOSTICS` in `rustc_driver`. Once we remove all references to `rustc_error_codes` in all other crates but `rustc_driver`, this should allow for incremental recompilation of the compiler to be smoother when tweaking error codes. This works towards https://github.com/rust-lang/rust/issues/66210#issuecomment-551862528.
(May include traces of minor drive-by cleanup.)
r? @Mark-Simulacrum
rustc_plugin: Remove `Registry::register_attribute`
Legacy plugins cannot register inert attributes anymore.
The preferred replacement is to use `register_tool` ([tracking issue](https://github.com/rust-lang/rust/issues/66079)).
```rust
#![register_tool(servo)]
#[servo::must_root]
struct S;
```
The more direct replacement is `register_attribute` ([tracking issue](https://github.com/rust-lang/rust/issues/66080))
```rust
#![register_attr(must_root)]
#[must_root]
struct S;
```
, but it requires registering each attribute individually rather than registering the tool once, and is more likely to be removed rather than stabilized.
When there are multiple implementors for the same trait that is present
in an unmet binding, modify the E0277 error to refer to the parent
obligation and verify whether borrowing the argument being passed in
would satisfy the unmet bound. If it would, suggest it.
Update cc, git2, num_cpus.
This updates the `cc` crate, bringing in better parallel building support. Also updates `git2` which enables the parallel feature. (Note: I don't expect it will have a significant impact on build time, but seems good to update anyways.)
The main thorn is that `cc` gained knowledge about RISC-V architectures (https://github.com/alexcrichton/cc-rs/pull/428, https://github.com/alexcrichton/cc-rs/pull/429, https://github.com/alexcrichton/cc-rs/pull/430), but the builders on CI do not have the riscv C compiler installed. This means that bootstraps' cc detection was finding a C compiler that isn't installed, and fails.
The solution here is to override the cc detection to `false`. The C compiler isn't actually used on riscv platforms. AFAIK, the only location would be compiler_builtins, and it currently forces C support off (a533ae9c5a/build.rs (L49-L55)).
Other possible solutions:
- Add the override in cc_detect for riscv (or any "no-C" platform like wasm32 and nvptx)
- Install and use the appropriate c compiler. I tried this the `g++-riscv64-linux-gnu` package, but it failed missing some header file.
Closes#66232
Move the JSON error emitter to librustc_errors
This is done both as a cleanup (it makes little sense for this emitter to be in libsyntax), but also as part of broader work to decouple Session from librustc itself.
Along the way, this also moves SourceMap to syntax_pos, which is also nice for the above reasons, as well as allowing dropping the SourceMapper trait from code. This had the unfortunate side-effect of moving `FatalError` to rustc_data_structures (it's needed in syntax_pos, due to SourceMap, but putting it there feels somehow worse).
Push `ast::{ItemKind, ImplItemKind}::OpaqueTy` hack down into lowering
We currently have a hack in the form of `ast::{ItemKind, ImplItemKind}::OpaqueTy` which is constructed literally when you write `type Alias = impl Trait;` but not e.g. `type Alias = Vec<impl Trait>;`. Per https://github.com/rust-lang/rfcs/pull/2515, this needs to change to allow `impl Trait` in nested positions. This PR achieves this change for the syntactic aspect but not the semantic one, which will require changes in lowering and def collection. In the interim, `TyKind::opaque_top_hack` is introduced to avoid knock-on changes in lowering, collection, and resolve. These hacks can then be removed and fixed one by one until the desired semantics are supported.
r? @varkor
