| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Because the corresponding `Level` is `DelayedBug` and `span_delayed_bug`
follows the pattern used everywhere else: `span_err`, `span_warning`,
etc.
|
|
Because the variant name in `Level` is `Note`, and the `without_error`
suffix is omitted in similar cases like `struct_allow` and
`struct_help`.
|
|
To match the `FailureNote` variant of `Level`.
|
|
Because `span_note_diag` doesn't follow the naming structure used for
the error reporting functions.
|
|
|
|
`ErrorGuaranteed` should be used for all error methods involving the
`Error` level, e.g. as is done for the corresponding `span_err` methods.
|
|
It has a single call site.
|
|
Restore `#![no_builtins]` crates participation in LTO.
After #113716, we can make `#![no_builtins]` crates participate in LTO again.
`#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again.
Fixes #72140. Fixes #112245. Fixes #110606. Fixes #105734. Fixes #96486. Fixes #108853. Fixes #108893. Fixes #78744. Fixes #91158. Fixes https://github.com/rust-lang/cargo/issues/10118. Fixes https://github.com/rust-lang/compiler-builtins/issues/347.
The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears.
Some issues were not tested due to the difficulty of reproducing them.
r? pnkfelix
cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
|
|
|
|
Remove unnecessary span label for parse errors that already have a
suggestion.
Provide structured suggestion to close generics in more cases.
|
|
|
|
vis note for no pub reexports glob import
Fixes #115966
Only trigger the `unused_import` lint when it's not being used.
r? `@petrochenkov`
|
|
|
|
|
|
Liveness data is pushed from multiple parts of NLL. Instead of changing
the call sites to maintain live loans, move the latter to `LivenessValues` where
this liveness data is pushed to, and maintain live loans there.
This fixes the differences in polonius scopes on some CFGs where a
variable was dead in tracing but as a MIR terminator its regions were marked
live from "constraint generation"
|
|
for consistency with how they're named everywhere else
|
|
|
|
Stabilize C string literals
RFC: https://rust-lang.github.io/rfcs/3348-c-str-literal.html
Tracking issue: https://github.com/rust-lang/rust/issues/105723
Documentation PR (reference manual): https://github.com/rust-lang/reference/pull/1423
# Stabilization report
Stabilizes C string and raw C string literals (`c"..."` and `cr#"..."#`), which are expressions of type [`&CStr`](https://doc.rust-lang.org/stable/core/ffi/struct.CStr.html). Both new literals require Rust edition 2021 or later.
```rust
const HELLO: &core::ffi::CStr = c"Hello, world!";
```
C strings may contain any byte other than `NUL` (`b'\x00'`), and their in-memory representation is guaranteed to end with `NUL`.
## Implementation
Originally implemented by PR https://github.com/rust-lang/rust/pull/108801, which was reverted due to unintentional changes to lexer behavior in Rust editions < 2021.
The current implementation landed in PR https://github.com/rust-lang/rust/pull/113476, which restricts C string literals to Rust edition >= 2021.
## Resolutions to open questions from the RFC
* Adding C character literals (`c'.'`) of type `c_char` is not part of this feature.
* Support for `c"..."` literals does not prevent `c'.'` literals from being added in the future.
* C string literals should not be blocked on making `&CStr` a thin pointer.
* It's possible to declare constant expressions of type `&'static CStr` in stable Rust (as of v1.59), so C string literals are not adding additional coupling on the internal representation of `CStr`.
* The unstable `concat_bytes!` macro should not accept `c"..."` literals.
* C strings have two equally valid `&[u8]` representations (with or without terminal `NUL`), so allowing them to be used in `concat_bytes!` would be ambiguous.
* Adding a type to represent C strings containing valid UTF-8 is not part of this feature.
* Support for a hypothetical `&Utf8CStr` may be explored in the future, should such a type be added to Rust.
|
|
Refactor NLL constraint generation and most of polonius fact generation
As discussed in #118175, NLL "constraint generation" is only about liveness, but currently also contains legacy polonius fact generation. The latter is quite messy, and this PR cleans this up to prepare for its future removal:
- splits polonius fact generation out of NLL constraint generation
- merges NLL constraint generation to its more natural place, liveness
- extracts all of the polonius fact generation from NLLs apart from MIR typeck (as fact generation is somewhat in a single place there already, but should be cleaned up) into its own explicit module, with a single entry point instead of many.
There should be no behavior changes, and tests seem to behave the same as master: without polonius, with legacy polonius, with the in-tree polonius.
I've split everything into smaller logical commits for easier review, as it required quite a bit of code to be split and moved around, but it should all be trivial changes.
r? `@matthewjasper`
|
|
Rollup of 3 pull requests
Successful merges:
- #118483 (rustdoc: `div.where` instead of fmt-newline class)
- #118486 (generic_const_exprs: suggest to add the feature, not use it)
- #118489 (Wesley is on vacation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
generic_const_exprs: suggest to add the feature, not use it
Usually our missing feature messages look something like
```
= help: add `#![feature(inline_const)]` to the crate attributes to enable
```
However `generic_const_exprs` used a different verb. That's inconsistent and it also means playground won't add that nice hyperlink to add the feature automatically. So let's use the same verb as everywhere else.
|
|
|
|
explain a good reason for why LocalValue does not store the type of the local
As found out by `@lcnr` in https://github.com/rust-lang/rust/pull/112307, storing the type here can lead to subtle bugs when it gets out of sync with the MIR body. That's not the reason why the interpreter does it this way I think, but good thing we dodged that bullet. :)
|
|
Change `SwitchTarget` representation in StableMIR
The new structure encodes its invariant, which reduces the likelihood of having an inconsistent representation. It is also more intuitive and user friendly.
I encapsulated the structure for now in case we decide to change it back.
### Notes:
1. I had to change the `Successors` type, since there's a conflict on the iterator type. We could potentially implement an iterator here, but I would prefer keeping it simple for now, and add a `successors_iter()` method if needed.
2. I removed `CoroutineDrop` for now since it we never create it. We can add it when we add support to other MIR stages.
|
|
`rustc_session` cleanups
r? `@bjorn3`
|
|
Add `-Zfunction-return={keep,thunk-extern}` option
This is intended to be used for Linux kernel RETHUNK builds.
With this commit (optionally backported to Rust 1.73.0), plus a patched Linux kernel to pass the flag, I get a RETHUNK build with Rust enabled that is `objtool`-warning-free and is able to boot in QEMU and load a sample Rust kernel module.
Issue: https://github.com/rust-lang/rust/issues/116853.
|
|
|
|
|
|
|
|
All the other option enums are defined in `config.rs`.
|
|
|
|
On Fn arg mismatch for a fn path, suggest a closure
When encountering a fn call that has a path to another fn being passed in, where an `Fn` impl is expected, and the arguments differ, suggest wrapping the argument with a closure with the appropriate arguments.
The last `help` is new:
```
error[E0631]: type mismatch in function arguments
--> $DIR/E0631.rs:9:9
|
LL | fn f(_: u64) {}
| ------------ found signature defined here
...
LL | foo(f);
| --- ^ expected due to this
| |
| required by a bound introduced by this call
|
= note: expected function signature `fn(usize) -> _`
found function signature `fn(u64) -> _`
note: required by a bound in `foo`
--> $DIR/E0631.rs:3:11
|
LL | fn foo<F: Fn(usize)>(_: F) {}
| ^^^^^^^^^ required by this bound in `foo`
help: consider wrapping the function in a closure
|
LL | foo(|arg0: usize| f(/* u64 */));
| +++++++++++++ +++++++++++
```
|
|
|
|
We currently rely on the order of successors to be conditional branches
first, followed by the otherwise target.
|
|
The new structure encodes its invariant, which reduces the likelihood
of having an inconsistent representation. It is also more intuitive and
user friendly.
I encapsulated the structure for now in case we decide to change it back.
|
|
This is intended to be used for Linux kernel RETHUNK builds.
With this commit (optionally backported to Rust 1.73.0), plus a
patched Linux kernel to pass the flag, I get a RETHUNK build with
Rust enabled that is `objtool`-warning-free and is able to boot in
QEMU and load a sample Rust kernel module.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
- Implement link-arg as an attribute
- Apply suggestions from review
- Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
- Add unstable book entry
|
|
|
|
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Rollup of 5 pull requests
Successful merges:
- #118452 (rustdoc-search: allow spaces around `::` in path query)
- #118453 (Tweak message on ADT with private fields building)
- #118456 (rustc_span: Remove unused symbols.)
- #118458 (rustdoc: remove small from `small-section-header`)
- #118464 (Dispose llvm::TargetMachines prior to llvm::Context being disposed)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Dispose llvm::TargetMachines prior to llvm::Context being disposed
If the TargetMachine is disposed after the Context is disposed, it can lead to use after frees in some cases.
I've observed this happening occasionally on code compiled for aarch64-pc-windows-msvc using `-Zstack-protector=strong` but other users have reported AVs from host aarch64-pc-windows-msvc compilers as well.
I was not able to extract a self-contained test case yet so there is no accompanying test.
Fixes #118462
|
|
rustc_span: Remove unused symbols.
As noted here, there is no guarantee that all pre-interned symbols are used.
https://github.com/rust-lang/rust/blob/b10cfcd65fd7f7b1ab9beb34798b2108de003452/compiler/rustc_span/src/symbol.rs#L124-L125
This was done starting with using ripgrep to search for `sym::whatever`. I removed anything that didn't show up. However this had a huge number of false positives, due to extensive macro use. Then there was a manual phase of adding back all the ones used my macros.
I don't think this was worth my time to do, but it's done now . ¯\_(ツ)_/¯
|
|
Tweak message on ADT with private fields building
When trying to create an inaccessible ADT due to private fields, handle the case when no fields were passed.
```
error: cannot construct `Foo` with struct literal syntax due to private fields
--> $DIR/issue-76077.rs:8:5
|
LL | foo::Foo {};
| ^^^^^^^^
|
= note: private field `you_cant_use_this_field` that was not provided
```
|
|
miri: add test checking that aggregate assignments reset memory to uninit
Also, `write_aggregate` is really just a helper for evaluating `Aggregate` rvalues, so it should be in `step.rs`, not `place.rs`. Also factor out `Repeat` rvalues into their own function while we are at it.
r? `@saethlin`
Fixes https://github.com/rust-lang/miri/issues/3195
|
|
It's trivial and has a single callsite.
|
|
Alphabetical order is nicer than random order.
|
|
We have `sym::integer` for interning integers. Using it lets us use
symbols directy, and not have to explicitly go through strings.
|
|
|
|
Save analysis was removed a while ago.
|
|
|
