Compiler error messages: reduce assertiveness of message E0384
This message is emitted as guidance by the compiler when a developer attempts to reassign a value to an immutable variable. Following the message will always currently work, but it may not always be the best course of action; following the 'consider ...' messaging pattern provides a hint to the developer that it could be wise to explore other alternatives.
Resolves#84144
rustdoc: Hide item contents, not items
This tweaks rustdoc to hide item contents instead of items, and only when there are too many of them.
This means that users will _always_ see the type parameters, and will _often_ see fields/etc as long as they are small. Traits have some heuristics for hiding only the methods or only the methods and the consts, since the associated types are super important.
I'm happy to play around with the heuristics here; we could potentially make it so that structs/enums/etc are always hidden but traits will try really hard to show type aliases.
This needs a test, but you can see it rendered at https://manishearth.net/sand/doc_render/bar/
<details>
<summary> Code example </summary>
```rust
pub struct PubStruct {
pub a: usize,
pub b: usize,
}
pub struct BigPubStruct {
pub a: usize,
pub b: usize,
pub c: usize,
pub d: usize,
pub e: usize,
pub f: usize,
}
pub union BigUnion {
pub a: usize,
pub b: usize,
pub c: usize,
pub d: usize,
pub e: usize,
pub f: usize,
}
pub union Union {
pub a: usize,
pub b: usize,
pub c: usize,
}
pub struct PrivStruct {
a: usize,
b: usize,
}
pub enum Enum {
A, B, C,
D {
a: u8,
b: u8
}
}
pub enum LargeEnum {
A, B, C, D, E, F, G, H, I, J
}
pub trait Trait {
type A;
#[must_use]
fn foo();
fn bar();
}
pub trait GinormousTrait {
type A;
type B;
type C;
type D;
type E;
type F;
const N: usize = 1;
#[must_use]
fn foo();
fn bar();
}
pub trait HugeTrait {
type A;
const M: usize = 1;
const N: usize = 1;
const O: usize = 1;
const P: usize = 1;
const Q: usize = 1;
#[must_use]
fn foo();
fn bar();
}
pub trait BigTrait {
type A;
#[must_use]
fn foo();
fn bar();
fn baz();
fn quux();
fn frob();
fn greeble();
}
#[macro_export]
macro_rules! foo {
(a) => {a};
}
```
</details>
Fixes https://github.com/rust-lang/rust/issues/82114
Remove #[main] attribute.
This removes the #[main] attribute support from the compiler according to the decisions within #29634. For existing use cases within test harness generation, replaced it with a newly-introduced internal attribute `#[rustc_main]`.
This is first part extracted from #84062 .
Closes#29634.
r? `@petrochenkov`
Add simd_{round,trunc} intrinsics
LLVM supports many functions from math.h in its IR. Many of these
have SIMD instructions on various platforms. So, let's add round and
trunc so std::arch can use them.
Yes, exact comparison is intentional: rounding must always return a
valid integer-equal value, except for inf/NAN.
LLVM supports many functions from math.h in its IR. Many of these have
single-instruction variants on various platforms. So, let's add them so
std::arch can use them.
Yes, exact comparison is intentional: rounding must always return a
valid integer-equal value, except for inf/NAN.
add lint deref_nullptr detecting when a null ptr is dereferenced
fixes#83856
changelog: add lint that detect code like
```rust
unsafe {
&*core::ptr::null::<i32>()
};
unsafe {
addr_of!(std::ptr::null::<i32>())
};
let x: i32 = unsafe {*core::ptr::null()};
let x: i32 = unsafe {*core::ptr::null_mut()};
unsafe {*(0 as *const i32)};
unsafe {*(core::ptr::null() as *const i32)};
```
```
warning: Dereferencing a null pointer causes undefined behavior
--> src\main.rs:5:26
|
5 | let x: i32 = unsafe {*core::ptr::null()};
| ^^^^^^^^^^^^^^^^^^
| |
| a null pointer is dereferenced
| this code causes undefined behavior when executed
|
= note: `#[warn(deref_nullptr)]` on by default
```
Limitation:
It does not detect code like
```rust
const ZERO: usize = 0;
unsafe {*(ZERO as *const i32)};
```
or code where `0` is not directly a literal
rustdoc: links from items in a trait impl are inconsistent
Depending on where the struct implementing a trait is coming from, or the current page, the items in a trait impl are not linking to the same thing:
|item| trait page, implementors| trait page, implementations on Foreign Types|struct page, trait implementations|
|-|-|-|-|
|function| link to current impl|link to first impl in the list|link to trait def
|default function | not present |not present |link to trait def
|default function with custom impl|link to current impl|link to trait def |link to trait def
|constant| link to current impl|link to trait def |link to trait def
|associated type| link to current impl|link to trait def |link to trait def
||*missing link to trait def*|*function link wrong + missing link to current impl*|*missing link to current impl*|
<details>
<summary>rust code with those cases</summary>
```rust
pub trait MyTrait {
type Assoc;
const VALUE: u32;
fn trait_function(&self);
fn defaulted(&self) {}
fn defaulted_override(&self) {}
}
impl MyTrait for String {
/// will link to trait def
type Assoc = ();
/// will link to trait def
const VALUE: u32 = 5;
/// will link to first foreign implementor
fn trait_function(&self) {}
/// will link to trait def
fn defaulted_override(&self) {}
}
impl MyTrait for Vec<u8> {
/// will link to trait def
type Assoc = ();
/// will link to trait def
const VALUE: u32 = 5;
/// will link to first foreign implementor
fn trait_function(&self) {}
/// will link to trait def
fn defaulted_override(&self) {}
}
impl MyTrait for MyStruct {
/// in trait page, will link to current impl
///
/// in struct page, will link to trait def
type Assoc = bool;
/// in trait page, will link to current impl
///
/// in struct page, will link to trait def
const VALUE: u32 = 20;
/// in trait page, will link to current impl
///
/// in struct page, will link to trait def
fn trait_function(&self) {}
/// in trait page, will link to current impl
///
/// in struct page, will link to trait def
fn defaulted_override(&self) {}
}
pub struct MyStruct;
```
</details>
In this PR, I fixed all links to target the trait definition, and added an anchor-link to the current implementation appearing on mouse hover.
Fix typo in error message
Also tweaked the message a bit by
- removing the hyphen, because in my opinion the hyphen makes the
message a bit harder to read, especially combined with the backticks;
- adding the word "be", because I think it's a bit clearer that way.
Check for asm support in UI tests that require it
Add `needs-asm-support` compiletest directive, and use it in asm tests
that require asm support without relying on any architecture specific
features.
Closes#84038.
This message is emitted as guidance by the compiler when a developer attempts to reassign a value to an immutable variable. Following the message will always currently work, but it may not always be the best course of action; following the 'consider ...' messaging pattern provides a hint to the developer that it could be wise to explore other alternatives.
Also tweaked the message a bit by
- removing the hyphen, because in my opinion the hyphen makes the
message a bit harder to read, especially combined with the backticks;
- adding the word "be", because I think it's a bit clearer that way.
Improve trait/impl method discrepancy errors
* Use more accurate spans
* Clean up some code by removing previous hack
* Provide structured suggestions
Structured suggestions are particularly useful for cases where arbitrary self types are used, like in custom `Future`s, because the way to write `self: Pin<&mut Self>` is not necessarily self-evident when first encountered.
Issue 81508 fix
Fix#81508
**Problem**: When variable name is used incorrectly as path, error and warning point to undeclared/unused name, when in fact the name is used, just incorrectly (should be used as a variable, not part of a path).
**Summary for fix**: When path resolution errs, diagnostics checks for variables in ```ValueNS``` that have the same name (e.g., variable rather than path named Foo), and adds additional suggestion that user may actually intend to use the variable name rather than a path.
The fix does not suppress or otherwise change the *warning* that results. I did not find a straightforward way in the code to modify this, but would love to make changes here as well with any guidance.
Implement token-based handling of attributes during expansion
This PR modifies the macro expansion infrastructure to handle attributes
in a fully token-based manner. As a result:
* Derives macros no longer lose spans when their input is modified
by eager cfg-expansion. This is accomplished by performing eager
cfg-expansion on the token stream that we pass to the derive
proc-macro
* Inner attributes now preserve spans in all cases, including when we
have multiple inner attributes in a row.
This is accomplished through the following changes:
* New structs `AttrAnnotatedTokenStream` and `AttrAnnotatedTokenTree` are introduced.
These are very similar to a normal `TokenTree`, but they also track
the position of attributes and attribute targets within the stream.
They are built when we collect tokens during parsing.
An `AttrAnnotatedTokenStream` is converted to a regular `TokenStream` when
we invoke a macro.
* Token capturing and `LazyTokenStream` are modified to work with
`AttrAnnotatedTokenStream`. A new `ReplaceRange` type is introduced, which
is created during the parsing of a nested AST node to make the 'outer'
AST node aware of the attributes and attribute target stored deeper in the token stream.
* When we need to perform eager cfg-expansion (either due to `#[derive]` or `#[cfg_eval]`), we tokenize and reparse our target, capturing additional information about the locations of `#[cfg]` and `#[cfg_attr]` attributes at any depth within the target. This is a performance optimization, allowing us to perform less work in the typical case where captured tokens never have eager cfg-expansion run.
This PR modifies the macro expansion infrastructure to handle attributes
in a fully token-based manner. As a result:
* Derives macros no longer lose spans when their input is modified
by eager cfg-expansion. This is accomplished by performing eager
cfg-expansion on the token stream that we pass to the derive
proc-macro
* Inner attributes now preserve spans in all cases, including when we
have multiple inner attributes in a row.
This is accomplished through the following changes:
* New structs `AttrAnnotatedTokenStream` and `AttrAnnotatedTokenTree` are introduced.
These are very similar to a normal `TokenTree`, but they also track
the position of attributes and attribute targets within the stream.
They are built when we collect tokens during parsing.
An `AttrAnnotatedTokenStream` is converted to a regular `TokenStream` when
we invoke a macro.
* Token capturing and `LazyTokenStream` are modified to work with
`AttrAnnotatedTokenStream`. A new `ReplaceRange` type is introduced, which
is created during the parsing of a nested AST node to make the 'outer'
AST node aware of the attributes and attribute target stored deeper in the token stream.
* When we need to perform eager cfg-expansion (either due to `#[derive]` or `#[cfg_eval]`),
we tokenize and reparse our target, capturing additional information about the locations of
`#[cfg]` and `#[cfg_attr]` attributes at any depth within the target.
This is a performance optimization, allowing us to perform less work
in the typical case where captured tokens never have eager cfg-expansion run.
