Commit Graph

479 Commits

Author SHA1 Message Date
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
Camelid
4b3490f64d Convert some lang item comments to doc-comments 2021-02-28 12:05:07 -08:00
Camelid
da0099a9ff Enable extended_key_value_attributes in rustc_hir 2021-02-28 11:56:16 -08:00
Camelid
e5f1e8883a Improve lang item generated docs
cc https://rust-lang.zulipchat.com/#narrow/stream/146229-wg-secure-code/topic/Is.20.60core.60.20part.20of.20the.20compiler.3F/near/226738260
2021-02-28 11:43:25 -08: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
Michael Woerister
22d489be76 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.

It also allows to reliably and cheaply check for DefPathHash collisions.
2021-02-02 17:40:29 +01:00
Mark Rousskov
d5b760ba62 Bump rustfmt version
Also switches on formatting of the mir build module
2021-02-02 09:09:52 -05:00
Danuel
8bbb2d057d Fixed #[inline] to be warned in fields, arms, macro defs
Add visitors for checking #[inline]

Add visitors for checking #[inline] with struct field

Fix test for #[inline]

Add visitors for checking #[inline] with #[macro_export] macro

Add visitors for checking #[inline] without #[macro_export] macro

Add use alias with Visitor

Fix lint error

Reduce unnecessary variable

Co-authored-by: LingMan <LingMan@users.noreply.github.com>

Change error to warning

Add warning for checking field, arm with #[allow_internal_unstable]

Add name resolver

Formatting

Formatting

Fix error fixture

Add checking field, arm, macro def
2021-02-01 23:36:19 +09:00
Jonas Schievink
1e99f26894
Rollup merge of #80470 - SimonSapin:array-intoiter-type, r=m-ou-se
Stabilize by-value `[T; N]` iterator `core::array::IntoIter`

Tracking issue: https://github.com/rust-lang/rust/issues/65798

This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135.

This PR does *not* include the corresponding `IntoIterator` impl, which is https://github.com/rust-lang/rust/pull/65819. Instead, an iterator can be constructed through the `new` method.

`new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then, although it will stay stable.
2021-01-31 01:47:25 +01:00
bors
78e22069d0 Auto merge of #81393 - pnkfelix:issue-81296-make-weak-item-traversal-deterministic, r=estebank
Make weak item traversal deterministic

Fix #81296.

(No test added. The relevant test *is* ui/panic-handler/weak-lang-item.rs, and this change should make it less flaky.)
2021-01-27 00:19:45 +00:00
bors
a8f7075532 Auto merge of #80692 - Aaron1011:feature/query-result-debug, r=estebank
Enforce that query results implement Debug

Currently, we require that query keys implement `Debug`, but we do not do the same for query values. This can make incremental compilation bugs difficult to debug - there isn't a good place to print out the result loaded from disk.

This PR adds `Debug` bounds to several query-related functions, allowing us to debug-print the query value when an 'unstable fingerprint' error occurs. This required adding `#[derive(Debug)]` to a fairly large number of types - hopefully, this doesn't have much of an impact on compiler bootstrapping times.
2021-01-26 05:47:23 +00:00
Felix S. Klock II
4c5ede7c6a This should address issue 81294.
(No test added. The relevant test *is* ui/panic-handler/weak-lang-item.rs, and this change should make it less flaky.)
2021-01-25 14:37:27 -05:00
bors
85e355ea9b Auto merge of #80919 - cjgillot:defkey-span, r=oli-obk
Generate metadata by iterating on DefId instead of traversing the HIR tree 1/N

Sample from #80347.
2021-01-24 06:51:17 +00:00
Camille GILLOT
c58a6fa422 Iterate DefId to encode spans. 2021-01-23 13:44:02 +01:00
Esteban Küber
060dba67b7 Add loop head span to hir 2021-01-21 21:41:46 -08:00
Aaron Hill
7afb32557d
Enforce that query results implement Debug 2021-01-16 17:53:02 -05:00
Vadim Petrochenkov
7f9a2cfa1b resolve: Reject ambiguity built-in attr vs different built-in attr 2021-01-17 01:48:17 +03:00
LingMan
a56bffb4f9 Use Option::map_or instead of .map(..).unwrap_or(..) 2021-01-14 19:23:59 +01:00
bors
d03fe84169 Auto merge of #79328 - c410-f3r:hir-if, r=matthewjasper
Reintroduce hir::ExprKind::If

Basically copied and paste #59288/https://github.com/rust-lang/rust-clippy/pull/4080 with some modifications.

The vast majority of tests were fixed and now there are only a few remaining. Since I am still unable to figure out the missing pieces, any help with the following list is welcome.

- [ ] **Unnecessary `typeck` exception**: [Cheated on this one to make CI green.](https://github.com/rust-lang/rust/pull/79328/files#diff-3faee9ba23fc54a12b7c43364ba81f8c5660045c7e1d7989a02a0cee1c5b2051)
- [x] **Incorrect span**: [Span should reference `then` and `else` separately.](https://github.com/rust-lang/rust/pull/79328/files#diff-cf2c46e82222ee4b1037a68fff8a1af3c4f1de7a6b3fd798aacbf3c0475abe3d)
- [x] **New note regarding `assert!`**: [Modified but not "wrong". Maybe can be a good thing?](https://github.com/rust-lang/rust/pull/79328/files#diff-9e0d7c89ed0224e2b62060c957177c27db43c30dfe3c2974cb6b5091cda9cfb5)
- [x] **Inverted report location**: [Modified but not "wrong". Locations were inverted.](https://github.com/rust-lang/rust/pull/79328/files#diff-f637ce7c1f68d523a165aa9651765df05e36c4d7d279194b1a6b28b48a323691)
- [x] **`src/test/ui/point-to-type-err-cause-on-impl-trait-return.rs` has weird errors**: [Not sure why this is happening.](https://github.com/rust-lang/rust/pull/79328/files#diff-c823c09660f5b112f95e97e8ff71f1797b6c7f37dbb3d16f8e98bbaea8072e95)
- [x] **Missing diagnostic**: [???](https://github.com/rust-lang/rust/pull/79328/files#diff-6b8ab09360d725ba4513933827f9796b42ff9522b0690f80b76de067143af2fc)
2021-01-14 14:41:58 +00:00
bors
a62a76047e Auto merge of #77524 - Patryk27:fixes/66228, r=estebank
Rework diagnostics for wrong number of generic args (fixes #66228 and #71924)

This PR reworks the `wrong number of {} arguments` message, so that it provides more details and contextual hints.
2021-01-13 20:35:58 +00:00
Joshua Nelson
a8ff647deb Separate out a hir::Impl struct
This makes it possible to pass the `Impl` directly to functions, instead
of having to pass each of the many fields one at a time. It also
simplifies matches in many cases.
2021-01-12 20:32:33 -05:00
Patryk Wychowaniec
d2f8e398f1
Rework diagnostics for wrong number of generic args 2021-01-10 13:07:40 +01:00
Caio
f85fc264fe Reintroduce hir::ExprKind::If 2021-01-07 18:54:12 -03:00
Yuki Okushi
be2a3f8642
Rollup merge of #80538 - JulianKnodt:err_usize, r=lcnr
Add check for `[T;N]`/`usize` mismatch in astconv

Helps clarify the issue in #80506
by adding a specific check for mismatches between [T;N] and usize.

r? `@lcnr`
2021-01-05 09:52:37 +09:00
kadmin
54883e0a1c Add check for array/usize mismatch in astconv 2021-01-04 10:07:15 +00:00
Matthias Krüger
8a90626a46 reduce borrowing and (de)referencing around match patterns (clippy::match_ref_pats) 2021-01-02 20:09:17 +01:00
Julian Knodt
61f33bfd29 first pass at default values for const generics
- Adds optional default values to const generic parameters in the AST
  and HIR
- Parses these optional default values
- Adds a `const_generics_defaults` feature gate
2021-01-01 10:55:10 +01:00
Dylan DPC
96c11f98d7
Rollup merge of #80551 - lcnr:const-arg-wildcard, r=varkor
support pattern as const parents in type_of

nice to know that there's still stuff about rust i didn't know about 😆

fixes #80531

r? `@varkor`
2020-12-31 22:21:00 +01:00
Bastian Kauschke
2aef46b17b support pattern as const parents in type_of 2020-12-31 14:10:49 +01:00
Mara Bos
9e8edc8c22
Rollup merge of #80495 - jyn514:rename-empty, r=petrochenkov
Rename kw::Invalid -> kw::Empty

See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Is.20there.20a.20symbol.20for.20the.20empty.20string.3F/near/220054471
for context.

r? `@petrochenkov`
2020-12-30 20:56:58 +00:00
Joshua Nelson
edeac1778c Rename kw::Invalid -> kw::Empty
See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Is.20there.20a.20symbol.20for.20the.20empty.20string.3F/near/220054471
for context.
2020-12-30 09:50:02 -05:00
Vadim Petrochenkov
4d2d0bad4e Remove compile-fail test suite 2020-12-29 23:39:56 +03:00
Simon Sapin
61c49d4042 Stabilize by-value [T; N] iterator core::array::IntoIter
Tracking issue: https://github.com/rust-lang/rust/issues/65798

This is unblocked now that `min_const_generics` has been stabilized
in https://github.com/rust-lang/rust/pull/79135.

This PR does *not* include the corresponding `IntoIterator` impl,
which is https://github.com/rust-lang/rust/pull/65819.
Instead, an iterator can be constructed through the `new` method.

`new` would become unnecessary when `IntoIterator` is implemented
and might be deprecated then, although it will stay stable.
2020-12-29 09:16:46 +01:00
bors
3d9ada686f Auto merge of #79073 - davidtwco:issue-78957-const-param-attrs, r=lcnr
passes: prohibit invalid attrs on generic params

Fixes #78957.

This PR modifies the `check_attr` pass so that attribute placement on generic parameters is checked for validity.

r? `@lcnr`
2020-12-19 04:32:50 +00:00
Yuki Okushi
1e1ba7c936
Rollup merge of #79051 - LeSeulArtichaut:if-let-guard, r=matthewjasper
Implement if-let match guards

Implements rust-lang/rfcs#2294 (tracking issue: #51114).

I probably should do a few more things before this can be merged:
- [x] Add tests (added basic tests, more advanced tests could be done in the future?)
- [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements)
- [x] Fix clippy

However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs.

Thanks a lot `@matthewjasper` ❤️ for helping me with lowering to MIR! Would you be interested in reviewing this?
r? `@ghost` for now
2020-12-17 11:43:55 +09:00
Tomasz Miąsko
91fe548825 Retain assembly operands span when lowering AST to HIR 2020-12-06 20:48:08 +01:00
LeSeulArtichaut
f3d4aa6afb Implement lowering of if-let guards to MIR 2020-12-06 13:42:24 +01:00
LeSeulArtichaut
77d80b22f1 Introduce if-let guards in the HIR 2020-12-06 11:48:06 +01:00
Joshua Nelson
0ad3dce83a Fix some clippy lints 2020-12-03 17:08:19 -05:00
David Wood
75eb72cc9c
passes: prohibit attrs on generic params
This commit modifies the `check_attr` pass so that attribute placement
on generic parameters is checked for validity.

Signed-off-by: David Wood <david@davidtw.co>
2020-11-29 14:05:19 +00:00
Camille GILLOT
60c3bbd844 Formatting. 2020-11-26 21:32:29 +01:00
Camille GILLOT
032f68d625 Remove ForeignMod struct. 2020-11-26 21:32:27 +01:00
Camille GILLOT
419a9186a4 Store ForeignItem in a side table. 2020-11-26 21:29:27 +01:00
Vadim Petrochenkov
69894ce9ac resolve: Introduce a separate NonMacroAttrKind for legacy derive helpers 2020-11-19 19:25:20 +03:00
Bastian Kauschke
69b43c209c improve error message for const ty param mismatch 2020-11-16 16:07:59 +01:00
Mara Bos
755dd14e00
Rollup merge of #78836 - fanzier:struct-and-slice-destructuring, r=petrochenkov
Implement destructuring assignment for structs and slices

This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: #71126). This PR is the second part of #71156, which was split up to allow for easier review.

Note that the first PR (#78748) is not merged yet, so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged, I totally understand, of course.

This PR implements destructuring assignment for (tuple) structs and slices. In order to do this, the following *parser change* was necessary: struct expressions are not required to have a base expression, i.e. `Struct { a: 1, .. }` becomes legal (in order to act like a struct pattern).

Unfortunately, this PR slightly regresses the diagnostics implemented in #77283. However, it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet, I was hoping it's OK to regress this temporarily and fix it in a follow-up PR.

Thanks to ``@varkor`` who helped with the implementation, particularly around the struct rest changes.

r? ``@petrochenkov``
2020-11-12 19:46:09 +01:00
Fabian Zaiser
de84ad95b4 Implement destructuring assignment for structs and slices
Co-authored-by: varkor <github@varkor.com>
2020-11-11 12:10:52 +00:00
Nicholas-Baron
261ca04c92 Changed unwrap_or to unwrap_or_else in some places.
The discussion seems to have resolved that this lint is a bit "noisy" in
that applying it in all places would result in a reduction in
readability.

A few of the trivial functions (like `Path::new`) are fine to leave
outside of closures.

The general rule seems to be that anything that is obviously an
allocation (`Box`, `Vec`, `vec![]`) should be in a closure, even if it
is a 0-sized allocation.
2020-11-10 20:07:47 -08:00
Dylan DPC
abaa78baeb
Rollup merge of #78748 - fanzier:tuple-assignment, r=petrochenkov
Implement destructuring assignment for tuples

This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909, tracking issue: #71126). This PR is the first part of #71156, which was split up to allow for easier review.

Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple.
It is implemented via a desugaring (AST -> HIR lowering) as follows:
```rust
(a,b) = (1,2)
```
... becomes ...
```rust
{
  let (lhs0,lhs1) = (1,2);
  a = lhs0;
  b = lhs1;
}
```

Thanks to `@varkor` who helped with the implementation, particularly around default binding modes.

r? `@petrochenkov`
2020-11-09 01:13:44 +01:00
Joshua Nelson
67d0db6b00 Fix handling of item names for HIR
- Handle variants, fields, macros in `Node::ident()`
- Handle the crate root in `opt_item_name`
- Factor out `item_name_from_def_id` to reduce duplication
- Look at HIR before the DefId for `opt_item_name`

  This gives accurate spans, which are not available from serialized
  metadata.

- Don't panic on the crate root in `opt_item_name`
- Add comments
2020-11-07 10:37:12 -05:00
Fabian Zaiser
3a7a997323 Implement destructuring assignment for tuples
Co-authored-by: varkor <github@varkor.com>
2020-11-07 13:17:19 +00:00
Joshua Nelson
57c6ed0c07 Fix even more clippy warnings 2020-10-30 10:13:39 -04:00
Yuki Okushi
270d2e0c2e
Rollup merge of #78224 - lcnr:repeat-expr, r=varkor
min_const_generics: allow ty param in repeat expr

implements https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/repeat.20expressions

Even with `min_const_generics` active, now keeps resulting in future compat warnings instead of hard errors.
Const parameters, for example `[0; N + 1]`, still result in hard errors during resolve.
```rust
#![allow(dead_code)]

fn foo<T>() {
    [0; std::mem::size_of::<*mut T>()];
}

struct Foo<T>(T);

impl<T> Foo<T> {
    const ASSOC: usize = 4;

    fn test() {
        [0; Self::ASSOC];
    }
}
```

r? @varkor cc @petrochenkov
2020-10-29 12:08:40 +09:00
Yuki Okushi
0a26e4ba7e
Rollup merge of #78326 - Aaron1011:fix/min-stmt-lints, r=petrochenkov
Split out statement attributes changes from #78306

This is the same as PR https://github.com/rust-lang/rust/pull/78306, but `unused_doc_comments` is modified to explicitly ignore statement items (which preserves the current behavior).

This shouldn't have any user-visible effects, so it can be landed without lang team discussion.

---------
When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.

```rust
trait Foo {
    #[allow(unused_attributes)] #[inline] fn first();
    #[inline] #[allow(unused_attributes)] fn second();
}
```

However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).

Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.

This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:

* The `HasAttr` impl for `StmtKind` now returns attributes for
  `StmtKind::Item`, treating it just like every other `StmtKind`
  variant. The only place relying on the old behavior was macro
  which has been updated to explicitly ignore attributes on item
  statements. This allows the `unused_doc_comments` lint to fire for
  item statements.
* The `early` and `late` lint visitors now activate lint attributes when
  invoking the callback for `Stmt`. This ensures that a lint
  attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
  sibiling attributes on an item statement.

For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR #78306
2020-10-25 18:43:49 +09:00
bors
3e0dd24a6c Auto merge of #77546 - lcnr:impl-trait-closure, r=eddyb
fix def collector for impl trait

fixes #77329

We now consistently make `impl Trait` a hir owner, requiring some special casing for synthetic generic params.

r? `@eddyb`
2020-10-25 07:03:58 +00:00
Aaron Hill
ac384ac2db
Fix inconsistencies in handling of inert attributes on statements
When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.

```rust
trait Foo {
    #[allow(unused_attributes)] #[inline] fn first();
    #[inline] #[allow(unused_attributes)] fn second();
}
```

However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).

Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.

This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:

* The `HasAttr` impl for `StmtKind` now returns attributes for
  `StmtKind::Item`, treating it just like every other `StmtKind`
  variant. The only place relying on the old behavior was macro
  which has been updated to explicitly ignore attributes on item
  statements. This allows the `unused_doc_comments` lint to fire for
  item statements.
* The `early` and `late` lint visitors now activate lint attributes when
  invoking the callback for `Stmt`. This ensures that a lint
  attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
  sibiling attributes on an item statement.

For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR #78306
2020-10-24 11:55:48 -04:00
Bastian Kauschke
83ecbb4a29 add tests for self with const params 2020-10-23 22:10:44 +02:00
Mara Bos
4f7ffbf351 Fix const core::panic!(non_literal_str). 2020-10-22 18:41:35 +02:00
Vadim Petrochenkov
cee5521a03 Calculate visibilities once in resolve
Then use them through a query based on resolver outputs
2020-10-19 11:57:50 +03:00
Santiago Pastorino
fe922e567f
Lower inline const down to MIR 2020-10-16 15:21:18 -03:00
Andy Russell
14b2d16c5c
ensure arguments are included in count mismatch span 2020-10-15 10:22:39 -04:00
est31
6897619d6d Remove unused code from rustc_hir 2020-10-14 04:14:32 +02:00
est31
a0fc455d30 Replace absolute paths with relative ones
Modern compilers allow reaching external crates
like std or core via relative paths in modules
outside of lib.rs and main.rs.
2020-10-13 14:16:45 +02:00
Bastian Kauschke
604bc876e0 implement nits 2020-10-07 10:19:04 +02:00
Bastian Kauschke
236689d6eb split SyntheticTyParamKind 2020-10-07 10:19:04 +02:00
Dylan DPC
9dbc9ed870
Rollup merge of #77514 - scottmcm:less-once-chain-once, r=estebank
Replace some once(x).chain(once(y)) with [x, y] IntoIter

Now that we have by-value array iterators that are [already used](25c8c53dd9/compiler/rustc_hir/src/def.rs (L305-L307))...

For example,
```diff
-        once(self.type_ns).chain(once(self.value_ns)).chain(once(self.macro_ns)).filter_map(|it| it)
+        IntoIter::new([self.type_ns, self.value_ns, self.macro_ns]).filter_map(|it| it)
```
2020-10-05 02:29:42 +02:00
Scott McMurray
d74b8e0505 Replace some once(x).chain(once(y)) with [x, y] IntoIter
Now that we have by-value array iterators...
2020-10-03 16:51:43 -07:00
Guillaume Gomez
0e68e1ba5c Prevent #[doc(alias = "...")] at crate level 2020-10-03 21:33:47 +02:00
bors
71bdb84817 Auto merge of #76955 - jyn514:refactor-diagnostics, r=euclio
Refactor and fix intra-doc link diagnostics, and fix links to primitives

Closes https://github.com/rust-lang/rust/issues/76925, closes https://github.com/rust-lang/rust/issues/76693, closes https://github.com/rust-lang/rust/issues/76692.

Originally I only meant to fix #76925. But the hack with `has_primitive` was so bad it was easier to fix the primitive issues than to try and work around it.

Note that this still has one bug: `std::primitive::i32::MAX` does not resolve. However, this fixes the ICE so I'm fine with fixing the link in a later PR.

This is part of a series of refactors to make #76467 possible.

This is best reviewed commit-by-commit; it has detailed commit messages.

r? `@euclio`
2020-09-27 08:12:29 +00:00
Ralf Jung
9e02642fb3
Rollup merge of #77211 - est31:remove_unused_allow, r=oli-obk
Remove unused #[allow(...)] statements from compiler/
2020-09-26 12:58:34 +02:00
est31
12187b7f86 Remove unused #[allow(...)] statements from compiler/ 2020-09-26 01:25:55 +02:00
marmeladema
5946c12476 Move is_raw_guess check in ty::print::pretty 2020-09-25 22:48:44 +01:00
marmeladema
35bad3edbf Address review comment 2020-09-25 22:48:44 +01:00
marmeladema
657ecdb75e Rename DefPathData::get_name() to DefPathData::name() 2020-09-25 22:46:15 +01:00
marmeladema
2708ad8bb4 Fix pretty-printing of DisambiguatedDefPathData 2020-09-25 22:46:15 +01:00
marmeladema
9f50c49117 Implement Display for DisambiguatedDefPathData and DefPathData 2020-09-25 22:46:15 +01:00
marmeladema
f1878d19fa Move from {{closure}}#0 syntax to {closure#0} for (def) path components 2020-09-25 22:46:14 +01:00
Joshua Nelson
472e52e5a0 Fix intra-doc links for primitives
- Add `PrimTy::name` and `PrimTy::name_str`
- Use those new functions to distinguish between the name in scope and
the canonical name
- Fix diagnostics for primitive types
- Add tests for primitives
2020-09-23 21:04:22 -04:00
Bastian Kauschke
c552717e9d review, improve note span 2020-09-13 22:53:51 +02:00
Bastian Kauschke
e5b82a56c5 allow concrete self types in consts 2020-09-13 22:53:51 +02:00
Joshua Nelson
3797f29aad [WIP] give better errors for broken intra doc links 2020-09-05 13:48:19 -04:00
Bastian Kauschke
cdd5d60b47 add track_caller to local_def_id_to_hir_id 2020-09-04 09:24:44 +02:00
marmeladema
67b8f9491c hir: replace lazy_static by SyncLazy from std 2020-09-01 22:06:47 +01:00
mark
9e5f7d5631 mv compiler to compiler/ 2020-08-30 18:45:07 +03:00