| 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
|
|
Enable sanitizers for x86_64-unknown-linux-musl
Those 4 sanitizers get musl target support in LLVM 12 release.
|
|
Introduce CompileMonoItem DepNode
This is likely required for allowing efficient hot code swap support in cg_clif's jit mode. My prototype currently requires re-compiling all functions, which is both slow and uses a lot of memory as there is not support for freeing the memory used by replaced functions yet.
cc https://github.com/bjorn3/rustc_codegen_cranelift/issues/1087
|
|
|
|
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
|
|
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
|
|
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
|
|
Fixes #84252
This query reads from untracked global state in `CStore`.
|
|
|
|
|
|
|
|
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
|
|
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
|
|
|
|
Track `-C link-dead-code` during incremental compilation
This option influences monomorphization, which participates in
incremental compilation.
|
|
|
|
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.
|
|
This option influences monomorphization, which participates in
incremental compilation.
|
|
Fixes #84195
|
|
Update docs for unsafe_op_in_unsafe_fn stability.
The unsafe_op_in_unsafe_fn lint was stabilized in #79208, but the bottom of this documentation wasn't updated.
I'm just guessing at the reason here, hopefully it is close to correct. The only discussion I found is https://github.com/rust-lang/rust/issues/71668#issuecomment-730399862 which didn't really explain the thought process behind the decision.
|
|
Fix typos in rustc_codegen_ssa/src/back/write.rs.
Just a couple of typos I spotted when reading this comment about the job server.
|
|
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
|
|
move new c abi abort behavior behind feature gate
*Background*
In #76570, new ABI strings including `C-unwind` were introduced. Their
behavior is specified in RFC 2945 <sup>[1]</sup>.
However, it was reported in the #ffi-unwind stream of the Rust community Zulip
that this had altered the way that `extern "C"` functions behaved even when the
`c_unwind` feature gate was not active. <sup>[2]</sup>
*Overview*
This makes a small patch to `rustc_mir_build::build::should_abort_on_panic`, so
that the same behavior from before is in place when the `c_unwind` gate is not
active.
`rustc_middle::ty::layout::fn_can_unwind` is not touched, as the visible
behavior should not differ before/after #76570. <sup>[3]</sup>
---
1: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
2: https://rust-lang.zulipchat.com/#narrow/stream/210922-project-ffi-unwind/topic/Is.20unwinding.20through.20extern.20C.20UB.3F/near/230112325
3: https://github.com/rust-lang/rust/pull/76570/files#diff-b0320c2b8868f325d83c027fc5d71732636e9763551e35895488f30fe057c6e9L2599-R2617
[1]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
[2]: https://rust-lang.zulipchat.com/#narrow/stream/210922-project-ffi-unwind/topic/Is.20unwinding.20through.20extern.20C.20UB.3F/near/230112325
[3]: https://github.com/rust-lang/rust/pull/76570/files#diff-b0320c2b8868f325d83c027fc5d71732636e9763551e35895488f30fe057c6e9L2599-R2617
|
|
|
|
|
|
|
|
An error is already created by AST validation.
|
|
Avoid an `Option<Option<_>>`
By simply swapping the calls to `map` and `and_then` around the complexity of
handling an `Option<Option<_>>` disappears.
`@rustbot` modify labels +C-cleanup +T-compiler
|
|
By simply swapping the calls to `map` and `and_then` around the complexity of
handling an `Option<Option<_>>` disappears.
|
|
### Background
In #76570, new ABI strings including `C-unwind` were introduced.
Their behavior is specified in RFC 2945 [1].
However, it was reported in the #ffi-unwind stream of the Rust
community Zulip that this had altered the way that `extern "C"`
functions behaved even when the `c_unwind` feature gate was not
active. [2]
### Overview
This makes a small patch to
`rustc_mir_build::build::should_abort_on_panic`, so that the same
behavior from before is in place when the `c_unwind` gate is not
active.
`rustc_middle::ty::layout::fn_can_unwind` is not touched, as the
visible behavior should not differ before/after #76570. [3]
### Footnotes
[1]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
[2]: https://rust-lang.zulipchat.com/#narrow/stream/210922-project-ffi-unwind/topic/Is.20unwinding.20through.20extern.20C.20UB.3F/near/230112325
[3]: https://github.com/rust-lang/rust/pull/76570/files#diff-b0320c2b8868f325d83c027fc5d71732636e9763551e35895488f30fe057c6e9L2599-R2617
|
|
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.
|
|
Don't call bump in check_mistyped_turbofish_with_multiple_type_params
Fixes https://github.com/rust-lang/rust/issues/84117
|
|
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.
|
|
|
|
warn-by-default on 2015
|
