make pretty source comparison check be fatal (fixes#52255)
This is not ready for merging because it reveals (at least) two regressions in the pretty suite. Should I attempt to fix those in this PR also?
rustc: Verify #[proc_macro] is only a word
... and perform the same verification for #[proc_macro_attribute], currently
neither of these attributes take any arguments.
Closes#52273
rustc: Search all derives for inert attributes
This commit fixes an apparent mistake in librustc_resolve where when the
`proc_macro` feature is enabled (or `rust_2018_preview`) the resolution of
custom attributes for custom derive was tweaked. Previously when an attribute
failed to resolve it was attempted to locate if there is a custom derive also in
scope which declares the attribute, but only the first custom derive directive
was search.
Instead this commit fixes the loop to search all custom derive invocations
looking for any which register the attribute in question.
Closes#52219
rustc_codegen_llvm: replace the first argument early in FnType::new_vtable.
Fixes#51907 by removing the vtable pointer before the `ArgType` is even created.
This allows any ABI to support trait object method calls, regardless of how it passes `*dyn Trait`.
r? @nikomatsakis
improve error message shown for unsafe operations
Add a short explanation saying why undefined behavior could arise. In particular, the error many people got for "creating a pointer to a packed field requires unsafe block" was not worded great -- it lead to people just adding the unsafe block without considering if what they are doing follows the rules.
I am not sure if a "note" is the right thing, but that was the easiest thing to add...
Inspired by @gnzlbg at https://github.com/rust-lang/rust/issues/46043#issuecomment-381544673
hygiene: Decouple transparencies from expansion IDs
And remove fallback to parent modules during resolution of names in scope.
This is a breaking change for users of unstable macros 2.0 (both procedural and declarative), code like this:
```rust
#![feature(decl_macro)]
macro m($S: ident) {
struct $S;
mod m {
type A = $S;
}
}
fn main() {
m!(S);
}
```
or equivalent
```rust
#![feature(decl_macro)]
macro m($S: ident) {
mod m {
type A = $S;
}
}
fn main() {
struct S;
m!(S);
}
```
stops working due to module boundaries being properly enforced.
For proc macro derives this is still reported as a compatibility warning to give `actix_derive`, `diesel_derives` and `palette_derive` time to fix their issues.
Fixes https://github.com/rust-lang/rust/issues/50504 in accordance with [this comment](https://github.com/rust-lang/rust/issues/50504#issuecomment-399764767).
Infinite loop detection for const evaluation
Resolves#50637.
An `EvalContext` stores the transient state (stack, heap, etc.) of the MIRI virtual machine while it executing code. As long as MIRI only executes pure functions, we can detect if a program is in a state where it will never terminate by periodically taking a "snapshot" of this transient state and comparing it to previous ones. If any two states are exactly equal, the machine must be in an infinite loop.
Instead of fully cloning a snapshot every time the detector is run, we store a snapshot's hash. Only when a hash collision occurs do we fully clone the interpreter state. Future snapshots which cause a collision will be compared against this clone, causing the interpreter to abort if they are equal.
At the moment, snapshots are not taken until MIRI has progressed a certain amount. After this threshold, snapshots are taken every `DETECTOR_SNAPSHOT_PERIOD` steps. This means that an infinite loop with period `P` will be detected after a maximum of `2 * P * DETECTOR_SNAPSHOT_PERIOD` interpreter steps. The factor of 2 arises because we only clone a snapshot after it causes a hash collision.
Upgrade to LLVM's master branch (LLVM 7)
### Current status
~~Blocked on a [performance regression](https://github.com/rust-lang/rust/pull/51966#issuecomment-402320576). The performance regression has an [upstream LLVM issue](https://bugs.llvm.org/show_bug.cgi?id=38047) and has also [been bisected](https://reviews.llvm.org/D44282) to an LLVM revision.~~
Ready to merge!
---
This commit upgrades the main LLVM submodule to LLVM's current master branch.
The LLD submodule is updated in tandem as well as compiler-builtins.
Along the way support was also added for LLVM 7's new features. This primarily
includes the support for custom section concatenation natively in LLD so we now
add wasm custom sections in LLVM IR rather than having custom support in rustc
itself for doing so.
Some other miscellaneous changes are:
* We now pass `--gc-sections` to `wasm-ld`
* The optimization level is now passed to `wasm-ld`
* A `--stack-first` option is passed to LLD to have stack overflow always cause
a trap instead of corrupting static data
* The wasm target for LLVM switched to `wasm32-unknown-unknown`.
* The syntax for aligned pointers has changed in LLVM IR and tests are updated
to reflect this.
* ~~The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug]~~
Nowadays we've been mostly only upgrading whenever there's a major release of
LLVM but enough changes have been happening on the wasm target that there's been
growing motivation for quite some time now to upgrade out version of LLD. To
upgrade LLD, however, we need to upgrade LLVM to avoid needing to build yet
another version of LLVM on the builders.
The revision of LLVM in use here is arbitrarily chosen. We will likely need to
continue to update it over time if and when we discover bugs. Once LLVM 7 is
fully released we can switch to that channel as well.
[llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382
cc #50543
use the adjusted type for cat_pattern in tuple patterns
This looks like a typo introduced in #51686.
Fixes#52213.
r? @pnkfelix
beta + stable nominating because regression + unsoundness.
This commit fixes an apparent mistake in librustc_resolve where when the
`proc_macro` feature is enabled (or `rust_2018_preview`) the resolution of
custom attributes for custom derive was tweaked. Previously when an attribute
failed to resolve it was attempted to locate if there is a custom derive also in
scope which declares the attribute, but only the first custom derive directive
was search.
Instead this commit fixes the loop to search all custom derive invocations
looking for any which register the attribute in question.
Closes#52219
This commit upgrades the main LLVM submodule to LLVM's current master branch.
The LLD submodule is updated in tandem as well as compiler-builtins.
Along the way support was also added for LLVM 7's new features. This primarily
includes the support for custom section concatenation natively in LLD so we now
add wasm custom sections in LLVM IR rather than having custom support in rustc
itself for doing so.
Some other miscellaneous changes are:
* We now pass `--gc-sections` to `wasm-ld`
* The optimization level is now passed to `wasm-ld`
* A `--stack-first` option is passed to LLD to have stack overflow always cause
a trap instead of corrupting static data
* The wasm target for LLVM switched to `wasm32-unknown-unknown`.
* The syntax for aligned pointers has changed in LLVM IR and tests are updated
to reflect this.
* The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug]
Nowadays we've been mostly only upgrading whenever there's a major release of
LLVM but enough changes have been happening on the wasm target that there's been
growing motivation for quite some time now to upgrade out version of LLD. To
upgrade LLD, however, we need to upgrade LLVM to avoid needing to build yet
another version of LLVM on the builders.
The revision of LLVM in use here is arbitrarily chosen. We will likely need to
continue to update it over time if and when we discover bugs. Once LLVM 7 is
fully released we can switch to that channel as well.
[llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382
NLL: fix E0594 "change to mutable ref" suggestion
Fix#51515.
Fix#51879.
Questions:
- [x] Is this the right place to fix this? It feels brittle, being so close to the frontend. **It's probably fine.**
- [ ] Have I missed any other cases that trigger this behavior?
- [x] Is it okay to use HELP and SUGGESTION in the UI test? **Yes.**
- [x] Do I need more tests for this? **No.**
rustdoc: Hide struct and enum variant constructor imports
This is fallout from #51425. The duplicate variant imports can be seen [here](https://doc.rust-lang.org/nightly/std/prelude/v1/index.html) for example.
This is fixing a regression so could be backported to beta.
r? @QuietMisdreavus
Implement #[alloc_error_handler]
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`.
find and highlight the `&` or `'_` in `region_name`
Before:
```
--> $DIR/dyn-trait-underscore.rs:18:5
|
LL | fn a<T>(items: &[T]) -> Box<dyn Iterator<Item=&T>> {
- | ----- lifetime `'1` appears in this argument
LL | Box::new(items.iter()) //~ ERROR cannot infer an appropriate lifetime
| ^^^^^^^^^^^^^^^^^^^^^^ cast requires that `'1` must outlive `'static`
```
After:
```
--> $DIR/dyn-trait-underscore.rs:18:5
|
LL | fn a<T>(items: &[T]) -> Box<dyn Iterator<Item=&T>> {
+ | - let's call the lifetime of this reference `'1`
LL | Box::new(items.iter()) //~ ERROR cannot infer an appropriate lifetime
| ^^^^^^^^^^^^^^^^^^^^^^ cast requires that `'1` must outlive `'static`
```
Not intended as the final end point necessarily in any sense. I intentionally left some to-do points to fill in later:
- Does not apply to upvars in closures yet (should be relatively easy)
- Does not handle the case where we can't find a precise match very well
- And of course we can still tweak wording
but shows the basic idea of how to make the `Ty` and `hir::Ty` to find a good spot to highlight.
r? @estebank
cc @davidtwco
Store scalar pair bools as i8 in memory
We represent `bool` as `i1` in a `ScalarPair`, unlike other aggregates,
to optimize IR for checked operators and the like. With this patch, we
still do so when the pair is an immediate value, but we use the `i8`
memory type when the value is loaded or stored as an LLVM aggregate.
So `(bool, bool)` looks like an `{ i1, i1 }` immediate, but `{ i8, i8 }`
in memory. When a pair is a direct function argument, `PassMode::Pair`,
it is still passed using the immediate `i1` type, but as a return value
it will use the `i8` memory type. Also, `bool`-like` enum tags will now
use scalar pairs when possible, where they were previously excluded due
to optimization issues.
Fixes#51516.
Closes#51566.
r? @eddyb
cc @nox
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`.
Don't suggest `let` bindings if they don't help with borrows
@oli-obk I have added a condition to address #52049, right now, this is on WIP because I think code change is also required on `error_reporting.rs`. Plus I need to check if any test cases fail.
I will ping you again if everything passes
r? @oli-obk
clarify why we're suggesting removing semicolon after braced items
Previously (issue #46186, pull-request #46258), a suggestion was added
to remove the semicolon after we fail to parse an item, but issue #51603
complains that it's still insufficiently obvious why. Let's add a note.
Resolves#51603.
Mostly fix metadata_only backend and extract some code out of rustc_codegen_llvm
Removes dependency on the `ar` crate and removes the `llvm.enabled` config option in favour of setting `rust.codegen-backends` to `[]`.
