| Age | Commit message (Collapse) | Author | Lines |
|---|
|
rustc_driver cleanup
Best reviewed one commit at a time.
|
|
The spans generated by `quote!` are (intentionally) no longer all the
same, so I removed that check entirely.
|
|
This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:
```
error[E0412]: cannot find type `MissingType` in this scope
--> $DIR/auxiliary/span-from-proc-macro.rs:37:20
|
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
| ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL | field: MissingType
| ^^^^^^^^^^^ not found in this scope
|
::: $DIR/span-from-proc-macro.rs:8:1
|
LL | #[error_from_attribute]
| ----------------------- in this macro invocation
```
Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`
This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.
This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
macro to get run. This saves all of the sapns in the input to `quote!`
into the metadata of *the proc-macro-crate* (which we are currently
compiling). The `quote!` macro then expands to a call to
`proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.
The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.
This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`
Custom quoting currently has a few limitations:
In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.
Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.
|
|
r=tmandry
Revert "Auto merge of #84797 - richkadel:cover-unreachable-statements…
This reverts commit e5f83d24aee866a14753a7cedbb4e301dfe5bef5, reversing
changes made to ac888e8675182c703c2cd097957878faf88dad94.
See https://github.com/rust-lang/rust/pull/84797#issuecomment-839068132
r? `@tmandry`
|
|
r=Mark-Simulacrum
Improve rustdoc gui tester
I cherry-picked the commit from https://github.com/rust-lang/rust/pull/84834 (and modified it a bit). I also used this opportunity to update it to last version (forgot to update GUI test in https://github.com/rust-lang/rust/pull/85074, really can't wait to make https://github.com/rust-lang/rust/pull/84586 finally work).
cc `@Mark-Simulacrum` for the changes in bootstrap.
r? `@jsha`
|
|
Use .name_str() to format primitive types in error messages
This pull request fixes #84976. The problem described there is caused by this code
https://github.com/rust-lang/rust/blob/506e75cbf8cb5305e49a41326307004ca3976029/compiler/rustc_middle/src/ty/error.rs#L161-L166
using `Debug` formatting (`{:?}`), while the proper solution is to call `name_str()` of `ty::IntTy`, `ty::UintTy` and `ty::FloatTy`, respectively.
|
|
shrinking the deprecated method span
close https://github.com/rust-lang/rust/issues/84637
|
|
rustdoc: Add unstable CLI option to show basic type layout information
Closes #75988.
Right now it just shows the size.
|
|
|
|
r=tmandry"
This reverts commit e5f83d24aee866a14753a7cedbb4e301dfe5bef5, reversing
changes made to ac888e8675182c703c2cd097957878faf88dad94.
|
|
|
|
for more libraries
|
|
There are issues with computing layout for type aliases; see #85103.
Once the issues are fixed, we should re-enable layout docs for them.
|
|
This should prevent confusion about why generic types don't have layout
docs.
|
|
|
|
|
|
|
|
At first you might think "why not just click through to the aliased
type?", but if a type alias instantiates all of the generic parameters
of the aliased type, then it can show layout info even though the
aliased type cannot (because we can't compute the layout of a generic
type). So I think it's still useful to show layout info for type
aliases.
|
|
|
|
Improve diagnostics for GATs
Fixes https://github.com/rust-lang/rust/issues/81801
Fixes https://github.com/rust-lang/rust/issues/81961
Fixes https://github.com/rust-lang/rust/issues/81862
r? `@estebank`
|
|
|
|
array-to-raw-elem cast: test that Retag covers entire array
Make sure that we `Retag` *before* doing the `ArrayToPointer` cast.
|
|
|
|
remove const_fn feature gate
Fixes https://github.com/rust-lang/rust/issues/84510
r? `@oli-obk`
|
|
Fix invalid suggestion of changing impl trait signature
Fix #68049
|
|
Emit errors/warns on some wrong uses of rustdoc attributes
This PR adds a few diagnostics:
- error if conflicting `#[doc(inline)]`/`#[doc(no_inline)]` are found
- introduce the `invalid_doc_attributes` lint (warn-by-default) which triggers:
- if a crate-level attribute is used on a non-`crate` item
- if `#[doc(inline)]`/`#[doc(no_inline)]` is used on a non-`use` item
The code could probably be improved but I wanted to get feedback first. Also, some of those changes could be considered breaking changes, so I don't know what the procedure would be? ~~And finally, for the warnings, they are currently hard warnings, maybe it would be better to introduce a lint?~~ (EDIT: introduced the `invalid_doc_attributes` lint)
Closes #80275.
r? `@jyn514`
|
|
|
|
Fix stack overflow when checking for structural recursion
This pull request aims to fix #74224 and fix #84611. The current logic for detecting ADTs with structural recursion is flawed because it only looks at the root type, and then for exact matches. What I mean by this is that for examples such as:
```rust
struct A<T> {
x: T,
y: A<A<T>>,
}
struct B {
z: A<usize>
}
fn main() {}
```
When checking `A`, the compiler correctly determines that it has an infinite size (because the "root" type is `A`, and `A` occurs, albeit with different type arguments, as a nested type in `A`).
However, when checking `B`, it also recurses into `A`, but now `B` is the root type, and it only checks for _exact_ matches of `A`, but since `A` never precisely contains itself (only `A<A<T>>`, `A<A<A<T>>>`, etc.), an endless recursion ensues until the stack overflows.
In this PR, I have attempted to fix this behavior by implementing a two-phase checking: When checking `B`, my code first checks `A` _separately_ and stops if `A` already turns out to be infinite. If not (such as for `Option<T>`), the second phase checks whether the root type (`B`) is ever nested inside itself, e.g.:
```rust
struct Foo { x: Option<Option<Foo>> }
```
Special care needs to be taken for mutually recursive types, e.g.:
```rust
struct A<T> {
z: T,
x: B<T>,
}
struct B<T> {
y: A<T>
}
```
Here, both `A` and `B` both _are_ `SelfRecursive` and _contain_ a recursive type. The current behavior, which I have maintained, is to treat both `A` and `B` as `SelfRecursive`, and accordingly report errors for both.
|
|
Fix source code line number display and make it clickable again
Fixes https://github.com/rust-lang/rust/issues/85119.
I used the same logic we're using for other codeblocks: putting the line number `<span>`s into the `example-wrap` directly and then add `display: inline-flex` on `example-wrap`.
r? `@jsha`
|
|
|
|
ensure failing promoteds in const/static bodies are handled correctly
`const`/`static` bodies are the one case where we still promote code that might fail to evaluate. Ensure that this is handled correctly; in particular, it must not fail compilation.
`src/test/ui/consts/const-eval/erroneous-const.rs` ensures that when a non-promoted fails to evaluate, we *do* show an error.
r? `@oli-obk`
|
|
Improve "panic message is not a string literal" warning
This warning always referenced panic! even in case of an
assert. Related to #84656
|
|
Fix suggestions for missing return type lifetime specifiers
This pull request aims to fix #84592. The issue is that the current code seems to assume that there is only a single relevant span pointing to the missing lifetime, and only looks at the first one:
https://github.com/rust-lang/rust/blob/e5f83d24aee866a14753a7cedbb4e301dfe5bef5/compiler/rustc_resolve/src/late/lifetimes.rs#L2959
This is incorrect, though, and leads to incorrect error messages and invalid suggestions. For instance, the example from #84592:
```rust
struct TwoLifetimes<'x, 'y> {
x: &'x (),
y: &'y (),
}
fn two_lifetimes_needed(a: &(), b: &()) -> TwoLifetimes<'_, '_> {
TwoLifetimes { x: &(), y: &() }
}
```
currently leads to:
```
error[E0106]: missing lifetime specifiers
--> src/main.rs:6:57
|
6 | fn two_lifetimes_needed(a: &(), b: &()) -> TwoLifetimes<'_, '_> {
| --- --- ^^ expected 2 lifetime parameters
|
= help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `a` or `b`
help: consider introducing a named lifetime parameter
|
6 | fn two_lifetimes_needed<'a>(a: &'a (), b: &'a ()) -> TwoLifetimes<'_<'a, 'a>, '_> {
| ^^^^ ^^^^^^ ^^^^^^ ^^^^^^^^^^
```
There are two problems:
- The error message is wrong. There is only _one_ lifetime parameter expected at the location pointed to by the error message (and another one at a separate location).
- The suggestion is incorrect and will not lead to correct code.
With the changes in this PR, I get the following output:
```
error[E0106]: missing lifetime specifiers
--> p.rs:6:57
|
6 | fn two_lifetimes_needed(a: &(), b: &()) -> TwoLifetimes<'_, '_> {
| --- --- ^^ ^^ expected named lifetime parameter
| |
| expected named lifetime parameter
|
= help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `a` or `b`
help: consider introducing a named lifetime parameter
|
6 | fn two_lifetimes_needed<'a>(a: &'a (), b: &'a ()) -> TwoLifetimes<'a, 'a> {
| ^^^^ ^^^^^^ ^^^^^^ ^^ ^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0106`.
```
Mainly, I changed `add_missing_lifetime_specifiers_label()` to receive a _vector_ of spans (and counts) instead of just one, and adjusted its body accordingly.
|
|
|
|
|
|
Migrate top doc and non-exhaustive toggles to details tag
Fixes #83332.
r? `@jsha`
|
|
Add primary marker on codegen unit and generate main wrapper on primary codegen.
This is the codegen part of changes extracted from #84062.
This add a marker called `primary` on each codegen units, where exactly one codegen unit will be `primary = true` at a time. This specific codegen unit will take charge of generating `main` wrapper when `main` is imported from a foreign crate after the implementation of RFC 1260.
cc #28937
I'm not sure who should i ask for review for codegen changes, so feel free to reassign.
r? `@nagisa`
|
|
|
|
|
|
Improve support for NewPM
This adds various missing bits of support for NewPM and allows us to successfully run stage 2 tests with NewPM enabled.
This does not yet enable NewPM by default, as there are still known issue on LLVM 12 (such as a weak fat LTO pipeline). The plan is to make the switch after we update to LLVM 13.
|
|
This warning always referenced panic! even in case of an
assert. Related to #84656
|
|
|
|
|
|
|
|
non-local cases.
|
|
|
|
Bump stdarch submodule
Major changes:
- More AVX-512 intrinsics.
- More ARM & AArch64 NEON intrinsics.
- Updated unstable WASM intrinsics to latest draft standards.
- Intrinsics that previously used `#[rustc_args_required_const]` now use const generics. See #83167 for more details.
- `std_detect` is now a separate crate instead of a submodule of `std`.
|
|
|
|
|
|
|
