| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Loosened rules involving statics mentioning other statics
Before this PR, trying to mention a static in any way other than taking a reference to it caused a compile-time error. So, while
```rust
static A: u32 = 42;
static B: &u32 = &A;
```
compiles successfully,
```rust
static A: u32 = 42;
static B: u32 = A; // error
```
and
```rust
static A: u32 = 42;
static B: u32 = *&A; // error
```
are not possible to express in Rust. On the other hand, introducing an intermediate `const fn` can presently allow one to do just that:
```rust
static A: u32 = 42;
static B: u32 = foo(&A); // success!
const fn foo(a: &u32) -> u32 {
*a
}
```
Preventing `const fn` from allowing to work around the ban on reading from statics would cripple `const fn` almost into uselessness.
Additionally, the limitation for reading from statics comes from the old const evaluator(s) and is not shared by `miri`.
This PR loosens the rules around use of statics to allow statics to evaluate other statics by value, allowing all of the above examples to compile and run successfully.
Reads from extern (foreign) statics are however still disallowed by miri, because there is no compile-time value to be read.
```rust
extern static A: u32;
static B: u32 = A; // error
```
This opens up a new avenue of potential issues, as a static can now not just refer to other statics or read from other statics, but even contain references that point into itself.
While it might seem like this could cause subtle bugs like allowing a static to be initialized by its own value, this is inherently impossible in miri.
Reading from a static causes the `const_eval` query for that static to be invoked. Calling the `const_eval` query for a static while already inside the `const_eval` query of said static will cause cycle errors.
It is not possible to accidentally create a bug in miri that would enable initializing a static with itself, because the memory of the static *does not exist* while being initialized.
The memory is not uninitialized, it is not there. Thus any change that would accidentally allow reading from a not yet initialized static would cause ICEs.
Tests have been modified according to the new rules, and new tests have been added for writing to `static mut`s within definitions of statics (which needs to fail), and incremental compilation with complex/interlinking static definitions.
Note that incremental compilation did not need to be adjusted, because all of this was already possible before with workarounds (like intermediate `const fn`s) and the encoding/decoding already supports all the possible cases.
r? @eddyb
|
|
Rollup of 7 pull requests
Successful merges:
- #51511 (Stabilize Iterator::flatten in 1.29, fixes #48213.)
- #51853 (Fix some doc links)
- #51890 (Fix inconsequential typo in GlobalAlloc doc example)
- #51920 (use literal span for concrete type suggestion)
- #51921 (improve the error message when `#[panic_implementation]` is missing)
- #51922 (rename the llvm-tools component to llvm-tools-preview and tweak its image)
- #51961 (Fix typo in /src/librustc_resolve/lib.rs)
Failed merges:
r? @ghost
|
|
improve the error message when `#[panic_implementation]` is missing
closes #51341
r? @nagisa
cc @phil-opp
|
|
use literal span for concrete type suggestion
Fixes #51874.
r? @estebank
|
|
Speed up compilation of large constant arrays
This is a different approach to #51672 as suggested by @oli-obk. Rather
than write each repeated value one-by-one, we write the first one and
then copy its value directly into the remaining memory.
With this change, the [toy program](https://github.com/rust-lang/rust/blob/c2f4744d2db4e162df824d0bd0b093ba4b351545/src/test/run-pass/mir_heavy_promoted.rs) goes from 63 seconds to 19 seconds on my machine.
Edit: Inlining `Size::bytes()` saves an additional 6 seconds dropping the total time to 13 seconds on my machine.
Edit2: Now down to 2.8 seconds.
r? @oli-obk
cc @nnethercote @eddyb
|
|
davidtwco:nll-dyn-trait-underscore-error-improvements, r=nikomatsakis
NLL: bad error message when converting anonymous lifetime to `'static`
Contributes to #46983. This PR doesn't introduce fantastic errors, but it should hopefully lay some groundwork for diagnostic improvements.
r? @nikomatsakis
|
|
|
|
|
|
|
|
|
|
Suggest correct comparison against negative literal
When parsing as emplacement syntax (`x<-1`), suggest the correct syntax
for comparison against a negative value (`x< -1`).
Fix #45651.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Updated tests accordingly.
|
|
Updated tests accordingly.
|
|
Point to lifetime spans on lifetime errors
|
|
Do not allow LLVM to increase a TLS's alignment on macOS.
This addresses the various TLS segfault on macOS 10.10.
Fix #51794.
Fix #51758.
Fix #50867.
Fix #48866.
Fix #46355.
Fix #44056.
|
|
|
|
hygiene: Implement transparent marks and use them for call-site hygiene in proc-macros
Fixes https://github.com/rust-lang/rust/issues/50050
|
|
Lowering cleanups [1/N]
|
|
Implement PartialEq between &str and OsString
This fixes #49854.
It allows equality comparison between `OsString` values and `str` references, such as `os_string == "something"`.
|
|
`$crate` is not resolved at def-site of a macro, but rather at "transitive def-site"
|
|
|
|
|
|
|
|
closes #51341
|
|
Fix incorrect type mismatch label pointing at return type
CC #46302.
|
|
Fixes #51874.
|
|
|
|
Make the public API of the alloc crate a subset of std
This only affects **unstable** APIs.
I plan to submit an RFC proposing to stabilize the crate. The reason it isn’t stable yet (https://github.com/rust-lang/rust/issues/27783) is in case we end up merging the standard library crates into one. However the `core` crate is already stable, so if that happens we’ll need to keep it working somehow (likely by making replacing its contents by `pub use` items). We can do the same for `alloc`. This PR will hopefully make this easier, but even if that doesn’t happen consistency with `std` seems good.
|
|
[NLL] Better move errors
Make a number of changes to improve the quality of NLL cannot move errors.
* Group errors that occur in the same `match` with the same cause.
* Suggest `ref`, `&` or removing `*` to avoid the move.
* Show the place being matched on.
Differences from AST borrowck:
* `&` is suggested over `ref` when matching on a place that can't be moved from.
* Removing `*` is suggested instead of adding `&` when applicable.
* Sub-pattern spans aren't used, this would probably need Spans on Places.
Closes #45699
Closes #46627
Closes #51187
Closes #51189
r? @pnkfelix
|
|
|
|
|
|
Fix macro missing from doc search
Fixes #51095.
r? @QuietMisdreavus
|
|
Detect overflows of non u32 shifts
|
|
Provide existing ref suggestions for more E0308 errors
|
|
Refactor error reporting of constants
cc @eddyb
This PR should not change any behaviour. It solely simplifies the internal handling of the errors
|
|
When parsing as emplacement syntax (`x<-1`), suggest the correct syntax
for comparison against a negative value (`x< -1`).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
translate / export weak lang items
see #51671 for details
fixes #51671
fixes #51342
r? @michaelwoerister or @alexcrichton
|
|
Optimize RefCell refcount tracking
Address the performance concern raised in https://github.com/rust-lang/rust/pull/51466#issuecomment-398255276
cc @dtolnay @nnethercote @rust-lang/wg-compiler-performance
cc @RalfJung @jhjourdan for soundness concerns
Can somebody kick off a perf run on this? I'm not sure how that's done, but I understand it has to be started manually.
The idea of this change is to switch to representing mutable refcount as values below 0 to eliminate some branching that was required with the old algorithm.
|
