| Age | Commit message (Collapse) | Author | Lines |
|---|
|
fix suggestion for unsized function parameters
taken from `@fasterthanlime's` article https://fasterthanli.me/articles/whats-in-the-box
|
|
Lower async fn in traits.
An error is already created by AST validation.
Fixes #84149
|
|
|
|
r=petrochenkov
Improve an error message.
|
|
Stablize `non-ascii-idents`
This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467).
r? `@Manishearth`
|
|
|
|
Don't set fast-math for the SIMD operations we set it for previously
Instead of `fast-math`. `fast-math` implies things like functions not
being able to accept as an argument or return as a result, say, `inf`
which made these functions confusingly named or behaving incorrectly,
depending on how you interpret it. It seems that the intended behaviour
was to set a `afn` flag instead. In doing so we also renamed the
intrinsics to say `_approx` so that it is clear these are not precision
oriented and the users can act accordingly.
Fixes #84268
|
|
Deprecate the core::raw / std::raw module
It only contains the `TraitObject` struct which exposes components of wide pointer. Pointer metadata APIs are designed to replace this: https://github.com/rust-lang/rust/issues/81513
|
|
Move some tests to more reasonable directories - 6
cc #73494
r? `@petrochenkov`
git mv bad/bad-const-type.* static/
git mv bad/bad-crate-name.* extern
git mv bad/bad-env-capture* fn/
git mv bad/bad-expr-lhs.* expr/
git mv bad/bad-expr-path* expr/
git mv bad/bad-extern-link-attrs.* extern/
git mv bad/bad-intrinsic-monomorphization.* intrinsics/
git mv bad/bad-lint-cap* lint/
git mv bad/bad-main.* fn
git mv bad/bad-method-typaram-kind.* type/
git mv bad/bad-mid-path-type-params.* fn
git mv bad/bad-module.* modules/
git mv bad/bad-sized.* type/
git mv bad/bad-type-env-capture.* fn
|
|
Do not ignore path segments in the middle in `#[allow]`/`#[warn]`/`#[deny]`/`#[forbid]` attributes
Fixes #83477.
|
|
|
|
`fast-math` implies things like functions not being able to accept as an
argument or return as a result, say, `inf` which made these functions
confusingly named or behaving incorrectly, depending on how you
interpret it. Since the time when these intrinsics have been implemented
the intrinsics user's (stdsimd) approach has changed significantly and
so now it is required that these intrinsics operate normally rather than
in "whatever" way.
Fixes #84268
|
|
rustdoc: Give a more accurate span for anchor failures
r? `@euclio`
|
|
rustdoc: use more precise relative URLs
This is a fairly large diff, and will probably conflict with https://github.com/rust-lang/rust/pull/82815 since it reduces (but does not eliminate) the use of the old depth variable.
Instead of using a depth counter and adding "../" to get to the top, this commit makes rustdoc actually compare the path of what it's linking from to the path that it's linking to. This makes the resulting HTML shorter.
Here's a comparison of one of the largest (non-source) files in the Rust standard library docs (about 4% improvement before gzipping).
$ wc -c struct.Wrapping.old.html struct.Wrapping.new.html
2387389 struct.Wrapping.old.html
2298538 struct.Wrapping.new.html
Most if it can be efficiently gzipped away.
$ wc -c struct.Wrapping.old.html.gz struct.Wrapping.new.html.gz
70679 struct.Wrapping.old.html.gz
70050 struct.Wrapping.new.html.gz
But it also makes a difference in the final DOM size, reducing it from 91MiB to 82MiB.
|
|
|
|
Instead of using a depth counter and adding "../" to get to the top,
this commit makes rustdoc actually compare the path of what it's
linking from to the path that it's linking to. This makes the resulting
HTML shorter.
Here's a comparison of one of the largest (non-source) files in the
Rust standard library docs (about 4% improvement before gzipping).
$ wc -c struct.Wrapping.old.html struct.Wrapping.new.html
2387389 struct.Wrapping.old.html
2298538 struct.Wrapping.new.html
Most if it can be efficiently gzipped away.
$ wc -c struct.Wrapping.old.html.gz struct.Wrapping.new.html.gz
70679 struct.Wrapping.old.html.gz
70050 struct.Wrapping.new.html.gz
But it also makes a difference in the final DOM size, reducing it from 91MiB to 82MiB.
|
|
Mark `has_global_allocator` query as `eval_always`
Fixes #84252
This query reads from untracked global state in `CStore`.
|
|
`#[allow]`/`#[warn]`/`#[deny]`/`#[forbid]` attributes
|
|
fix incomplete diagnostic notes when closure returns conflicting for genric type
fixes #84128
Correctly report the span on for conflicting return type in closures
|
|
Builtin derive macros: fix error with const generics default
This fixes a bug where builtin derive macros (like Clone, Debug) would basically copy-paste the default from a const generic, causing a compile error with very confusing message - it would say defaults are not allowed in impl blocks, while pointing at struct/enum/union definition.
|
|
Detect when suggested paths enter extern crates more rigorously
When reporting resolution errors, the compiler tries to avoid suggesting importing inaccessible paths from other crates. However, the search for suggestions only recognized when it was entering a crate root directly, and so failed to recognize a path like `crate::module::private_item`, where `module` was imported from another crate with `use other_crate::module`, as entering another crate.
Fixes #80079
Fixes #84081
|
|
rustdoc: clean up and test macro visibility print
This fixes the overly-complex invariant mentioned in <https://github.com/rust-lang/rust/pull/83237#issuecomment-815346570>, where the macro source can't have any links in it only because the cache hasn't been populated yet.
|
|
Fixes #84252
This query reads from untracked global state in `CStore`.
|
|
std: Add a variant of thread locals with const init
This commit adds a variant of the `thread_local!` macro as a new
`thread_local_const_init!` macro which requires that the initialization
expression is constant (e.g. could be stuck into a `const` if so
desired). This form of thread local allows for a more efficient
implementation of `LocalKey::with` both if the value has a destructor
and if it doesn't. If the value doesn't have a destructor then `with`
should desugar to exactly as-if you use `#[thread_local]` given
sufficient inlining.
The purpose of this new form of thread locals is to precisely be
equivalent to `#[thread_local]` on platforms where possible for values
which fit the bill (those without destructors). This should help close
the gap in performance between `thread_local!`, which is safe, relative
to `#[thread_local]`, which is not easy to use in a portable fashion.
|
|
This commit adds a variant of the `thread_local!` macro as a new
`thread_local_const_init!` macro which requires that the initialization
expression is constant (e.g. could be stuck into a `const` if so
desired). This form of thread local allows for a more efficient
implementation of `LocalKey::with` both if the value has a destructor
and if it doesn't. If the value doesn't have a destructor then `with`
should desugar to exactly as-if you use `#[thread_local]` given
sufficient inlining.
The purpose of this new form of thread locals is to precisely be
equivalent to `#[thread_local]` on platforms where possible for values
which fit the bill (those without destructors). This should help close
the gap in performance between `thread_local!`, which is safe, relative
to `#[thread_local]`, which is not easy to use in a portable fashion.
|
|
|
|
|
|
r=petrochenkov
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
|
|
Fix a couple resolve bugs from binder refactor
Fixes #83753
Fixes #83907
|
|
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`
|
|
Suggest to borrow after failing to cast from T to *const/mut T
Fixes #84213
|
|
|
|
|
|
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.
|
|
|
|
|
|
Fixes #84195
|
|
rustdoc: Note that forbidding anchors in links to primitives is a bug
cc https://github.com/rust-lang/rust/issues/83083, https://github.com/rust-lang/rust/pull/84147#discussion_r613518820
r? `@cuviper`
|
|
add more pat2021 tests
close https://github.com/rust-lang/rust/issues/84138
r? ```@nikomatsakis```
|
|
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.
|
|
Fix lookahead with None-delimited group
Fixes https://github.com/rust-lang/rust/issues/84162, a regression introduced by https://github.com/rust-lang/rust/pull/82608.
|
|
|
|
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.
|
|
|
|
|
|
Add explanatory note to `bare_urls` lint
I think the lint is confusing otherwise since it doesn't fully explain
what the problem is.
|
