| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Bump the bootstrap compiler
|
|
expand: Implement something similar to `#[cfg(accessible(path))]`
cc https://github.com/rust-lang/rust/issues/64797
The feature is implemented as a `#[cfg_accessible(path)]` attribute macro rather than as `#[cfg(accessible(path))]` because it needs to wait until `path` becomes resolvable, and `cfg` cannot wait, but macros can wait.
Later we can think about desugaring or not desugaring `#[cfg(accessible(path))]` into `#[cfg_accessible(path)]`.
This implementation is also incomplete in the sense that it never returns "false" from `cfg_accessible(path)`, it requires some tweaks to resolve, which is not quite ready to answer queries like this during early resolution.
However, the most important part of this PR is not `cfg_accessible` itself, but expansion infrastructure for retrying expansions.
Before this PR we could say "we cannot resolve this macro path, let's try it later", with this PR we can say "we cannot expand this macro, let's try it later" as well.
This is a pre-requisite for
- turning `#[derive(...)]` into a regular attribute macro,
- properly supporting eager expansion for macros that cannot yet be resolved like
```
fn main() {
println!(not_available_yet!());
}
macro_rules! make_available {
() => { #[macro_export] macro_rules! not_available_yet { () => { "Hello world!" } }}
}
make_available!();
```
|
|
|
|
|
|
Implement a feature for a sound specialization subset
This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use.
The plan is to then:
* Update `libcore` and `liballoc` to compile with `min_specialization`.
* Add a lint to forbid use of `feature(specialization)` (and other unsound, type system extending features) in the standard library.
* Fix the soundness issues around `specialization`.
* Remove `min_specialization`
The rest of this is an overview from a comment in this PR
## Basic approach
To enforce this requirement on specializations we take the following approach:
1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`.
2. Check for any direct use of `'static` in the substs of `impl2`.
3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate.
4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs).
## Example
Suppose we have the following always applicable impl:
```rust
impl<T> SpecExtend<T> for std::vec::IntoIter<T> { /* specialized impl */ }
impl<T, I: Iterator<Item=T>> SpecExtend<T> for I { /* default impl */ }
```
We get that the subst for `impl2` are `[T, std::vec::IntoIter<T>]`. `T` is constrained to be `<I as Iterator>::Item`, so we check only `std::vec::IntoIter<T>` for repeated parameters, which it doesn't have. The predicates of `impl1` are only `T: Sized`, which is also a predicate of impl2`. So this specialization is sound.
## Extensions
Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits.
### rustc_specialization_trait
If a trait is always applicable, then it's sound to specialize on it. We check trait is always applicable in the same way as impls, except that step 4 is now "all predicates on `impl1` are always applicable". We require that `specialization` or `min_specialization` is enabled to implement these traits.
### rustc_specialization_marker
There are also some specialization on traits with no methods, including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can.
r? @nikomatsakis
cc #31844 #67194
|
|
|
|
it cant be called in ctfe yet
|
|
|
|
|
|
|
|
Add undo_leak to reset RefCell borrow state
This method is complementary for the feature cell_leak added in an
earlier PR. It allows *safely* reverting the effects of leaking a borrow guard by
statically proving that such a guard could not longer exist. This was
not added to the existing `get_mut` out of concern of impacting the
complexity of the otherwise pure pointer cast and because the name
`get_mut` poorly communicates the intent of resetting remaining borrows.
This is a follow-up to #68712 and uses the same tracking issue, #69099,
as these methods deal with the same mechanism and the idea came up
[in a review comment](https://github.com/rust-lang/rust/pull/68712#discussion_r384670041).
@dtolnay who reviewed the prior PR.
cc @RalfJung
|
|
|
|
Remove `sip::Hasher::short_write`.
`sip::Hasher::short_write` is currently unused. It is called by
`sip::Hasher::write_{u8,usize}`, but those methods are also unused,
because `DefaultHasher`, `SipHasher` and `SipHasher13` don't implement
any of the `write_xyz` methods, so all their write operations end up
calling `sip::Hasher::write`.
(I confirmed this by inserting a `panic!` in `sip::Hasher::short_write`
and running the tests -- they all passed.)
The alternative would be to add all the missing `write_xyz` methods.
This does give some significant speed-ups, but it hurts compile times a
little in some cases. See #69152 for details. This commit does the
conservative thing and doesn't change existing behaviour.
r? @rust-lang/libs
|
|
|
|
|
|
Optimize catch_unwind to match C++ try/catch
This refactors the implementation of catching unwinds to allow LLVM to inline the "try" closure directly into the happy path, avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown.
https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably, the codegen is *exactly the same* if `-Cpanic=abort` is passed, which is clearly not great.
This PR, on the other hand, generates the following assembly:
```asm
# -Cpanic=unwind:
push rbx
mov ebx,0x2a
call QWORD PTR [rip+0x1c53c] # <happy>
mov eax,ebx
pop rbx
ret
mov rdi,rax
call QWORD PTR [rip+0x1c537] # cleanup function call
call QWORD PTR [rip+0x1c539] # <unfortunate>
mov ebx,0xd
mov eax,ebx
pop rbx
ret
# -Cpanic=abort:
push rax
call QWORD PTR [rip+0x20a1] # <happy>
mov eax,0x2a
pop rcx
ret
```
Fixes #64224, and resolves #64222.
|
|
Update stable-since version for const_int_conversion
Since #69373 was not merged in time for 1.43.0 beta, update to `since = "1.44.0"`.
|
|
rename panic_if_ intrinsics to assert_
[Suggested by @eddyb](https://github.com/rust-lang/miri/issues/1222#issuecomment-598087523)
|
|
fix more clippy findings
* reduce references on match patterns (clippy::match_ref_pats)
* Use writeln!(fmt, "word") instead of write!(fmt, "word\n") (clippy::write_with_newline)
* libtest: remove redundant argument to writeln!() (clippy::writeln_empty_string)
* remove unneeded mutable references (cippy::unnecessary_mut_passed)
* libtest: declare variables as floats instead of casting them (clippy::unnecessary_cast)
* rustdoc: remove redundant static lifetimes (clippy::redundant_static_lifetimes)
* call .as_deref() instead of .as_ref().map(Deref::deref) (clippy::option_as_ref_deref)
* iterate over a maps values directly. (clippy::for_kv_map)
* rustdoc: simplify boolean condition (clippy::nonminimal_bool)
* Use ?-operator in more places (clippy::question_mark, had some false negatives fixed recently)
* rustdoc: Use .any(p) instead of find(p).is_some(). (clippy::search_is_some)
* rustdoc: don't call into_iter() on iterator. (clippy::identity_conversion)
|
|
|
|
|
|
Document unsafe blocks in core::fmt
r? @RalfJung
CC: @rust-lang/wg-unsafe-code-guidelines
#66219
Sorry for the hiatus, but here's a few more files with the unsafe blocks documented! I think working on it smaller chunks like this will be easier for everyone.
|
|
|
|
|
|
panic_bounds_check: use caller_location, like PanicFnLangItem
The `PanicFnLangItem` got switched to using `#[caller_location]` at some point, but `PanicBoundsCheckFnLangItem` was kept in the old style. For consistency, switch that one over to use `#[caller_location]` as well.
This is also helpful for Miri as it means the `assert_panic` machine hook never needs to know the current `Span`.
|
|
make `mem::discriminant` const
implements #69821, which could be used as a tracking issue for `const_discriminant`.
Should this be added to the meta tracking issue #57563?
@Lokathor
|
|
r=shepmaster
Make Point `Copy` in arithmetic documentation
Small composite types like `Point { x: i32, y: i32}` are plain
old data and we should encourage users to derive `Copy` on them.
This changes the semantics of the edited examples slightly: instead
of consuming the operands during addition, it will copy them. This
is desired behaviour.
|
|
const forget tests
Adds tests for https://github.com/rust-lang/rust/pull/69617
|
|
Implement nth, last, and count for iter::Copied
Implement nth, last and count for iter::Copied.
|
|
Stabilize const for integer {to,from}_{be,le,ne}_bytes methods
All of these functions can be implemented simply and naturally as const functions, e.g. `u32::from_le_bytes` can be implemented as
```rust
(bytes[0] as u32)
| (bytes[1] as u32) << 8
| (bytes[2] as u32) << 16
| (bytes[3] as u32) << 24
```
So stabilizing the constness will not expose that internally they are implemented using transmute which is not const in stable.
|
|
mem::zeroed/uninit: panic on types that do not permit zero-initialization
r? @eddyb @oli-obk
Cc https://github.com/rust-lang/rust/issues/62825
Also see [this summary comment](https://github.com/rust-lang/rust/pull/66059#issuecomment-586734747)
|
|
Small composite types like `Point { x: i32, y: i32}` are plain
old data and we should encourage users to derive `Copy` on them.
This changes the semantics of the edited examples slightly: instead
of consuming the operands during addition, it will copy them. This
is desired behaviour.
Co-Authored-By: Jake Goulding <shepmaster@mac.com>
|
|
|
|
Allow ZSTs in `AllocRef`
Allows ZSTs in all `AllocRef` methods. The implementation of `AllocRef` for `Global` and `System` were adjusted to reflect those changes.
This is the second item on the roadmap to support ZSTs in `AllocRef`: https://github.com/rust-lang/wg-allocators/issues/38#issuecomment-595861542
After this has landed, I will adapt `RawVec`, but since this will be a pretty big overhaul, it makes sense to do a different PR for it.
~~Requires #69794 to land first~~
r? @Amanieu
|
|
Remove spotlight
I had a few comments saying that this feature was at best misunderstood or not even used so I decided to organize a poll about on [twitter](https://twitter.com/imperioworld_/status/1232769353503956994). After 87 votes, the result is very clear: it's not useful. Considering the amount of code we have just to run it, I think it's definitely worth it to remove it.
r? @kinnison
cc @ollie27
|
|
|
|
|
|
Try to ensure usize marker does not get merged
This follows up on [this conversation](https://github.com/rust-lang/rust/pull/69209#discussion_r379911282). However, I'm not confident this is quite correct, so feedback is appreciated, as always.
|
|
|
|
|
|
|
|
negatives fixed recently)
|
|
Correct version that relaxed orphan rules
Docs say
> Prior to Rust 1.40, if the destination type was not part of the current crate then you couldn't implement From directly
Version 1.41 of Rust introduced the change to the orphan rules - https://blog.rust-lang.org/2020/01/30/Rust-1.41.0.html#relaxed-restrictions-when-implementing-traits - so this should say
> Prior to Rust 1.41...
|
|
Add `Layout::dangling()` to return a well-aligned `NonNull<u8>`
Adds a convenient function to `Layout` to create a `NonNull<u8>` out of a layout to be returned on ZST allocations.
This is the first item on the roadmap to support ZSTs in `AllocRef`: https://github.com/rust-lang/wg-allocators/issues/38#issuecomment-595861542
r? @Amanieu
|
|
fix various typos
|
|
|
|
Use subslice patterns in slice methods
For all of the methods that pick off the first or last element, we can
use subslice patterns to implement them directly, rather than relying on
deeper indexing function calls. At a minimum, this means the generated
code will rely less on inlining for performance, but in some cases it
also optimizes better.
|
|
|
|
|
|
|
