| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Don't use eval_always for miri queries used from codegen.
This should fix the [massive incremental perf regression](https://perf.rust-lang.org/compare.html?start=95f437b3cfb2fec966d7eaf69d7c2e36f9c274d1&end=9285d401a6070094747465962bc49969b93e14c5&stat=instructions:u) introduced in #65664.
It seems that `eval_always` was mistakenly(?) added to `const_field` and then it ended up on `const_caller_location` (which is used much more often than `const_field` is).
r? @michaelwoerister cc @oli-obk @nnethercote
|
|
|
|
Fix #64153
This PR changes how the compiler detects if an object file from an upstream crate is a Rust object file or not. Instead of checking if the name starts with the crate name and ends with `.o` (which is not always the case, as described in #64153), it now just checks if the filename ends with `.rcgu.o`.
This fixes #64153. However, ideally we'd clean up the code around filename generation some more. Then this check could be made more robust.
r? @alexcrichton
|
|
Add new EFIAPI ABI
Fixes #54527
Adds a new ABI, "efiapi", which reflects the calling convention as specified by [the current spec UEFI spec](https://uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf#G6.999903). When compiling for x86_64, we should select the `win64` ABI, while on all other architectures (Itanium, x86, ARM and ARM64 and RISC-V), we should select the `C` ABI.
Currently, this is done by just turning it into the C ABI everywhere except on x86_64, where it's turned into the win64 ABI. Should we prevent this ABI from being used on unsupported architectures, and if so, how would this be done?
|
|
Improve the "try using a variant of the expected type" hint.
Fix https://github.com/rust-lang/rust/issues/65494.
- Change type-printing output.
- Use `span_to_snippet` when possible.
- Change the message to `try using a variant of the expected enum`
|
|
Update backtrace to 0.3.40
Diff: https://github.com/rust-lang/backtrace-rs/compare/0.3.37...b5cc5b12fa4fd03cb83546a7c62b9fff40086b63
Pretty low risk, considering the only changes are in low-tier targets.
r? @cramertj
cc @alexcrichton
|
|
Call out the types that are non local on E0117
CC #24745.
|
|
Lint ignored `#[inline]` on function prototypes
Fixes https://github.com/rust-lang/rust/issues/51280.
- Adds a `unused_attribute` lint for `#[inline]` on function prototypes.
- As a consequence, foreign items, impl items and trait items now have their attributes checked, which could cause some code to no longer compile (it was previously erroneously ignored).
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #65563 (Add long error explanation for E0587)
- #65640 (Use heuristics to recover parsing of missing `;`)
- #65643 (Correct handling of type flags with `ConstValue::Placeholder`)
- #65825 (rustc: use IndexVec<DefIndex, T> instead of Vec<T>.)
- #65858 (suggest `const_in_array_repeat_expression` flag)
- #65877 (doc: introduce `once` in `iter::chain` document)
- #65887 (doc: mention `get(_mut)` in Vec)
- #65891 (self-profiling: Record something more useful for crate metadata generation event.)
- #65893 (Output previous stable error messaging when using stable build.)
Failed merges:
r? @ghost
|
|
Output previous stable error messaging when using stable build.
Fixes #65254
As I had mentioned previously there I have the logic running right now however I'm not getting the exact same syntax highlighting as there was originally for this error.
I'm currently getting the following:
```
error: expected expression, found statement (`let`)
--> src/main.rs:2:14
|
2 | let x = (let y = 6);
| ^^^^^^^^^
|
= note: variable declaration using `let` is a statement
```
I'd like to get the following instead:
```
| let x = (let y = 6);
| ^^^
```
My current understanding is that the `span` being passed into `lower_expr_let` is coming from `lowering.rs`. I still don't know how the byte range is calculated for the erroneous syntax and need to look into it a bit more. In the meantime does anybody have any hints/tips regarding this??
|
|
self-profiling: Record something more useful for crate metadata generation event.
Before this commit, we had an event that would only track the compression step
for proc-macros and Rust dylibs. After the commit we measure the time for
acutally generating the crate metadata bytes.
r? @wesleywiser
|
|
doc: mention `get(_mut)` in Vec
|
|
doc: introduce `once` in `iter::chain` document
I find it hard to find which one to use with `chain` when I only need to
chain one value. Also [`once`][1] talks about `chain`.
[1]: https://doc.rust-lang.org/nightly/std/iter/fn.once.html
|
|
r=ecstatic-morse
suggest `const_in_array_repeat_expression` flag
This PR adds a suggestion to add the `#![feature(const_in_array_repeat_expression)]` attribute to the crate when a promotable expression is used in a repeat expression and the feature gate is not enabled.
Unfortunately, this ended up being a little bit more complex than I anticipated, which may not have been worth it given that this would all be removed when the feature is stabilized. However, with #65732 and #65737 being open, and the feature gate having not been being suggested to potential users, the feature might not be stabilized in a while, so maybe this is worth landing.
cc @Centril (addresses [this comment](https://github.com/rust-lang/rust/pull/61749#discussion_r307863857))
r? @ecstatic-morse (opened issues related to RFC 2203 recently)
|
|
rustc: use IndexVec<DefIndex, T> instead of Vec<T>.
Now that `DefIndex` is a proper index type, we can do that.
There was also an unnecessary `Option` I removed, I wonder if that has perf implications.
|
|
r=eddyb
Correct handling of type flags with `ConstValue::Placeholder`
This fixes a mistake, but not https://github.com/rust-lang/rust/issues/65623.
r? @eddyb
|
|
Use heuristics to recover parsing of missing `;`
- Detect `,` and `:` typos where `;` was intended.
- When the next token could have been the start of a new statement,
detect a missing semicolon.
Fix #48160, fix #44767 (after adding note about statements).
|
|
Add long error explanation for E0587
Part of #61137.
r? @kinnison
|
|
|
|
This commit adds a suggestion to add the
`#![feature(const_in_array_repeat_expression)]` attribute to the crate
when a promotable expression is used in a repeat expression.
Signed-off-by: David Wood <david@davidtw.co>
|
|
|
|
|
|
- Detect `,` and `:` typos where `;` was intended.
- When the next token could have been the start of a new statement,
detect a missing semicolon.
|
|
|
|
pretty-printing mechanism.
|
|
|
|
|
|
ci: move most of the prepare config into scripts
This PR moves most of the configuration from the CI yamls into bash scripts, driven by a small Python script (which understands and emulates the two `##vso[` commands we use).
There are two reasons why we'd want to do this:
* Being able to prepare the build environment locally by just running `src/ci/prepare.py` simplifies a lot setting up a local VM similar to CI (software pre-installed in the CI images won't be prepared, but it's a start anyway).
* When we'll switch to GitHub Actions we'll need to either duplicate code in multiple workflows or write a preprocessor. Having all the prepare steps in a single one is going to simplify the implementation of both options.
Along with the move I did a few changes to the actual scripts:
* Mirrored all the remaining external URLs we download (except chocolatey) to the `rust-lang-ci-mirrors` bucket, to increase reliability and reduce the chance of supply chain attacks. I didn't audit and mirror the CI scripts outside this PR though.
* Extracted CI-specific behavior (like issuing `##vso[` commands and detecting the host platform) into `shared.sh` and included it in most of the scripts. This way a switch to another CI provider will be less painful.
It's possible (and easier) to review this commit-by-commit.
r? @alexcrichton
cc @rust-lang/infra
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
version is not worth the trouble.
|
|
|
|
Point at local similarly named element and tweak references to variants
Partially address #65386.
|
|
event.
Before this commit, we had an event that would only track the compression step
for proc-macros and Rust dylibs. After the commit we measure the time for
acutally generating the crate metadata bytes.
|
|
|
|
|
|
Stabilize `const_constructor`
# Stabilization proposal
I propose that we stabilize `#![feature(const_constructor)]`.
Tracking issue: https://github.com/rust-lang/rust/issues/61456
Version target: 1.40 (2019-11-05 => beta, 2019-12-19 => stable).
## What is stabilized
### User guide
Tuple struct and tuple variant constructors are now considered to be constant functions. As such a call expression where the callee has a tuple struct or variant constructor "function item" type can be called:
```rust
const fn make_options() {
// These already work because they are special cased:
Some(0);
(Option::Some)(1);
// These also work now:
let f = Option::Some;
f(2);
{Option::Some}(3);
<Option<_>>::Some(5);
}
```
### Motivation
Consistency with other `const fn`. Consistency between syntactic path forms.
This should also ensure that constructors implement `const Fn` traits and can be coerced to `const fn` function pointers, if they are introduced.
## Tests
* [ui/consts/const_constructor/const-construct-call.rs](https://github.com/rust-lang/rust/blob/0d75ab2293a106eb674ac01860910cfc1580837e/src/test/ui/consts/const_constructor/const-construct-call.rs) - Tests various syntactic forms, use in both `const fn` and `const` items, and constructors in both the current and extern crates.
* [ui/consts/const_constructor/const_constructor_qpath.rs](https://github.com/rust-lang/rust/blob/1850dfcdabf8258a1f023f26c2c59e96b869dd95/src/test/ui/consts/const_constructor/const_constructor_qpath.rs) - Tests that type qualified paths to enum variants are also considered to be `const fn`.(#64247)
r? @oli-obk
Closes #61456
Closes #64247
|
|
|
|
Gather together usefulness tests
I took most tests that were testing only for match exhaustiveness, pattern refutability or match arm reachability, and put them in the same test folder. I found it helpful to have them all in the same place when working on the usefulness algorithm.
|
|
doc: explain why it is unsafe to construct Vec<u8> from Vec<u16>
|
|
librustc_lexer: Enhance documentation
This PR enhances documentation state of the `librustc_lexer` (as initiative caused by [rustc-guide#474](https://github.com/rust-lang/rustc-guide/issues/474)), by adding:
- Module documentation.
- Doc-comments (and a bit of usual comments) in non-obvious (as for me) places.
r? @petrochenkov
cc @Centril
|
|
rustc, rustc_passes: reduce deps on rustc_expand
Part of #65324.
r? @petrochenkov
|
