| Age | Commit message (Collapse) | Author | Lines |
|---|
|
behavior could arise
Inspired by @gnzlbg at https://github.com/rust-lang/rust/issues/46043#issuecomment-381544673
|
|
This to-be-stable attribute is equivalent to `#[lang = "oom"]`.
It is required when using the alloc crate without the std crate.
It is called by `handle_alloc_error`, which is in turned called
by "infallible" allocations APIs such as `Vec::push`.
|
|
|
|
r=nikomatsakis
Dont run ast borrowck on mir mode
r? @nikomatsakis
|
|
refactor and cleanup region errors for NLL
This is a WIP commit. It simplifies some of the code from https://github.com/rust-lang/rust/pull/51536 and extends a few more steps towards the errors that @davidtwco and I were shooting for. These are intended as a replacement for the general "unable to infer lifetime" messages -- one that is actually actionable. We're certainly not there yet, but the overall shape hopefully gets a bit clearer.
I'm thinking about trying to open up an internals thread to sketch out the overall plan and perhaps discuss how to get the wording right, which special cases to handle, etc.
r? @estebank
cc @davidtwco
|
|
Implementation of tool lints.
Tracking issue: #44690
|
|
Deduplicate error reports for statics
fixes #51970
|
|
|
|
|
|
|
|
|
|
[NLL] Use better span for initializing a variable twice
Closes #51217
When assigning to a (projection from a) local immutable local which starts initialised (everything except `let PATTERN;`):
* Point to the declaration of that local
* Make the error message refer to the local, rather than the projection.
r? @nikomatsakis
|
|
|
|
Show known meta items in unknown meta items error
This PR adds a label to E0541. It also factors built-in attribute parsing into a submodule of `attr` for ease of future refactoring.
Fixes #51469.
|
|
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
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Updated tests accordingly.
|
|
Updated tests accordingly.
|
|
|
|
Lowering cleanups [1/N]
|
|
|
|
closes #51341
|
|
[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
|
|
Refactor error reporting of constants
cc @eddyb
This PR should not change any behaviour. It solely simplifies the internal handling of the errors
|
|
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.
|
|
|
|
|
|
|
|
Add a compiletest header for edition
r? @nikomatsakis
Are the `-Zunstable-options` options needed in these tests? It looks like they aren't. If not, I can remove them.
|
|
Lower case some feature gate error messages
|
|
|
|
|
|
|
|
|
|
|
|
These were stabilized in March 2018's #47813, and are the Preferred Way
to Do It going forward (q.v. #51043).
|
|
Rollup of 11 pull requests
Successful merges:
- #51104 (add `dyn ` to display of dynamic (trait) types)
- #51153 (Link panic and compile_error docs)
- #51642 (Fix unknown windows build)
- #51730 (New safe associated functions for PinMut)
- #51731 (Fix ICEs when using continue as an array length inside closures (inside loop conditions))
- #51747 (Add error for using null characters in #[export_name])
- #51769 (Update broken rustc-guide links)
- #51786 (Remove unnecessary stat64 pointer casts)
- #51788 (Fix typo)
- #51789 (Don't ICE when performing `lower_pattern_unadjusted` on a `TyError`)
- #51791 (Minify css)
Failed merges:
r? @ghost
|
|
add `dyn ` to display of dynamic (trait) types
~~I'm not sure we want the `dyn` in the E0277 "trait bound [...] is not satisfied" messages ("bound" sounds like a different thing in contrast to the names of specific trait-object types like `Box<dyn Trait>`), but I'm finding the code I would need to change that hard to follow—the [display object seems to](https://github.com/rust-lang/rust/blob/f0805a4421449bd6fe3096d63820fbebe2bfcd1d/src/librustc/traits/error_reporting.rs#L600) be a [`Predicate::Trait`](https://github.com/rust-lang/rust/blob/f0805a4421449bd6fe3096d63820fbebe2bfcd1d/src/librustc/ty/mod.rs#L962) variant, whose [`Display` implementation](https://github.com/rust-lang/rust/blob/f0805a4421449bd6fe3096d63820fbebe2bfcd1d/src/librustc/util/ppaux.rs#L1309) calls `.print` on its `PolyTraitPredicate` member, [which is a type alias](https://github.com/rust-lang/rust/blob/f0805a4421449bd6fe3096d63820fbebe2bfcd1d/src/librustc/ty/mod.rs#L1112) for `ty::Binder<TraitPredicate<'tcx>>`, whose [`Display` implementation](https://github.com/rust-lang/rust/blob/f0805a4421449bd6fe3096d63820fbebe2bfcd1d/src/librustc/util/ppaux.rs#L975-L985) ... _&c._— so maybe it's time to pull-request this and see what reviewers think.~~
Resolves #49277 (?).
r? @nikomatsakis
|
|
Implementation of RFC 2086 - Allow Irrefutable Let patterns
This is the set of changes for RFC2086. Tracking issue #44495. Rendered [here](https://github.com/rust-lang/rfcs/pull/2086)
|
|
|
|
The `dyn Trait` syntax was stabilized in 199ee327. Resolves #49277.
|
