Commit Graph

129 Commits

Author SHA1 Message Date
Camille GILLOT
a987bbb97c Remove hir::Crate::attrs. 2021-03-09 19:22:55 +01:00
Camille GILLOT
c05c90275c Remove hir::MacroDef::attrs. 2021-03-09 19:09:36 +01:00
Camille GILLOT
fd8a021757 Remove hir::GenericParam::attrs. 2021-03-09 19:09:36 +01:00
Camille GILLOT
7ea1eacb17 Remove hir::Local::attrs. 2021-03-09 19:09:35 +01:00
Camille GILLOT
ff79ad394f Remove hir::StmtKind::attrs. 2021-03-09 19:09:35 +01:00
Camille GILLOT
4bb07bedf5 Visit attributes in one go. 2021-03-09 19:09:34 +01:00
Camille GILLOT
8e816056a5 Do not store attrs in FnKind. 2021-03-09 19:09:33 +01:00
Camille GILLOT
1fb257b3b4 Collect attributes during HIR lowering. 2021-03-09 18:51:37 +01:00
Camille GILLOT
d50ca3cbee Introduce HirIdVec. 2021-03-09 18:51:36 +01:00
Mara Bos
bb9542b016
Rollup merge of #82841 - hvdijk:x32, r=joshtriplett
Change x64 size checks to not apply to x32.

Rust contains various size checks conditional on target_arch = "x86_64", but these checks were never intended to apply to x86_64-unknown-linux-gnux32. Add target_pointer_width = "64" to the conditions.
2021-03-09 09:05:24 +00: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
Harald van Dijk
95e096d623
Change x64 size checks to not apply to x32.
Rust contains various size checks conditional on target_arch = "x86_64",
but these checks were never intended to apply to
x86_64-unknown-linux-gnux32. Add target_pointer_width = "64" to the
conditions.
2021-03-06 16:02:48 +00:00
Tomasz Miąsko
481e1fd3a8 Miscellaneous inlining improvements
Inline a few small and hot functions.
2021-02-26 00:00:00 +00:00
Ömer Sinan Ağacan
fa74d489a2 Improve error msgs when found type is deref of expected
This improves help messages in two cases:

- When expected type is `T` and found type is `&T`, we now look through blocks
  and suggest dereferencing the expression of the block, rather than the whole
  block.

- In the above case, if the expression is an `&`, we not suggest removing the
  `&` instead of adding `*`.

Both of these are demonstrated in the regression test. Before this patch the
first error in the test would be:

    error[E0308]: `if` and `else` have incompatible types
     --> test.rs:8:9
      |
    5 | /     if true {
    6 | |         a
      | |         - expected because of this
    7 | |     } else {
    8 | |         b
      | |         ^ expected `usize`, found `&usize`
    9 | |     };
      | |_____- `if` and `else` have incompatible types
      |
    help: consider dereferencing the borrow
      |
    7 |     } else *{
    8 |         b
    9 |     };
      |

Now:

    error[E0308]: `if` and `else` have incompatible types
     --> test.rs:8:9
      |
    5 | /     if true {
    6 | |         a
      | |         - expected because of this
    7 | |     } else {
    8 | |         b
      | |         ^
      | |         |
      | |         expected `usize`, found `&usize`
      | |         help: consider dereferencing the borrow: `*b`
    9 | |     };
      | |_____- `if` and `else` have incompatible types

The second error:

    error[E0308]: `if` and `else` have incompatible types
      --> test.rs:14:9
       |
    11 | /     if true {
    12 | |         1
       | |         - expected because of this
    13 | |     } else {
    14 | |         &1
       | |         ^^ expected integer, found `&{integer}`
    15 | |     };
       | |_____- `if` and `else` have incompatible types
       |
    help: consider dereferencing the borrow
       |
    13 |     } else *{
    14 |         &1
    15 |     };
       |

now:

    error[E0308]: `if` and `else` have incompatible types
      --> test.rs:14:9
       |
    11 | /     if true {
    12 | |         1
       | |         - expected because of this
    13 | |     } else {
    14 | |         &1
       | |         ^-
       | |         ||
       | |         |help: consider removing the `&`: `1`
       | |         expected integer, found `&{integer}`
    15 | |     };
       | |_____- `if` and `else` have incompatible types

Fixes #82361
2021-02-23 10:50:06 +03:00
Dylan DPC
5d90e89c36
Rollup merge of #81769 - estebank:tail-expr-as-potential-return, r=lcnr
Suggest `return`ing tail expressions that match return type

Some newcomers are confused by the behavior of tail expressions,
interpreting that "leaving out the `;` makes it the return value".
To help them go in the right direction, suggest using `return` instead
when applicable.
2021-02-23 02:51:46 +01:00
Esteban Küber
fc6c19e2dc fix rebase 2021-02-21 23:15:59 -08:00
Esteban Küber
d669882f38 Do not suggest ; if expression is side effect free
When a tail expression isn't unit, we previously always suggested adding
a trailing `;` to turn it into a statement. This suggestion isn't
appropriate for any expression that doesn't have side-effects, as the
user will have likely wanted to call something else or do something with
the resulting value, instead of just discarding it.
2021-02-21 16:34:37 -08:00
Simon Vandel Sillesen
2d1e0adfe9 New pass to deduplicate blocks 2021-02-21 21:51:54 +01:00
Dylan DPC
30f39fee9d
Rollup merge of #82238 - petrochenkov:nocratemod, r=Aaron1011
ast: Keep expansion status for out-of-line module items

I.e. whether a module `mod foo;` is already loaded from a file or not.
This is a pre-requisite to correctly treating inner attributes on such modules (https://github.com/rust-lang/rust/issues/81661).

With this change AST structures for `mod` items diverge even more for AST structure for the crate root, which previously used `ast::Mod`.
Therefore this PR removes `ast::Mod` from `ast::Crate` in the first commit, these two things are sufficiently different from each other, at least at syntactic level.
Customization points for visiting a "`mod` item or crate root" were also removed from AST visitors (`fn visit_mod`).
`ast::Mod` itself was refactored away in the second commit in favor of `ItemKind::Mod(Unsafe, ModKind)`.
2021-02-19 02:49:08 +01:00
Dylan DPC
f468fd1d23
Rollup merge of #81496 - guswynn:expected_async_block, r=oli-obk
name async generators something more human friendly in type error diagnostic

fixes #81457

Some details:

1. I opted to load the generator kind from the hir in TyCategory. I also use 1 impl in the hir for the descr
2. I named both the source of the future, in addition to the general type (`future`), not sure what is preferred
3. I am not sure what is required to make sure "generator" is not referred to anywhere. A brief `rg "\"generator\"" showed me that most diagnostics correctly distinguish from generators and async generator, but the `descr` of `DefKind` is pretty general (not sure how thats used)
4. should the descr impl of AsyncGeneratorKind use its display impl instead of copying the string?
2021-02-19 02:49:00 +01:00
Gus Wynn
3e7ea401cd ignore file length 2021-02-18 08:17:43 -08:00
Dylan DPC
66211f6657
Rollup merge of #82066 - matthewjasper:trait-ref-fix, r=jackh726
Ensure valid TraitRefs are created for GATs

This fixes `ProjectionTy::trait_ref` to use the correct substs. Places that need all of the substs have been updated to not use `trait_ref`.

r? ````@jackh726````
2021-02-18 16:57:34 +01:00
Vadim Petrochenkov
eb65f15c78 ast: Stop using Mod in Crate
Crate root is sufficiently different from `mod` items, at least at syntactic level.

Also remove customization point for "`mod` item or crate root" from AST visitors.
2021-02-18 13:07:49 +03: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
Camille GILLOT
7dd1e8cfdf Trait impls are Items, therefore HIR owners. 2021-02-15 19:36:13 +01:00
Camille GILLOT
c4e7427081 Only store a LocalDefId in hir::MacroDef. 2021-02-15 19:35:55 +01:00
Camille GILLOT
ff14cac621 Index Modules using their LocalDefId. 2021-02-15 19:32:30 +01:00
Camille GILLOT
996dc8d5c5 Only store a LocalDefId in hir::ForeignItem. 2021-02-15 19:32:29 +01:00
Camille GILLOT
786a80e9ea Only store a LocalDefId in hir::ImplItem. 2021-02-15 19:32:29 +01:00
Camille GILLOT
a871a0f111 Only store a LocalDefId in hir::TraitItem. 2021-02-15 19:32:28 +01: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
Camille GILLOT
bd3cd5dbed Use an ItemId inside mir::GlobalAsm. 2021-02-15 19:24:58 +01:00
Camille GILLOT
c676e358a5 Use ItemId as a strongly typed index. 2021-02-15 19:24:58 +01:00
Camille GILLOT
ac8961fc04 Add assertions on HIR enum sizes. 2021-02-15 19:24:57 +01:00
Gus Wynn
c28d86c53b name async generators something more human friendly in type error diagnostics 2021-02-15 08:51:08 -08:00
Simon Sapin
696b239f72 Add ptr::Pointee trait (for all types) and ptr::metadata function
RFC: https://github.com/rust-lang/rfcs/pull/2580
2021-02-15 14:27:12 +01:00
Dylan DPC
e3b2655c3a
Rollup merge of #81720 - klensy:smallvec-update, r=Mark-Simulacrum
Updated smallvec version due to RUSTSEC-2021-0003

Hi.

Updated Cargo.toml's for smallvec due to RUSTSEC-2021-0003 and Cargo.toml in separate commit.

Affected function `SmallVec::insert_many` looks like don't was used directly in rust, but can be somewhere in deps.

There should be some mechanism to not to do this kind of things manually, like dependabot. Actually, dependabot supports rust and can check security articles (at least that noted in description).
2021-02-14 16:54:44 +01:00
Dylan DPC
ac1d26bcd3
Rollup merge of #80920 - rylev:check_attr-refactor, r=davidtwco
Visit more targets when validating attributes

This begins to address #80048, allowing for additional validation of attributes.

There are more refactorings that can be done, though I think they should be tackled in additional PRs:
* ICE when a builtin attribute is encountered that is not checked
* Move some of the attr checking done `ast_validation` into `rustc_passes`
  * note that this requires a bit of additional refactoring, especially of extern items which currently parse attributes (and thus are a part of the AST) but do not possess attributes in their HIR representation.
* Rename `Target` to `AttributeTarget`
* Refactor attribute validation completely to go through `Visitor::visit_attribute`.
  * This would require at a minimum passing `Target` into this method which might be too big of a refactoring to be worth it.
  * It's also likely not possible to do all the validation this way as some validation requires knowing what other attributes a target has.

r? `@davidtwco`
2021-02-14 16:54:42 +01:00
klensy
93c8ebe022 bumped smallvec deps 2021-02-14 18:03:11 +03:00
Matthew Jasper
9bbd3e0f8e Remove ProjectionTy::from_ref_and_name 2021-02-13 19:29:55 +00:00
Ryan Levick
396022b90b Visit more targets when checking attrs 2021-02-09 21:54:46 +01:00
Ömer Sinan Ağacan
c4e3558b8c Rename HIR UnOp variants
This renames the variants in HIR UnOp from

    enum UnOp {
        UnDeref,
        UnNot,
        UnNeg,
    }

to

    enum UnOp {
        Deref,
        Not,
        Neg,
    }

Motivations:

- This is more consistent with the rest of the code base where most enum
  variants don't have a prefix.

- These variants are never used without the `UnOp` prefix so the extra
  `Un` prefix doesn't help with readability. E.g. we don't have any
  `UnDeref`s in the code, we only have `UnOp::UnDeref`.

- MIR `UnOp` type variants don't have a prefix so this is more
  consistent with MIR types.

- "un" prefix reads like "inverse" or "reverse", so as a beginner in
  rustc code base when I see "UnDeref" what comes to my mind is
  something like "&*" instead of just "*".
2021-02-09 11:39:20 +03:00
Jonas Schievink
85fb5cdf26
Rollup merge of #81680 - camsteffen:primty, r=oli-obk
Refactor `PrimitiveTypeTable` for Clippy

I removed `PrimitiveTypeTable` and added `PrimTy::ALL` and `PrimTy::from_name` in its place. This allows Clippy to use `PrimTy::from_name` for the `builtin_type_shadow` lint, and a `const` list of primitive types is deleted from Clippy code (the goal). All changes should be a little faster, if anything.
2021-02-06 17:01:45 +01:00
Mara Bos
deec6a96d4
Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths, r=jackh726
Generic associated types in trait paths

This is the second part of https://github.com/rust-lang/rust/pull/78978

This should fix:

Fixes #67510
Fixes #68648
Fixes #68649
Fixes #68650
Fixes #68652
Fixes #74684
Fixes #76535
Fixes #79422
Fixes #80433

and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265

r? ``@matthewjasper``
2021-02-05 12:25:50 +01:00
Michael Woerister
9e5054498b Add unit test to ensure that both parts of a DefPathHash depend on the defining crate's ID. 2021-02-04 16:33:58 +01:00
b-naber
fdaf603102 add generic args to hir::TypeBinding 2021-02-04 16:20:56 +01:00
Mara Bos
24e0940169 Stabilize feature(iterator_fold_self): Iterator::reduce 2021-02-04 11:31:11 +01:00
Mara Bos
5c056ed2f5 Rename Iterator::fold_first to reduce. 2021-02-04 11:30:42 +01:00
Michael Woerister
97380e3b06 Add more explanation to local DefPathHash collision case. 2021-02-04 11:01:52 +01:00
Cameron Steffen
fba747a06e Refactor out PrimitiveTypeTable 2021-02-03 08:32:23 -06:00