HirId has a more stable representation than NodeId, meaning that
modifications to one item don't influence (part of) the IDs within
other items. The other part is a DefIndex for which there already
is a way of stable hashing and persistence.
This commit introduces the HirId type and generates a HirId for
every NodeId during HIR lowering, but the resulting values are
not yet used anywhere, except in consistency checks.
This reverts commit dc0bb3f283, reversing
changes made to e879aa43ef.
This is a temporary step intended to fix regressions. A more
comprehensive fix for type inference and dead-code is in the works.
This commit alters the translation layer to unconditionally emit the `uwtable`
LLVM attribute on Windows regardless of the `no_landing_pads` setting.
Previously I believe we omitted this attribute as an optimization when the
`-Cpanic=abort` flag was passed, but this unfortunately caused problems for
Gecko.
It [was discovered] that there was trouble unwinding through Rust functions due
to foreign exceptions such as illegal instructions or otherwise in-practice
methods used to abort a process. In testing it looked like the major difference
between a working binary and a non-working binary is indeed this `uwtable`
attribute, but this PR has unfortunately not been thoroughly tested in terms of
compiling Gecko with `-C panic=abort` *and* this PR to see whether it works, so
this is still somewhat working on just suspicion.
[was discovered]: https://bugzilla.mozilla.org/show_bug.cgi?id=1302078
macros: improve the `TokenStream` quoter
This PR
- renames the `TokenStream` quoter from `qquote!` to `quote!`,
- uses `$` instead of `unquote` (e.g. `let toks: TokenStream = ...; quote!([$toks])`),
- allows unquoting `Token`s as well as `TokenTree`s and `TokenStream`s (fixes#39746), and
- to preserve syntactic space, requires that `$` be followed by
- a single identifier to unquote, or
- another `$` to produce a literal `$`.
r? @nrc
Propagate expected type hints through struct literals.
Partial fix for #31260 to maximize backwards-compatibility, i.e. the hint is provided but not coerced to.
The added test works because `{...; x}` with a hint of `T` coerces `x` to `T`, and the reasoning why that is slightly different has to do with DSTs: `&Struct { tail: [x] }: &Struct<[T]>` has a hint of `[T]` for `[x]`, but the inferred type should be `[T; 1]` to succeed later, so `[x]` shouldn't be *forced* to be `[T]`.
*However*, implementing that complete behavior in a backwards-compatible way may be non-trivial, and has not yet been fully investigated, while this PR fixes#40355 and can be backported.
r? @nikomatsakis
Change how the `0` flag works in format!
Now it always implies right-alignment, so that padding zeroes are placed after the sign (if any) and before the digits. In other words, it always takes precedence over explicitly specified `[[fill]align]`. This also affects the '#' flag: zeroes are placed after the prefix (0b, 0o, 0x) and before the digits.
Here's a short summary of how similar format strings work in Python and Rust:
```
:05 :<05 :>05 :^05
Python 3.6 |-0001| |-1000| |000-1| |0-100|
Rust before |-0001| |-1000| |-0001| |-0100|
Rust after |-0001| |-0001| |-0001| |-0001|
:#05x :<#05x :>#05x :^#05x
Python 3.6 |0x001| |0x100| |000x1| |00x10|
Rust before |0x001| |0x100| |000x1| |0x010|
Rust after |0x001| |0x001| |0x001| |0x001|
```
Fixes#39997 [breaking-change]
Point to let when modifying field of immutable variable
Point at the immutable local variable when trying to modify one of its
fields.
Given a file:
```rust
struct Foo {
pub v: Vec<String>
}
fn main() {
let f = Foo { v: Vec::new() };
f.v.push("cat".to_string());
}
```
present the following output:
```
error: cannot borrow immutable field `f.v` as mutable
--> file.rs:7:13
|
6 | let f = Foo { v: Vec::new() };
| - this should be `mut`
7 | f.v.push("cat".to_string());
| ^^^
error: aborting due to previous error
```
Fix#27593.
Add feature gate for rvalue-static-promotion
Probably needs more tests (which ones?) and there may be other things that need to be done. Also not sure whether the version that introduces the flag is really `1.15.1`.
See https://github.com/rust-lang/rfcs/pull/1414.
Updates #38865.
Drop of arrays is now translated in trans::block in an ugly way that I
should clean up in a later PR, and does not handle panics in the middle
of an array drop, but this commit & PR are growing too big.
Point out correct turbofish usage on `Foo<Bar<Baz>>`
Whenever we parse a chain of binary operations, as long as the first
operation is `<` and the subsequent operations are either `>` or `<`,
present the following diagnostic help:
use `::<...>` instead of `<...>` if you meant to specify type arguments
This will lead to spurious recommendations on situations like
`2 < 3 < 4` but should be clear from context that the help doesn't apply
in that case.
Fixes#40396.
Now it always implies right-alignment, so that padding zeroes are placed after the sign (if any) and before the digits. In other words, it always takes precedence over explicitly specified `[[fill]align]`.
:06 :<06 :>06 :^06
before |-001.2| |-1.200| |-001.2| |-01.20|
after |-001.2| |-001.2| |-001.2| |-001.2|
Now it always implies right-alignment, so that padding zeroes are placed after the sign (if any) and before the digits. In other words, it always takes precedence over explicitly specified `[[fill]align]`. This also affects the '#' flag: zeroes are placed after the prefix (0b, 0o, 0x) and before the digits.
:05 :<05 :>05 :^05
before |-0001| |-1000| |-0001| |-0100|
after |-0001| |-0001| |-0001| |-0001|
:#05x :<#05x :>#05x :^#05x
before |0x001| |0x100| |000x1| |0x010|
after |0x001| |0x001| |0x001| |0x001|
Fixes#39997 [breaking-change]
Whenever we parse a chain of binary operations, as long as the first
operation is `<` and the subsequent operations are either `>` or `<`,
present the following diagnostic help:
use `::<...>` instead of `<...>` if you meant to specify type arguments
This will lead to spurious recommendations on situations like
`2 < 3 < 4` but should be clear from context that the help doesn't apply
in that case.
