| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Derive Lift using a proc-macro
Based on #66384
r? @Zoxc
|
|
Move the definition of `QueryResult` into `plumbing.rs`.
Because it's the only file that uses it, and removes the need for importing it.
r? @Centril
|
|
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.
|
|
Because it's the only file that uses it, and removes the need for
importing it.
|
|
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=25173
Closes #45246.
|
|
namespace
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 using an async closure as a value in a place that expects a future,
suggest calling the closure.
Fix #65923.
|
|
|
|
|
|
|
|
|
|
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 (https://github.com/rust-lang/compiler-builtins/blob/a533ae9c5aa325db209659679535fe1f186eae81/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
|
|
|
