Commit graph

214 commits

Author SHA1 Message Date
kadmin
e4e5db4e42 Add has_default to GenericParamDefKind::Const
This currently creates a field which is always false on GenericParamDefKind for future use when
consts are permitted to have defaults

Update const_generics:default locations

Previously just ignored them, now actually do something about them.

Fix using type check instead of value

Add parsing

This adds all the necessary changes to lower const-generics defaults from parsing.

Change P<Expr> to AnonConst

This matches the arguments passed to instantiations of const generics, and makes it specific to
just anonymous constants.

Attempt to fix lowering bugs
2021-03-23 17:16:20 +00:00
mark
8c4b3dbb50 rename :pat2018 -> :pat215 2021-03-22 12:40:23 -05:00
bors
41b315a470 Auto merge of #83271 - SparrowLii:simd_neg, r=Amanieu
Add simd_neg platform intrinsic

Stdarch needs to add simd_neg to support the implementation of vneg neon instructions. Look [here](https://github.com/rust-lang/stdarch/pull/1087)
2021-03-20 09:01:35 +00:00
Dylan DPC
37b7031078
Rollup merge of #83197 - jyn514:cfg-test-dead-code, r=joshtriplett
Move some test-only code to test files

Split out from https://github.com/rust-lang/rust/pull/83185.
2021-03-19 15:03:24 +01:00
SparrowLii
0fa158b38f Add simd_neg platform intrinsic 2021-03-19 02:16:21 +08:00
Mara Bos
cfb4ad4f2a Remove unwrap_none/expect_none from compiler/. 2021-03-18 14:25:54 +01:00
Joshua Nelson
620ecc01a2 Move some test-only code to test files
This also relaxes the bounds on some structs and moves them to the impl
block instead.
2021-03-17 10:31:30 -04:00
Oli Scherer
1f7df1956a Replace type_alias_impl_trait by min_type_alias_impl_trait with no actual changes in behaviour
This makes `type_alias_impl_trait` not actually do anything anymore
2021-03-15 17:32:43 +00:00
Vadim Petrochenkov
a4cc3cae04 expand: Resolve and expand inner attributes on out-of-line modules 2021-03-14 18:10:29 +03:00
bors
acca818928 Auto merge of #83064 - cjgillot:fhash, r=jackh726
Tweaks to stable hashing
2021-03-13 20:21:40 +00:00
Camille GILLOT
34e92bbf65 Hash SyntaxContext first. 2021-03-11 12:31:31 +01:00
Camille GILLOT
fe2d728e62 Remove useless method. 2021-03-11 12:24:58 +01:00
bors
f98721f886 Auto merge of #82982 - Dylan-DPC:rollup-mt497z7, r=Dylan-DPC
Rollup of 9 pull requests

Successful merges:

 - #81309 (always eagerly eval consts in Relate)
 - #82217 (Edition-specific preludes)
 - #82807 (rustdoc: Remove redundant enableSearchInput function)
 - #82924 (WASI: Switch to crt1-command.o to enable support for new-style commands)
 - #82949 (Do not attempt to unlock envlock in child process after a fork.)
 - #82955 (fix: wrong word)
 - #82962 (Treat header as first paragraph for shortened markdown descriptions)
 - #82976 (fix error message for copy(_nonoverlapping) overflow)
 - #82977 (Rename `Option::get_or_default` to `get_or_insert_default`)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-03-10 19:12:53 +00:00
Dylan DPC
b9a2570c9b
Rollup merge of #82955 - ltoddy:fix/wrong, r=jonas-schievink
fix: wrong word
2021-03-10 17:55:44 +01:00
Dylan DPC
759204ffc4
Rollup merge of #82217 - m-ou-se:edition-prelude, r=nikomatsakis
Edition-specific preludes

This changes `{std,core}::prelude` to export edition-specific preludes under `rust_2015`, `rust_2018` and `rust_2021`. (As suggested in https://github.com/rust-lang/rust/issues/51418#issuecomment-395630382.) For now they all just re-export `v1::*`, but this allows us to add things to the 2021edition prelude soon.

This also changes the compiler to make the automatically injected prelude import dependent on the selected edition.

cc `@rust-lang/libs` `@djc`
2021-03-10 17:55:38 +01:00
ltoddy
37543ce656 fix: wrong word 2021-03-10 09:09:37 +08:00
katelyn a. martin
df45c579de rustc_target: add "unwind" payloads to Abi
### Overview

    This commit begins the implementation work for RFC 2945. For more
    information, see the rendered RFC [1] and tracking issue [2].

    A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`,
    and `Thiscall` variants, marking whether unwinding across FFI
    boundaries is acceptable. The cases where each of these variants'
    `unwind` member is true correspond with the `C-unwind`,
    `system-unwind`, `stdcall-unwind`, and `thiscall-unwind` ABI strings
    introduced in RFC 2945 [3].

 ### Feature Gate and Unstable Book

    This commit adds a `c_unwind` feature gate for the new ABI strings.
    Tests for this feature gate are included in `src/test/ui/c-unwind/`,
    which ensure that this feature gate works correctly for each of the
    new ABIs.

    A new language features entry in the unstable book is added as well.

 ### Further Work To Be Done

    This commit does not proceed to implement the new unwinding ABIs,
    and is intentionally scoped specifically to *defining* the ABIs and
    their feature flag.

 ### One Note on Test Churn

    This will lead to some test churn, in re-blessing hash tests, as the
    deleted comment in `src/librustc_target/spec/abi.rs` mentioned,
    because we can no longer guarantee the ordering of the `Abi`
    variants.

    While this is a downside, this decision was made bearing in mind
    that RFC 2945 states the following, in the "Other `unwind` Strings"
    section [3]:

    >  More unwind variants of existing ABI strings may be introduced,
    >  with the same semantics, without an additional RFC.

    Adding a new variant for each of these cases, rather than specifying
    a payload for a given ABI, would quickly become untenable, and make
    working with the `Abi` enum prone to mistakes.

    This approach encodes the unwinding information *into* a given ABI,
    to account for the future possibility of other `-unwind` ABI
    strings.

 ### Ignore Directives

    `ignore-*` directives are used in two of our `*-unwind` ABI test
    cases.

    Specifically, the `stdcall-unwind` and `thiscall-unwind` test cases
    ignore architectures that do not support `stdcall` and
    `thiscall`, respectively.

    These directives are cribbed from
    `src/test/ui/c-variadic/variadic-ffi-1.rs` for `stdcall`, and
    `src/test/ui/extern/extern-thiscall.rs` for `thiscall`.

    This would otherwise fail on some targets, see:
    fcf697f902

 ### Footnotes

[1]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
[2]: https://github.com/rust-lang/rust/issues/74990
[3]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md#other-unwind-abi-strings
2021-03-09 14:38:29 -05:00
Dylan DPC
9c310571a8
Rollup merge of #82682 - petrochenkov:cfgeval, r=Aaron1011
Implement built-in attribute macro `#[cfg_eval]` + some refactoring

This PR implements a built-in attribute macro `#[cfg_eval]` as it was suggested in https://github.com/rust-lang/rust/pull/79078 to avoid `#[derive()]` without arguments being abused as a way to configure input for other attributes.

The macro is used for eagerly expanding all `#[cfg]` and `#[cfg_attr]` attributes in its input ("fully configuring" the input).
The effect is identical to effect of `#[derive(Foo, Bar)]` which also fully configures its input before passing it to macros `Foo` and `Bar`, but unlike `#[derive]` `#[cfg_eval]` can be applied to any syntax nodes supporting macro attributes, not only certain items.

`cfg_eval` was the first name suggested in https://github.com/rust-lang/rust/pull/79078, but other alternatives are also possible, e.g. `cfg_expand`.

```rust
#[cfg_eval]
#[my_attr] // Receives `struct S {}` as input, the field is configured away by `#[cfg_eval]`
struct S {
    #[cfg(FALSE)]
    field: u8,
}
```

Tracking issue: https://github.com/rust-lang/rust/issues/82679
2021-03-08 13:13:23 +01:00
bors
76c500ec6c Auto merge of #81635 - michaelwoerister:structured_def_path_hash, r=pnkfelix
Let a portion of DefPathHash uniquely identify the DefPath's crate.

This allows to directly map from a `DefPathHash` to the crate it originates from, without constructing side tables to do that mapping -- something that is useful for incremental compilation where we deal with `DefPathHash` instead of `DefId` a lot.

It also allows to reliably and cheaply check for `DefPathHash` collisions which allows the compiler to gracefully abort compilation instead of running into a subsequent ICE at some random place in the code.

The following new piece of documentation describes the most interesting aspects of the changes:

```rust
/// A `DefPathHash` is a fixed-size representation of a `DefPath` that is
/// stable across crate and compilation session boundaries. It consists of two
/// separate 64-bit hashes. The first uniquely identifies the crate this
/// `DefPathHash` originates from (see [StableCrateId]), and the second
/// uniquely identifies the corresponding `DefPath` within that crate. Together
/// they form a unique identifier within an entire crate graph.
///
/// There is a very small chance of hash collisions, which would mean that two
/// different `DefPath`s map to the same `DefPathHash`. Proceeding compilation
/// with such a hash collision would very probably lead to an ICE and, in the
/// worst case, to a silent mis-compilation. The compiler therefore actively
/// and exhaustively checks for such hash collisions and aborts compilation if
/// it finds one.
///
/// `DefPathHash` uses 64-bit hashes for both the crate-id part and the
/// crate-internal part, even though it is likely that there are many more
/// `LocalDefId`s in a single crate than there are individual crates in a crate
/// graph. Since we use the same number of bits in both cases, the collision
/// probability for the crate-local part will be quite a bit higher (though
/// still very small).
///
/// This imbalance is not by accident: A hash collision in the
/// crate-local part of a `DefPathHash` will be detected and reported while
/// compiling the crate in question. Such a collision does not depend on
/// outside factors and can be easily fixed by the crate maintainer (e.g. by
/// renaming the item in question or by bumping the crate version in a harmless
/// way).
///
/// A collision between crate-id hashes on the other hand is harder to fix
/// because it depends on the set of crates in the entire crate graph of a
/// compilation session. Again, using the same crate with a different version
/// number would fix the issue with a high probability -- but that might be
/// easier said then done if the crates in questions are dependencies of
/// third-party crates.
///
/// That being said, given a high quality hash function, the collision
/// probabilities in question are very small. For example, for a big crate like
/// `rustc_middle` (with ~50000 `LocalDefId`s as of the time of writing) there
/// is a probability of roughly 1 in 14,750,000,000 of a crate-internal
/// collision occurring. For a big crate graph with 1000 crates in it, there is
/// a probability of 1 in 36,890,000,000,000 of a `StableCrateId` collision.
```

Given the probabilities involved I hope that no one will ever actually see the error messages. Nonetheless, I'd be glad about some feedback on how to improve them. Should we create a GH issue describing the problem and possible solutions to point to? Or a page in the rustc book?

r? `@pnkfelix` (feel free to re-assign)
2021-03-07 23:45:57 +00:00
Vadim Petrochenkov
5dad6c2575 Implement built-in attribute macro #[cfg_eval] 2021-03-06 23:03:19 +03:00
Mara
2cd1f79aa1
Rollup merge of #82773 - mgacek8:feature/add_diagnostic_item_to_Default_trait, r=oli-obk
Add diagnostic item to `Default` trait

This PR adds diagnostic item to `Default` trait to be used by rust-lang/rust-clippy#6562 issue.
Also fixes the obsolete path to the `symbols.rs` file in the comment.
2021-03-05 10:57:24 +01:00
Mara
e6a6df5daa
Rollup merge of #80723 - rylev:noop-lint-pass, r=estebank
Implement NOOP_METHOD_CALL lint

Implements the beginnings of https://github.com/rust-lang/lang-team/issues/67 - a lint for detecting noop method calls (e.g, calling `<&T as Clone>::clone()` when `T: !Clone`).

This PR does not fully realize the vision and has a few limitations that need to be addressed either before merging or in subsequent PRs:
* [ ] No UFCS support
* [ ] The warning message is pretty plain
* [ ] Doesn't work for `ToOwned`

The implementation uses [`Instance::resolve`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/instance/struct.Instance.html#method.resolve) which is normally later in the compiler. It seems that there are some invariants that this function relies on that we try our best to respect. For instance, it expects substitutions to have happened, which haven't yet performed, but we check first for `needs_subst` to ensure we're dealing with a monomorphic type.

Thank you to ```@davidtwco,``` ```@Aaron1011,``` and ```@wesleywiser``` for helping me at various points through out this PR ❤️.
2021-03-05 10:57:14 +01:00
Mateusz Gacek
58d6f80f96 Fix comment with path to symbols! macro 2021-03-04 10:14:56 -08:00
Yuki Okushi
f898aa3f5b
Rollup merge of #80527 - jyn514:rustdoc-lints, r=GuillaumeGomez
Make rustdoc lints a tool lint instead of built-in

- Rename `broken_intra_doc_links` to `rustdoc::broken_intra_doc_links` (and similar for other rustdoc lints; I don't expect any others to be used frequently, though).
- Ensure that the old lint names still work and give deprecation errors
- Register lints even when running doctests
- Move lint machinery into a separate file
- Add `declare_rustdoc_lint!` macro

Unblocks https://github.com/rust-lang/rust/pull/80300, https://github.com/rust-lang/rust/pull/79816, https://github.com/rust-lang/rust/pull/80965. Makes the strangeness in https://github.com/rust-lang/rust/pull/77364 more apparent to the end user (note that `missing_docs` is *not* moved to rustdoc in this PR). Closes https://github.com/rust-lang/rust/issues/78786.

## Current status

This is blocked on #82620 (see https://github.com/rust-lang/rust/pull/80527#issuecomment-787401519)
2021-03-04 20:01:01 +09:00
Ryan Levick
1999a3147f Fix borrow and deref 2021-03-03 11:23:29 +01:00
Ryan Levick
da3995f0ec Remove lint pass on borrow and deref 2021-03-03 11:23:14 +01:00
Ryan Levick
a6d926d80d Fix tests 2021-03-03 11:22:44 +01:00
Ryan Levick
f49ed7a6b7 Add tests and support two more noop methods 2021-03-03 11:22:17 +01:00
Ryan Levick
040735c110 First version of noop-lint 2021-03-03 11:22:16 +01:00
Yuki Okushi
5e68c60406
Rollup merge of #82516 - PoignardAzur:inherent-impl-ty, r=oli-obk
Add incomplete feature gate for inherent associate types.

Mentored by ``````@oli-obk``````

So far the only change is that instead of giving an automatic error, the following code compiles:

```rust
struct Foo;

impl Foo {
    type Bar = isize;
}
```

The backend work to make it actually usable isn't there yet. In particular, this:

```rust
let x : Foo::Bar;
```

will give you:

```sh
error[E0223]: ambiguous associated type
  --> /$RUSTC_DIR/src/test/ui/assoc-inherent.rs:15:13
   |
LL |     let x : Foo::Bar;
   |             ^^^^^^^^ help: use fully-qualified syntax: `<Foo as Trait>::Bar`
```
2021-03-02 21:23:15 +09:00
Joshua Nelson
cc62018e61 Rename rustdoc lints to be a tool lint instead of built-in.
- Rename `broken_intra_doc_links` to `rustdoc::broken_intra_doc_links`
- Ensure that the old lint names still work and give deprecation errors
- Register lints even when running doctests

  Otherwise, all `rustdoc::` lints would be ignored.

- Register all existing lints as removed

  This unfortunately doesn't work with `register_renamed` because tool
  lints have not yet been registered when rustc is running. For similar
  reasons, `check_backwards_compat` doesn't work either. Call
  `register_removed` directly instead.

- Fix fallout

  + Rustdoc lints for compiler/
  + Rustdoc lints for library/

Note that this does *not* suggest `rustdoc::broken_intra_doc_links` for
`rustdoc::intra_doc_link_resolution_failure`, since there was no time
when the latter was valid.
2021-03-01 19:29:15 -05:00
Cameron Steffen
6a3b834b39 Use diagnostic items in into_iter_collections 2021-03-01 09:04:11 -06:00
Cameron Steffen
eada4d1c45 Add diagnostic items 2021-03-01 09:04:11 -06:00
Cameron Steffen
4a6e67ead7 Add missing diagnostic item Symbols 2021-02-26 22:12:36 -06:00
Guillaume Gomez
0db8349fff
Rollup merge of #81940 - jhpratt:stabilize-str_split_once, r=m-ou-se
Stabilize str_split_once

Closes #74773
2021-02-26 15:52:29 +01:00
bors
98f8cce6db Auto merge of #82447 - Amanieu:legacy_const_generics, r=oli-obk
Add #[rustc_legacy_const_generics]

This is the first step towards removing `#[rustc_args_required_const]`: a new attribute is added which rewrites function calls of the form `func(a, b, c)` to `func::<{b}>(a, c)`. This allows previously stabilized functions in `stdarch` which use `rustc_args_required_const` to use const generics instead.

This new attribute is not intended to ever be stabilized, it is only intended for use in `stdarch` as a replacement for `#[rustc_args_required_const]`.

```rust
#[rustc_legacy_const_generics(1)]
pub fn foo<const Y: usize>(x: usize, z: usize) -> [usize; 3] {
    [x, Y, z]
}

fn main() {
    assert_eq!(foo(0 + 0, 1 + 1, 2 + 2), [0, 2, 4]);
    assert_eq!(foo::<{1 + 1}>(0 + 0, 2 + 2), [0, 2, 4]);
}
```

r? `@oli-obk`
2021-02-25 18:14:50 +00:00
Olivier FAURE
4f4e15d5eb Add feature gate for inherent associate types. 2021-02-25 14:10:25 +01:00
Mara Bos
d3b564c3d7 Pick the injected prelude based on the edition. 2021-02-25 12:47:58 +01:00
Amanieu d'Antras
d87eec1bf6 Add #[rustc_legacy_const_generics] 2021-02-23 17:25:55 +00:00
Dylan DPC
e2561c58a4
Rollup merge of #82296 - spastorino:pubrules, r=nikomatsakis
Support `pub` on `macro_rules`

This rebases and updates `since` version of #78166 from ``@petrochenkov``

r? ``@nikomatsakis``
2021-02-23 16:10:23 +01:00
Dylan DPC
547b3adfe4
Rollup merge of #82113 - m-ou-se:panic-format-lint, r=estebank
Improve non_fmt_panic lint.

This change:
- fixes the span used by this lint in the case the panic argument is a single macro expansion (e.g. `panic!(a!())`);
- adds a suggestion for `panic!(format!(..))` to remove `format!()` instead of adding `"{}", ` or using `panic_any` like it does now; and
- fixes the incorrect suggestion to replace `panic![123]` by `panic_any(123]`.

Fixes #82109.
Fixes #82110.
Fixes #82111.

Example output:
```
warning: panic message is not a string literal
 --> src/main.rs:8:12
  |
8 |     panic!(format!("error: {}", "oh no"));
  |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(non_fmt_panic)]` on by default
  = note: this is no longer accepted in Rust 2021
  = note: the panic!() macro supports formatting, so there's no need for the format!() macro here
help: remove the `format!(..)` macro call
  |
8 |     panic!("error: {}", "oh no");
  |           --                  --

```

r? `@estebank`
2021-02-23 16:10:21 +01:00
Dylan DPC
b8d4354099
Rollup merge of #82128 - anall:feature/add_diagnostic_items, r=davidtwco
add diagnostic items for OsString/PathBuf/Owned as well as to_vec on slice

This is adding diagnostic items to be used by rust-lang/rust-clippy#6730, but my understanding is the clippy-side change does need to be done over there since I am adding a new clippy feature.

Add diagnostic items to the following types:
  OsString (os_string_type)
  PathBuf (path_buf_type)
  Owned (to_owned_trait)

As well as the to_vec method on slice/[T]
2021-02-23 02:51:51 +01:00
Vadim Petrochenkov
0fddc2f780
Support pub on macro_rules 2021-02-19 13:52:57 -03:00
Eduard-Mihai Burtescu
6165d1cc72 Print -Ztime-passes (and misc stats/logs) on stderr, not stdout. 2021-02-18 14:13:38 +02:00
bors
d1462d8558 Auto merge of #81172 - SimonSapin:ptr-metadata, r=oli-obk
Implement RFC 2580: Pointer metadata & VTable

RFC: https://github.com/rust-lang/rfcs/pull/2580

~~Before merging this PR:~~

* [x] Wait for the end of the RFC’s [FCP to merge](https://github.com/rust-lang/rfcs/pull/2580#issuecomment-759145278).
* [x] Open a tracking issue: https://github.com/rust-lang/rust/issues/81513
* [x] Update `#[unstable]` attributes in the PR with the tracking issue number

----

This PR extends the language with a new lang item for the `Pointee` trait which is special-cased in trait resolution to implement it for all types. Even in generic contexts, parameters can be assumed to implement it without a corresponding bound.

For this I mostly imitated what the compiler was already doing for the `DiscriminantKind` trait. I’m very unfamiliar with compiler internals, so careful review is appreciated.

This PR also extends the standard library with new unstable APIs in `core::ptr` and `std::ptr`:

```rust
pub trait Pointee {
    /// One of `()`, `usize`, or `DynMetadata<dyn SomeTrait>`
    type Metadata: Copy + Send + Sync + Ord + Hash + Unpin;
}

pub trait Thin = Pointee<Metadata = ()>;

pub const fn metadata<T: ?Sized>(ptr: *const T) -> <T as Pointee>::Metadata {}

pub const fn from_raw_parts<T: ?Sized>(*const (), <T as Pointee>::Metadata) -> *const T {}
pub const fn from_raw_parts_mut<T: ?Sized>(*mut (),<T as Pointee>::Metadata) -> *mut T {}

impl<T: ?Sized> NonNull<T> {
    pub const fn from_raw_parts(NonNull<()>, <T as Pointee>::Metadata) -> NonNull<T> {}

    /// Convenience for `(ptr.cast(), metadata(ptr))`
    pub const fn to_raw_parts(self) -> (NonNull<()>, <T as Pointee>::Metadata) {}
}

impl<T: ?Sized> *const T {
    pub const fn to_raw_parts(self) -> (*const (), <T as Pointee>::Metadata) {}
}

impl<T: ?Sized> *mut T {
    pub const fn to_raw_parts(self) -> (*mut (), <T as Pointee>::Metadata) {}
}

/// `<dyn SomeTrait as Pointee>::Metadata == DynMetadata<dyn SomeTrait>`
pub struct DynMetadata<Dyn: ?Sized> {
    // Private pointer to vtable
}

impl<Dyn: ?Sized> DynMetadata<Dyn> {
    pub fn size_of(self) -> usize {}
    pub fn align_of(self) -> usize {}
    pub fn layout(self) -> crate::alloc::Layout {}
}

unsafe impl<Dyn: ?Sized> Send for DynMetadata<Dyn> {}
unsafe impl<Dyn: ?Sized> Sync for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Debug for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Unpin for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Copy for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Clone for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Eq for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> PartialEq for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Ord for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> PartialOrd for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Hash for DynMetadata<Dyn> {}
```

API differences from the RFC, in areas noted as unresolved questions in the RFC:

* Module-level functions instead of associated `from_raw_parts` functions on `*const T` and `*mut T`, following the precedent of `null`, `slice_from_raw_parts`, etc.
* Added `to_raw_parts`
2021-02-18 04:22:16 +00:00
Dylan DPC
d223250662
Rollup merge of #81860 - osa1:issue81800, r=estebank
Fix SourceMap::start_point

`start_point` needs to return the *first* character's span, but it would
previously call `find_width_of_character_at_span` which returns the span
of the *last* character. The implementation is now fixed.

Other changes:

- Docs for start_point, end_point, find_width_of_character_at_span
  updated

- Minor simplification in find_width_of_character_at_span code

Fixes #81800
2021-02-17 23:51:14 +01:00
bors
8fe989dd76 Auto merge of #81611 - cjgillot:meowner, r=estebank
Only store a LocalDefId in some HIR nodes

Some HIR nodes are guaranteed to be HIR owners: Item, TraitItem, ImplItem, ForeignItem and MacroDef.
As a consequence, we do not need to store the `HirId`'s `local_id`, and we can directly store a `LocalDefId`.

This allows to avoid a bit of the dance with `tcx.hir().local_def_id` and `tcx.hir().local_def_id_to_hir_id` mappings.
2021-02-16 22:14:32 +00:00
Andrea Nall
67fcaaaa7a a few more diagnostic items 2021-02-16 02:32:21 +00:00
Andrea Nall
c6bb62810a requested/proposed changes 2021-02-15 22:59:47 +00:00
Camille GILLOT
cebbba081e Only store a LocalDefId in hir::Item.
Items are guaranteed to be HIR owner.
2021-02-15 19:32:10 +01:00