Commit Graph

802 Commits

Author SHA1 Message Date
Matthias Krüger
f84a734a8e
Rollup merge of #87614 - notriddle:notriddle-count2len, r=Mark-Simulacrum
Recommend fix `count()` -> `len()` on slices

Fixes #87302
2021-12-07 11:04:56 +01:00
Michael Howell
6a17ee6d41 Recommend fix count() -> len() on slices
Fixes #87302
2021-12-06 20:33:23 -07:00
Smitty
eb56693a37 Implement concat_bytes!
The tracking issue for this is #87555.
2021-12-06 21:05:13 -05:00
Andrew Dona-Couch
c6e8ae1a6c Implement inline asm! for AVR platform 2021-12-06 01:02:49 -05:00
Matthias Krüger
23012b5200
Rollup merge of #91355 - alexcrichton:stabilize-thread-local-const, r=m-ou-se
std: Stabilize the `thread_local_const_init` feature

This commit is intended to follow the stabilization disposition of the
FCP that has now finished in #84223. This stabilizes the ability to flag
thread local initializers as `const` expressions which enables the macro
to generate more efficient code for accessing it, notably removing
runtime checks for initialization.

More information can also be found in #84223 as well as the tests where
the feature usage was removed in this PR.

Closes #84223
2021-12-05 00:38:00 +01:00
Matthias Krüger
0311cfa88c
Rollup merge of #90519 - estebank:issue-84003, r=petrochenkov
Keep spans for generics in `#[derive(_)]` desugaring

Keep the spans for generics coming from a `derive`d Item, so that errors
and suggestions have better detail.

Fix #84003.
2021-12-04 10:42:20 +01:00
cynecx
686ace3b41 add unwind_asm feature gate for may_unwind option 2021-12-03 23:51:49 +01:00
Amanieu d'Antras
940b2eabad Add initial AST and MIR support for unwinding from inline assembly 2021-12-03 23:51:46 +01:00
bors
532d2b14c0 Auto merge of #90737 - eholk:intofuture, r=tmandry
Reintroduce `into_future` in `.await` desugaring

This is a reintroduction of the remaining parts from https://github.com/rust-lang/rust/pull/65244 that have not been relanded yet.

This isn't quite ready to merge yet. The last attempt was reverting due to performance regressions, so we need to make sure this does not introduce those issues again.

Issues #67644, #67982

/cc `@yoshuawuyts`
2021-12-03 19:29:21 +00:00
Esteban Kuber
962b2197a5 Annotate derived spans and move span suggestion code
* Annotate `derive`d spans from the user's code with the appropciate context
* Add `Span::can_be_used_for_suggestion` to query if the underlying span
  at the users' code
2021-12-03 18:41:40 +00:00
Mara Bos
41b1bcb40d Improve 'cannot contain emoji' error. 2021-12-03 01:20:25 +01:00
Nicholas Nethercote
66153d76e2 Improve the comments in Symbol::interner. 2021-12-03 07:12:31 +11:00
Alex Crichton
a0c959750a std: Stabilize the thread_local_const_init feature
This commit is intended to follow the stabilization disposition of the
FCP that has now finished in #84223. This stabilizes the ability to flag
thread local initializers as `const` expressions which enables the macro
to generate more efficient code for accessing it, notably removing
runtime checks for initialization.

More information can also be found in #84223 as well as the tests where
the feature usage was removed in this PR.

Closes #84223
2021-11-29 07:23:46 -08:00
Cameron Steffen
ac8d514376 Add parent crate assert to register_expn_id 2021-11-28 16:35:54 -06:00
Cameron Steffen
768cfac705 Add fast path to is_descendant_of 2021-11-28 16:35:54 -06:00
Matthias Krüger
6970cf5a23
Rollup merge of #91096 - compiler-errors:elaborate_opaque_trait, r=estebank
Print associated types on opaque `impl Trait` types

This PR generalizes #91021, printing associated types for all opaque `impl Trait` types instead of just special-casing for future.

before:
```
error[E0271]: type mismatch resolving `<impl Iterator as Iterator>::Item == u32`
```

after:
```
error[E0271]: type mismatch resolving `<impl Iterator<Item = usize> as Iterator>::Item == u32`
```

---

Questions:
1. I'm kinda lost in binders hell with this one. Is all of the `rebind`ing necessary?
2. Is there a map collection type that will give me a stable iteration order? Doesn't seem like TraitRef is Ord, so I can't just sort later..
3. I removed the logic that suppresses printing generator projection types. It creates outputs like this [gist](https://gist.github.com/compiler-errors/d6f12fb30079feb1ad1d5f1ab39a3a8d). Should I put that back?
4. I also added spaces between traits, `impl A+B` -> `impl A + B`. I quite like this change, but is there a good reason to keep it like that?

r? ````@estebank````
2021-11-25 15:05:37 +01:00
Guillaume Gomez
a6a1d7ca29
Rollup merge of #90420 - GuillaumeGomez:rustdoc-internals-feature, r=camelid
Create rustdoc_internals feature gate

As suggested by ``@camelid`` [here](https://github.com/rust-lang/rust/pull/90398#issuecomment-955093851), since `doc_keyword` and `doc_primitive` aren't meant to be stabilized, we could put them behind a same feature flag.

This is pretty much what it would look like (needs to update the tests too).

The tracking issue is https://github.com/rust-lang/rust/issues/90418.

What do you think ``@rust-lang/rustdoc`` ?
2021-11-24 22:56:37 +01:00
Guillaume Gomez
1e6ced3532 Create rustdoc_internals feature gate 2021-11-24 21:57:18 +01:00
Michael Goulet
b84a52c95a Add generator lang-item 2021-11-23 10:34:16 -08:00
Matthias Krüger
a26c2c7495
Rollup merge of #91140 - nbdd0121:const_typeck, r=oli-obk
Split inline const to two feature gates and mark expression position inline const complete

This PR splits inline const in pattern position into its own `#![feature(inline_const_pat)]` feature gate, and make the usage in expression position complete.

I think I have resolved most outstanding issues related to `inline_const` with #89561 and other PRs. The only thing left that I am aware of is #90150 and the lack of lifetime checks when inline const is used in pattern position (FIXME in #89561). Implementation-wise when used in pattern position it has to be lowered during MIR building while in expression position it's evaluated only when monomorphizing (just like normal consts), so it makes some sense to separate it into two feature gates so one can progress without being blocked by another.

``@rustbot`` label: T-compiler F-inline_const
2021-11-23 19:28:10 +01:00
Matthias Krüger
68a44c8228
Rollup merge of #90856 - ken-matsui:suggestion-to-wrap-vec-allocator-api-in-tuple, r=davidtwco
Suggestion to wrap inner types using 'allocator_api' in tuple

This PR provides a suggestion to wrap the inner types in tuple when being along with 'allocator_api'.

Closes https://github.com/rust-lang/rust/issues/83250

```rust
fn main() {
    let _vec: Vec<u8, _> = vec![]; //~ ERROR use of unstable library feature 'allocator_api'
}
```

```diff
 error[E0658]: use of unstable library feature 'allocator_api'
   --> $DIR/suggest-vec-allocator-api.rs:2:23
    |
 LL |     let _vec: Vec<u8, _> = vec![];
-   |                       ^
+   |                   ----^
+   |                   |
+   |                   help: consider wrapping the inner types in tuple: `(u8, _)`
    |
    = note: see issue #32838 <https://github.com/rust-lang/rust/issues/32838> for more information
    = help: add `#![feature(allocator_api)]` to the crate attributes to enable
```
2021-11-23 19:28:06 +01:00
Ken Matsui
57494f7c75
Suggestion to wrap inner types using allocator_api in tuple 2021-11-24 00:24:13 +09:00
Eric Holk
dfa0db5961 Reintroduce into_future in .await desugaring
This is a reintroduction of the remaining parts from
https://github.com/rust-lang/rust/pull/65244 that have not been relanded
yet.

Issues GH-67644, GH-67982
2021-11-22 14:57:27 -08:00
Gary Guo
6d61d87b22 Split inline const to two feature gates 2021-11-22 22:17:03 +00:00
Cameron Steffen
9c83f8c4d1 Simplify for loop desugar 2021-11-21 08:15:21 -06:00
Matthias Krüger
79935714f3
Rollup merge of #90930 - Nilstrieb:fix-non-const-value-ice, r=estebank
Fix `non-constant value` ICE (#90878)

This also fixes the same suggestion, which was kind of broken, because it just searched for the last occurence of `const` to replace with a `let`. This works great in some cases, but when there is no const and a leading space to the file, it doesn't work and panic with overflow because it thought that it had found a const.

I also changed the suggestion to only trigger if the `const` and the non-constant value are on the same line, because if they aren't, the suggestion is very likely to be wrong.

Also don't trigger the suggestion if the found `const` is on line 0, because that triggers the ICE.

Asking Esteban to review since he was the last one to change the relevant code.

r? ``@estebank``

Fixes #90878
2021-11-20 10:21:14 +01:00
Matthias Krüger
7354bb331e
Rollup merge of #90575 - m-ou-se:compatible-variant-improvements, r=estebank
Improve suggestions for compatible variants on type mismatch.

Fixes #90553.

Before:
![image](https://user-images.githubusercontent.com/783247/140385675-6ff41090-eca2-41bc-b161-99c5dabfec61.png)

After:
![image](https://user-images.githubusercontent.com/783247/140385748-20cf26b5-ea96-4e56-8af2-5fe1ab16fd3b.png)

r? `````@estebank`````
2021-11-20 10:21:12 +01:00
Vadim Petrochenkov
91e02177a1 rustc: Remove #[rustc_synthetic]
This function parameter attribute was introduced in https://github.com/rust-lang/rust/pull/44866 as an intermediate step in implementing `impl Trait`, it's not necessary or used anywhere by itself.
2021-11-18 14:32:29 +08:00
Mara Bos
483cff7ed3 Add SourceMap::indentation_before. 2021-11-16 19:52:58 +01:00
Nilstrieb
d64aea65ad Fix non-constant value ICE (#90878)
This also fixes the same suggestion, which was kind of broken, because it just searched for the last occurence of `const` to replace with a `let`. This works great in some cases, but when there is no const and a leading space to the file, it doesn't work and panic with overflow because it thought that it had found a const.

I also changed the suggestion to only trigger if the `const` and the non-constant value are on the same line, because if they aren't, the suggestion is very likely to be wrong.

Also don't trigger the suggestion if the found `const` is on line 0, because that triggers the ICE.
2021-11-15 20:40:29 +01:00
bors
60952bc3da Auto merge of #90485 - camsteffen:fmt-args-less-bind, r=m-ou-se
Don't destructure args tuple in format_args!

This allows Clippy to parse the HIR more simply since `arg0` is changed to `_args.0`. (cc rust-lang/rust-clippy#7843). From rustc's perspective, I think this is something between a lateral move and a tiny improvement since there are fewer bindings.

r? `@m-ou-se`
2021-11-09 05:33:16 +00:00
bors
46b8e7488e Auto merge of #90668 - matthiaskrgr:clippy_nov7, r=jyn514
more clippy fixes
2021-11-07 20:04:54 +00:00
Matthias Krüger
5c454551da more clippy fixes 2021-11-07 16:59:05 +01:00
bors
90a273b785 Auto merge of #90348 - Amanieu:asm_feature_gates, r=joshtriplett
Add features gates for experimental asm features

This PR splits off parts of `asm!` into separate features because they are not ready for stabilization.

Specifically this adds:
- `asm_const` for `const` operands.
- `asm_sym` for `sym` operands.
- `asm_experimental_arch` for architectures other than x86, x86_64, arm, aarch64 and riscv.

r? `@nagisa`
2021-11-07 04:59:42 +00:00
Amanieu d'Antras
eb32c00216 Add features gates for experimental asm features 2021-11-07 01:23:53 +00:00
Cameron Steffen
a9a24d5106 Don't destructure args tuple in format_args! 2021-11-06 14:28:08 -05:00
Tomasz Miąsko
b285e0c5d8 Remove MaybeMutBorrowedLocals 2021-11-03 16:43:12 +01:00
Guillaume Gomez
d50a4753b8 Split doc_cfg and doc_auto_cfg features 2021-11-02 16:55:50 +01:00
Guillaume Gomez
1a1f525bb0
Rollup merge of #90202 - matthewjasper:xcrate-hygiene, r=petrochenkov
Improve and test cross-crate hygiene

- Decode the parent expansion for traits and enums in `rustc_resolve`, this was already being used for resolution in typeck
- Avoid suggesting importing names with def-site hygiene, since it's often not useful
- Add more tests

r? `@petrochenkov`
2021-10-30 20:30:27 +02:00
Mark Rousskov
3215eeb99f
Revert "Add rustc lint, warning when iterating over hashmaps" 2021-10-28 11:01:42 -04:00
bors
a8f6e614f8 Auto merge of #89652 - rcvalle:rust-cfi, r=nagisa
Add LLVM CFI support to the Rust compiler

This PR adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments.

Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653).

LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e., -Clto).

Thank you, `@eddyb` and `@pcc,` for all the help!
2021-10-27 09:19:42 +00:00
Ramon de C Valle
5d30e93189 Add LLVM CFI support to the Rust compiler
This commit adds LLVM Control Flow Integrity (CFI) support to the Rust
compiler. It initially provides forward-edge control flow protection for
Rust-compiled code only by aggregating function pointers in groups
identified by their number of arguments.

Forward-edge control flow protection for C or C++ and Rust -compiled
code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code
share the same virtual address space) will be provided in later work as
part of this project by defining and using compatible type identifiers
(see Type metadata in the design document in the tracking issue #89653).

LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e.,
-Clto).
2021-10-25 16:23:01 -07:00
Matthias Krüger
87822b27ee
Rollup merge of #89558 - lcnr:query-stable-lint, r=estebank
Add rustc lint, warning when iterating over hashmaps

r? rust-lang/wg-incr-comp
2021-10-24 15:48:42 +02:00
bors
aa5740c715 Auto merge of #90104 - spastorino:coherence-for-negative-trait, r=nikomatsakis
Implement coherence checks for negative trait impls

The main purpose of this PR is to be able to [move Error trait to core](https://github.com/rust-lang/project-error-handling/issues/3).

This feature is necessary to handle the following from impl on box.

```rust
impl From<&str> for Box<dyn Error> { ... }
```

Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future, and thus prevents the `From` impl in `alloc` that would cause overlap with `From<E: Error> for Box<dyn Error>`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error`, making the `From` impl compile.

We would have this in `alloc`:

```rust
impl From<&str> for Box<dyn Error> {} // A
impl<E> From<E> for Box<dyn Error> where E: Error {} // B
```

and this in `core`:

```rust
trait Error {}
impl !Error for &str {}
```

r? `@nikomatsakis`

This PR was built on top of `@yaahc` PR #85764.

Language team proposal: to https://github.com/rust-lang/lang-team/issues/96
2021-10-23 12:51:15 +00:00
Matthias Krüger
736e8ebd1c
Rollup merge of #89730 - crlf0710:type_changing_feature, r=jackh726
add feature flag for `type_changing_struct_update`

This implements the PR0 part of the mentoring notes within #86618.

overrides the previous inactive #86646 pr.

r? ```@nikomatsakis```
2021-10-23 05:28:22 +02:00
Santiago Pastorino
da79fa964c
Add rustc_strict_coherence attribute and use it to check overlap 2021-10-22 15:49:46 -03:00
Charles Lew
7d7ebf8805 add feature flag for type_changing_struct_update 2021-10-22 11:46:55 -04:00
Matthew Jasper
1536d7220b Don't suggest importing items with hygienic names
This will potentially hide a few correct suggestions, but importing
these items from another module is not generally possible.
2021-10-21 23:36:51 +01:00
Yuki Okushi
f7024998c7
Rollup merge of #88860 - nbdd0121:panic, r=m-ou-se
Deduplicate panic_fmt

std's begin_panic_fmt and core's panic_fmt are duplicates. Merge them to declutter code and remove a lang item.
2021-10-20 04:35:14 +09:00
Gary Guo
9370156957 Deduplicate panic_fmt
std's begin_panic_fmt and core's panic_fmt are duplicates.
Merge them to declutter code and remove a lang item.
2021-10-19 15:02:21 +01:00
Matthias Krüger
8c8835d277
Rollup merge of #89956 - JohnTitor:suggest-case-insensitive-match-names, r=estebank
Suggest a case insensitive match name regardless of levenshtein distance

Fixes #86170

Currently, `find_best_match_for_name` only returns a case insensitive match name depending on a Levenshtein distance. It's a bit unfortunate that that hides some suggestions for typos like `Bar` -> `BAR`. That idea is from https://github.com/rust-lang/rust/pull/46347#discussion_r153701834, but I think it still makes some sense to show a candidate when we find a case insensitive match name as it's more like a typo.
Skipped the `candidate != lookup` check because the current (i.e, `levenshtein_match`) returns the exact same `Symbol` anyway but it doesn't seem to confuse anything on UI tests.

r? ``@estebank``
2021-10-19 05:40:53 +02:00
Vadim Petrochenkov
a6808335d4 rustc_span: Ident::invalid -> Ident::empty
The equivalent for `Symbol`s was renamed some time ago (`kw::Invalid` -> `kw::Empty`), and it makes sense to do the same thing for `Ident`s.
2021-10-17 23:20:30 +03:00
Yuki Okushi
d4cc8774d5
Suggest a case insensitive match name regardless of levenshtein distance 2021-10-17 04:51:22 +09:00
lcnr
00e5abe9b6 allow potential_query_instability everywhere 2021-10-15 10:58:18 +02:00
lcnr
80fe0bb76e add a rustc::query_stability lint 2021-10-15 10:58:18 +02:00
Cameron Steffen
f005e9fe96 Guess semicolon span for macro statements 2021-10-15 02:24:48 -05:00
bors
c34ac8747c Auto merge of #89247 - fee1-dead:const-eval-select, r=oli-obk
Add `const_eval_select` intrinsic

Adds an intrinsic that calls a given function when evaluated at compiler time, but generates a call to another function when called at runtime.

See https://github.com/rust-lang/const-eval/issues/7 for previous discussion.

r? `@oli-obk.`
2021-10-14 10:06:30 +00:00
Deadbeef
5387b6542f
Add const_eval_select intrinsic 2021-10-12 05:42:23 +00:00
Flying-Toast
59b186d99a
Add enum_intrinsics_non_enums lint 2021-10-11 09:46:27 +02:00
Devin Ragotzy
14338786fd Add feature gate to non_exhaustive_omitted_patterns lint
Actually add the feature to the lints ui test
Add tracking issue to the feature declaration
Rename feature gate to non_exhaustive_omitted_patterns_lint
Add more omitted_patterns lint feature gate
2021-10-08 17:40:39 -04:00
Jubilee
30e068f58b
Rollup merge of #89622 - m-ou-se:debug-assert-2021, r=estebank
Use correct edition for panic in [debug_]assert!().

See https://github.com/rust-lang/rust/issues/88638#issuecomment-915472783
2021-10-07 20:26:15 -07:00
Mara Bos
afe5335b97 Use correct edition for panic in [debug_]assert!() etc. 2021-10-07 14:27:08 +02:00
Wim Looman
18fdd816b7 Allow adding a set of cfg's to hide from being implicitly doc(cfg)'d
By adding #![doc(cfg_hide(foobar))] to the crate attributes the cfg
 #[cfg(foobar)] (and _only_ that _exact_ cfg) will not be implicitly
treated as a doc(cfg) to render a message in the documentation.
2021-10-05 18:04:15 +02:00
bors
e737694a4d Auto merge of #88175 - camsteffen:let-desugar-span, r=Manishearth
Add expansion to while desugar spans

In the same vein as #88163, this reverts a change in Clippy behavior as a result of #80357 (and reverts some `#[allow]`s): This changes `clippy::blocks_in_if_conditions` to not fire on `while` loops. Though we might actually want Clippy to lint those cases, we should introduce the change purposefully, with tests, and possibly under a different lint name.

The actual change here is to add a desugaring expansion to the spans when lowering a `while` loop.

r? `@Manishearth`
2021-10-03 21:44:10 +00:00
Cameron Steffen
eec856bfbc Make diangostic item names consistent 2021-10-02 19:38:19 -05:00
Cameron Steffen
67ea84d97a Add desugaring mark to while loop 2021-10-02 17:41:14 -05:00
Vadim Petrochenkov
d7d07657cd rustc_span: Make hygiene debug printing reproducible 2021-10-02 18:31:50 +03:00
Jubilee
8a454f8101
Rollup merge of #89072 - bjorn3:less_symbol_as_str, r=michaelwoerister
Avoid a couple of Symbol::as_str calls in cg_llvm

This should improve performance a tiny bit. Also remove `Symbol::len` and make `SymbolIndex` private.
2021-09-24 11:40:12 -07:00
bors
0132f8258a Auto merge of #87064 - Aaron1011:new-closure-track-caller, r=estebank
Support `#[track_caller]` on closures and generators

## Lang team summary

This PR adds support for placing the `#[track_caller]` attribute on closure and generator expressions. This attribute's addition behaves identically (from a users perspective) to the attribute being placed on the method in impl Fn/FnOnce/FnMut for ... generated by compiler.

The attribute is currently "double" feature gated -- both `stmt_expr_attributes` (preexisting) and `closure_track_caller` (newly added) must be enabled in order to place these attributes on closures.

As the Fn* traits lack a `#[track_caller]` attribute in their definition, caller information does not propagate when invoking closures through dyn Fn*. There is no limitation that this PR adds in supporting this; it can be added in the future.

# Implementation details

This is implemented in the same way as for functions - an extra
location argument is appended to the end of the ABI. For closures,
this argument is *not* part of the 'tupled' argument storing the
parameters - the final closure argument for `#[track_caller]` closures
is no longer a tuple.

For direct (monomorphized) calls, the necessary support was already
implemented - we just needeed to adjust some assertions around checking
the ABI and argument count to take closures into account.

For calls through a trait object, more work was needed.
When creating a `ReifyShim`, we need to create a shim
for the trait method (e.g. `FnOnce::call_mut`) - unlike normal
functions, closures are never invoked directly, and always go through a
trait method.

Additional handling was needed for `InstanceDef::ClosureOnceShim`. In
order to pass location information throgh a direct (monomorphized) call
to `FnOnce::call_once` on an `FnMut` closure, we need to make
`ClosureOnceShim` aware of `#[tracked_caller]`. A new field
`track_caller` is added to `ClosureOnceShim` - this is used by
`InstanceDef::requires_caller` location, allowing codegen to
pass through the extra location argument.

Since `ClosureOnceShim.track_caller` is only used by codegen,
we end up generating two identical MIR shims - one for
`track_caller == true`, and one for `track_caller == false`. However,
these two shims are used by the entire crate (i.e. it's two shims total,
not two shims per unique closure), so this shouldn't a big deal.
2021-09-23 12:26:51 +00:00
bors
67365d64bc Auto merge of #89139 - camsteffen:write-perf, r=Mark-Simulacrum
Use ZST for fmt unsafety

as suggested here - https://github.com/rust-lang/rust/pull/83302#issuecomment-923529151.
2021-09-23 02:10:26 +00:00
Aaron Hill
94b19fac26
Support #[track_caller] on closures and generators
This PR allows applying a `#[track_caller]` attribute to a
closure/generator expression. The attribute as interpreted as applying
to the compiler-generated implementation of the corresponding trait
method (`FnOnce::call_once`, `FnMut::call_mut`, `Fn::call`, or
`Generator::resume`).

This feature does not have its own feature gate - however, it requires
`#![feature(stmt_expr_attributes)]` in order to actually apply
an attribute to a closure or generator.

This is implemented in the same way as for functions - an extra
location argument is appended to the end of the ABI. For closures,
this argument is *not* part of the 'tupled' argument storing the
parameters - the final closure argument for `#[track_caller]` closures
is no longer a tuple.

For direct (monomorphized) calls, the necessary support was already
implemented - we just needeed to adjust some assertions around checking
the ABI and argument count to take closures into account.

For calls through a trait object, more work was needed.
When creating a `ReifyShim`, we need to create a shim
for the trait method (e.g. `FnOnce::call_mut`) - unlike normal
functions, closures are never invoked directly, and always go through a
trait method.

Additional handling was needed for `InstanceDef::ClosureOnceShim`. In
order to pass location information throgh a direct (monomorphized) call
to `FnOnce::call_once` on an `FnMut` closure, we need to make
`ClosureOnceShim` aware of `#[tracked_caller]`. A new field
`track_caller` is added to `ClosureOnceShim` - this is used by
`InstanceDef::requires_caller` location, allowing codegen to
pass through the extra location argument.

Since `ClosureOnceShim.track_caller` is only used by codegen,
we end up generating two identical MIR shims - one for
`track_caller == true`, and one for `track_caller == false`. However,
these two shims are used by the entire crate (i.e. it's two shims total,
not two shims per unique closure), so this shouldn't a big deal.
2021-09-22 15:19:33 -05:00
the8472
5948a7b407
Rollup merge of #89046 - oli-obk:fix_oflo, r=estebank
"Fix" an overflow in byte position math

r? `@estebank`

help! I fixed the ICE only to brick the diagnostic.

I mean, it was wrong previously (using an already expanded macro span), but it is really bad now XD
2021-09-22 19:03:22 +02:00
bjorn3
df727490b6 Make SymbolIndex private 2021-09-22 13:37:09 +02:00
bjorn3
9886c233d8 Remove Symbol::len
It is used exactly once and can be replaced with the equally fast
.as_str().len()
2021-09-22 13:37:09 +02:00
bors
ce45663e14 Auto merge of #88865 - guswynn:must_not_suspend, r=oli-obk
Implement `#[must_not_suspend]`

implements #83310

Some notes on the impl:

1. The code that searches for the attribute on the ADT is basically copied from the `must_use` lint. It's not shared, as the logic did diverge
2. The RFC does specify that the attribute can be placed on fn's (and fn-like objects), like `must_use`. I think this is a direct copy from the `must_use` reference definition. This implementation does NOT support this, as I felt that ADT's (+ `impl Trait` + `dyn Trait`) cover the usecase's people actually want on the RFC, and adding an imp for the fn call case would be significantly harder. The `must_use` impl can do a single check at fn call stmt time, but `must_not_suspend` would need to answer the question: "for some value X with type T, find any fn call that COULD have produced this value". That would require significant changes to `generator_interior.rs`, and I would need mentorship on that. `@eholk` and I are discussing it.
3. `@estebank` do you know a way I can make the user-provided `reason` note pop out? right now it seems quite hidden

Also, I am not sure if we should run perf on this

r? `@nikomatsakis`
2021-09-22 06:43:33 +00:00
Cameron Steffen
09b37d7433 Use ZST for fmt unsafety
This allows the format_args! macro to keep the pre-expansion code out of
the unsafe block without doing gymnastics with nested `match`
expressions. This reduces codegen.
2021-09-21 10:04:44 -05:00
Mark Rousskov
c746be2219 Migrate to 2021 2021-09-20 22:21:42 -04:00
Oli Scherer
c9fe093876 Avoid the overflow with rustc+debugassertions in issue-44406 2021-09-20 15:39:16 +00:00
Oli Scherer
4281380717 Add some more tracing 2021-09-20 15:24:47 +00:00
bors
5ecc8ad846 Auto merge of #89049 - Aaron1011:caching-sourcemap-assert, r=Mark-Simulacrum
Convert `debug_assert` to `assert` in `CachingSourceMapView`

I suspect that there's a bug somewhere in this code, which is
leading to the `predicates_of` ICE being seen in #89035
2021-09-19 18:54:31 +00:00
Yuki Okushi
e675073e73
Rollup merge of #88855 - calebzulawski:feature/simd_shuffle, r=nagisa
Allow simd_shuffle to accept vectors of any length

cc ``@rust-lang/project-portable-simd`` ``@workingjubilee``
2021-09-19 17:31:29 +09:00
bors
6c33a0a2ec Auto merge of #88978 - bjorn3:move_symbol_interner_lock, r=Mark-Simulacrum
Move the Lock into symbol::Interner

This makes it easier to make the symbol interner (near) lock free in case of concurrent accesses in the future.

With https://github.com/rust-lang/rust/pull/87867 landed this shouldn't affect performance anymore.
2021-09-18 03:30:13 +00:00
Aaron Hill
95bea1594c
Convert debug_assert to assert in CachingSourceMapView
I suspect that there's a bug somewhere in this code, which is
leading to the `predicates_of` ICE being seen in #89035
2021-09-17 12:01:29 -05:00
Guillaume Gomez
eb62779f2d
Rollup merge of #88954 - nbdd0121:panic3, r=oli-obk
Allow `panic!("{}", computed_str)` in const fn.

Special-case `panic!("{}", arg)` and translate it to `panic_display(&arg)`. `panic_display` will behave like `panic_any` in cosnt eval and behave like `panic!(format_args!("{}", arg))` in runtime.

This should bring Rust 2015 and 2021 to feature parity in terms of `const_panic`; and hopefully would unblock the stabilisation of #51999.

`@rustbot` modify labels: +T-compiler +T-libs +A-const-eval +A-const-fn

r? `@oli-obk`
2021-09-17 17:41:19 +02:00
bors
78a46efff0 Auto merge of #88832 - pcwalton:debug-unit-variant-fast-path, r=oli-obk
Introduce a fast path that avoids the `debug_tuple` abstraction when deriving Debug for unit-like enum variants.

The intent here is to allow LLVM to remove the switch entirely in favor of an
indexed load from a table of constant strings, which is likely what the
programmer would write in C. Unfortunately, LLVM currently doesn't perform this
optimization due to a bug, but there is [a
patch](https://reviews.llvm.org/D109565) that fixes this issue. I've verified
that, with that patch applied on top of this commit, Debug for unit-like tuple
variants becomes a load, reducing the O(n) code bloat to O(1).

Note that inlining `DebugTuple::finish()` wasn't enough to allow LLVM to
optimize the code properly; I had to avoid the abstraction entirely. Not using
the abstraction is likely better for compile time anyway.

Part of #88793.

r? `@oli-obk`
2021-09-17 01:00:11 +00:00
Manish Goregaokar
b66c9c3ac1
Rollup merge of #88875 - notriddle:notriddle/cleanup-unused-trait-selection, r=Mark-Simulacrum
cleanup(rustc_trait_selection): remove vestigial code from rustc_on_unimplemented

This isn't allowed by the validator, and seems to be unused.
When it was added in ed10a3faae,
it was used on `Sized`, and that usage is gone.
2021-09-16 10:57:19 -07:00
Manish Goregaokar
fb2d7dff80
Rollup merge of #88775 - pnkfelix:revert-anon-union-parsing, r=davidtwco
Revert anon union parsing

Revert PR #84571 and #85515, which implemented anonymous union parsing in a manner that broke the context-sensitivity for the `union` keyword and thus broke stable Rust code.

Fix #88583.
2021-09-15 14:56:58 -07:00
Gary Guo
11c0e58c74 Allow panic!("{}", computed_str) in const fn. 2021-09-15 21:56:43 +01:00
bjorn3
ccba8cb4bb Make two functions private 2021-09-15 18:46:53 +02:00
bjorn3
0ad8981945 Inline with_interner 2021-09-15 18:46:53 +02:00
bjorn3
05c09cb62d Move the Lock into symbol::Interner
This makes it easier to make the symbol interner (near) lock free in
case of concurrent accesses in the future.
2021-09-15 18:46:45 +02:00
bjorn3
8c7840e8cb Use a separate interner type for UniqueTypeId
Using symbol::Interner makes it very easy to mixup UniqueTypeId symbols
with the global interner. In fact the Debug implementation of
UniqueTypeId did exactly this.

Using a separate interner type also avoids prefilling the interner with
unused symbols and allow for optimizing the symbol interner for parallel
access without negatively affecting the single threaded module codegen.
2021-09-13 14:42:06 +02:00
Michael Howell
e1873ba007 cleanup(rustc_trait_selection): remove vestigial code from rustc_on_unimplemented
This isn't allowed by the validator, and seems to be unused.
When it was added in ed10a3faae,
it was used on `Sized`, and that usage is gone.
2021-09-11 16:42:42 -07:00
bors
547d9374d2 Auto merge of #84373 - cjgillot:resolve-span, r=michaelwoerister,petrochenkov
Encode spans relative to the enclosing item

The aim of this PR is to avoid recomputing queries when code is moved without modification.

MCP at https://github.com/rust-lang/compiler-team/issues/443

This is achieved by :
1. storing the HIR owner LocalDefId information inside the span;
2. encoding and decoding spans relative to the enclosing item in the incremental on-disk cache;
3. marking a dependency to the `source_span(LocalDefId)` query when we translate a span from the short (`Span`) representation to its explicit (`SpanData`) representation.

Since all client code uses `Span`, step 3 ensures that all manipulations
of span byte positions actually create the dependency edge between
the caller and the `source_span(LocalDefId)`.
This query return the actual absolute span of the parent item.
As a consequence, any source code motion that changes the absolute byte position of a node will either:
- modify the distance to the parent's beginning, so change the relative span's hash;
- dirty `source_span`, and trigger the incremental recomputation of all code that
  depends on the span's absolute byte position.

With this scheme, I believe the dependency tracking to be accurate.

For the moment, the spans are marked during lowering.
I'd rather do this during def-collection,
but the AST MutVisitor is not practical enough just yet.
The only difference is that we attach macro-expanded spans
to their expansion point instead of the macro itself.
2021-09-11 23:35:28 +00:00
Gus Wynn
2271376fb2 must_not_suspend impl 2021-09-11 10:45:17 -07:00
Caleb Zulawski
1b3fe755ea Allow simd_shuffle to accept vectors of any length 2021-09-11 14:55:14 +00:00
Matthias Krüger
c1e96085d3 don't clone types that are Copy (clippy::clone_on_copy) 2021-09-11 10:18:56 +02:00
Patrick Walton
79bc53870f Introduce a fast path that avoids the debug_tuple abstraction when deriving
Debug for unit-like enum variants.

The intent here is to allow LLVM to remove the switch entirely in favor of an
indexed load from a table of constant strings, which is likely what the
programmer would write in C. Unfortunately, LLVM currently doesn't perform this
optimization due to a bug, but there is [a
patch](https://reviews.llvm.org/D109565) that fixes this issue. I've verified
that, with that patch applied on top of this commit, Debug for unit-like tuple
variants becomes a load, reducing the O(n) code bloat to O(1).

Note that inlining `DebugTuple::finish()` wasn't enough to allow LLVM to
optimize the code properly; I had to avoid the abstraction entirely. Not using
the abstraction is likely better for compile time anyway.

Part of #88793.
2021-09-10 12:07:03 -07:00
Camille GILLOT
5e026eacb1 Remove some span tracking. 2021-09-10 20:19:07 +02:00
Camille GILLOT
940fa9251e Rename decode to data_untracked. 2021-09-10 20:18:22 +02:00
Camille GILLOT
b19ae20aad Track span dependency using a callback. 2021-09-10 20:18:18 +02:00
Camille GILLOT
e85ddeb474 Encode spans relative to their parent. 2021-09-10 20:18:11 +02:00
Camille GILLOT
00485e0c0e Keep a parent LocalDefId in SpanData. 2021-09-10 20:17:33 +02:00
Fabian Wolff
79adda930f Ignore automatically derived impls of Clone and Debug in dead code analysis 2021-09-09 19:49:07 +02:00
Felix S. Klock II
91feb76d13 Revert "Implement Anonymous{Struct, Union} in the AST"
This reverts commit 059b68dd67.

Note that this was manually adjusted to retain some of the refactoring
introduced by commit 059b68dd67, so that it could
likewise retain the correction introduced in commit
5b4bc05fa5
2021-09-09 09:14:17 -04:00
Mark Rousskov
b4e7649d6d Bump stage0 compiler to 1.56 2021-09-08 20:51:05 -04:00
bors
97f2698484 Auto merge of #88363 - michaelwoerister:remapped-diagnostics, r=estebank
Path remapping: Make behavior of diagnostics output dependent on presence of --remap-path-prefix.

This PR fixes a regression (#87745) with `--remap-path-prefix` where the flag stopped causing diagnostic messages to be remapped as well. The regression was introduced in https://github.com/rust-lang/rust/pull/83813 where we erroneously assumed that remapping of diagnostic messages was not desired anymore (because #70642 partially undid that functionality with nobody objecting).

The issue is fixed by making `--remap-path-prefix` remap diagnostic messages again, including for paths that have been remapped in upstream crates (e.g. the standard library). This means that "sysroot-localization" (implemented in #70642) is also disabled if `rustc` is invoked with `--remap-path-prefix`. The assumption is that once someone starts explicitly remapping paths they also don't want paths to their local Rust installation in their build output.

In the future we might want to give more fine-grained control over this behavior via compiler flags (see https://github.com/rust-lang/rfcs/pull/3127 for a related RFC). For now this PR is intended as a regression fix.

This PR is an alternative to https://github.com/rust-lang/rust/pull/88191, which makes diagnostic messages be remapped unconditionally. That approach, however, would effectively revert #70642.

Fixes https://github.com/rust-lang/rust/issues/87745.

cc `@cbeuw`
r? `@ghost`
2021-09-03 00:23:10 +00:00
Mara Bos
494c563f3b
Rollup merge of #88350 - programmerjake:add-ppc-cr-xer-clobbers, r=Amanieu
add support for clobbering xer, cr, and cr[0-7] for asm! on OpenPower/PowerPC

Fixes #88315
2021-09-01 09:23:26 +02:00
bors
c2a408840a Auto merge of #87688 - camsteffen:let-else, r=cjgillot
Introduce `let...else`

Tracking issue: #87335

The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..`, but I decided against this because, when a "mismatched type" error is found in typeck, there is no way to trace where in the HIR the expected type originated, AFAICT. In order to pass down this information, I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType`, but I left that as a future enhancement. For now, I simply assert that the block is `!` with a custom `ObligationCauseCode`, and I think this is clear enough, at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect.

Overall, I believe this PR is feature-complete with regard to the RFC.
2021-09-01 01:02:42 +00:00
Mara Bos
2a06daa863 Pull Span::find_ancestor_inside loop into its own function. 2021-08-31 16:25:51 +02:00
bors
1e37e83dc0 Auto merge of #88414 - Aaron1011:guess-foreign-head-span, r=estebank
Don't use `guess_head_span` in `predicates_of` for foreign span

Previously, the result of `predicates_of` for a foreign trait
would depend on the *current* state of the corresponding source
file in the foreign crate. This could lead to ICEs during incremental
compilation, since the on-disk contents of the upstream source file
could potentially change without the upstream crate being recompiled.

Additionally, this ensure that that the metadata we produce for a crate
only depends on its *compiled* upstream dependencies (e.g an rlib or
rmeta file), *not* the current on-disk state of the upstream crate
source files.
2021-08-31 03:34:22 +00:00
Cameron Steffen
960ea093ab Add let_else feature gate 2021-08-30 20:18:39 -05:00
Cameron Steffen
ae32e88909 Lower let-else to HIR 2021-08-30 20:17:46 -05:00
bors
56ea5e0ee9 Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization, r=m-ou-se
Make Edition 2021 Stable

An item of #87959.

This is an "on-demand" pull request, which means it will be merged when it is the right time to.
2021-08-31 01:03:55 +00:00
Mara Bos
6adbbb6be7 Update LATEST_STABLE_EDITION to 2021. 2021-08-30 15:33:09 +02:00
HTG-YT
388d90ac4c make edition 2021 stable 2021-08-30 15:27:00 +02:00
lcnr
87e781799a feature(const_param_types) -> feature(adt_const_params) 2021-08-30 12:07:36 +02:00
lcnr
0c28e028b6 feature(const_generics) -> feature(const_param_types) 2021-08-30 11:00:21 +02:00
Ellen
fcc2badf9b rename const_evaluatable_checked to generic_const_exprs
2021-08-30 11:00:21 +02:00
Aaron Hill
c9157efad6
Don't use guess_head_span in predicates_of for foreign span
Previously, the result of `predicates_of` for a foreign trait
would depend on the *current* state of the corresponding source
file in the foreign crate. This could lead to ICEs during incremental
compilation, since the on-disk contents of the upstream source file
could potentially change without the upstream crate being recompiled.

Additionally, this ensure that that the metadata we produce for a crate
only depends on its *compiled* upstream dependencies (e.g an rlib or
rmeta file), *not* the current on-disk state of the upstream crate
source files.
2021-08-27 23:19:49 -05:00
Michael Woerister
af1b65cb18 Path remapping: Make behavior of diagnostics output dependent on presence of --remap-path-prefix. 2021-08-27 11:50:44 +02:00
Jacob Lifshay
5802f60355 add support for clobbering xer, cr, and cr[0-7] for asm! on OpenPower/PowerPC
Fixes #88315
2021-08-25 22:08:27 -07:00
Léo Lanteri Thauvin
fde1b76b4b Use if-let guards in the codebase 2021-08-25 20:24:35 +02:00
Frank Steffahn
2f9ddf3bc7 Fix typos “an”→“a” and a few different ones that appeared in the same search 2021-08-22 18:15:49 +02:00
Guillaume Gomez
09d56a749c
Rollup merge of #88050 - Aaron1011:filename-hash-stable, r=michaelwoerister
Remove `HashStable` impls for `FileName` and `RealFileName`

These impls were unused, and incorrectly hashed the local
(non-remapped) path for `RealFileName::Remapped` (which would
break reproducible builds if these impls were used).
2021-08-19 19:30:07 +02:00
bors
0035d9dcec Auto merge of #87050 - jyn514:no-doc-primitive, r=manishearth
Add future-incompat lint for `doc(primitive)`

## What is `doc(primitive)`?

`doc(primitive)` is an attribute recognized by rustdoc which adds documentation for the built-in primitive types, such as `usize` and `()`. It has been stable since Rust 1.0.

## Why change anything?

`doc(primitive)` is useless for anyone outside the standard library. Since rustdoc provides no way to combine the documentation on two different primitive items, you can only replace the docs, and since the standard library already provides extensive documentation there is no reason to do so.

While fixing rustdoc's handling of primitive items (https://github.com/rust-lang/rust/pull/87073) I discovered that even rustdoc's existing handling of primitive items was broken if you had more than two crates using it (it would pick randomly between them). That meant both:
- Keeping rustdoc's existing treatment was nigh-impossible, because it was random.
- doc(primitive) was even more useless than it would otherwise be.

The only use-case for this outside the standard library is for no-std libraries which want to link to primitives (https://github.com/rust-lang/rust/issues/73423) which is being fixed in https://github.com/rust-lang/rust/pull/87073.

https://github.com/rust-lang/rust/pull/87073 makes various breaking changes to `doc(primitive)` (breaking in the sense that they change the semantics, not in that they cause code to fail to compile). It's not possible to avoid these and still fix rustdoc's issues.

## What can we do about it?

As shown by the crater run (https://github.com/rust-lang/rust/pull/87050#issuecomment-886166706), no one is actually using doc(primitive), there wasn't a single true regression in the whole run. We can either:
1. Feature gate it completely, breaking anyone who crater missed. They can easily fix the breakage just by removing the attribute.
2. add it to the `INVALID_DOC_ATTRIBUTES` future-incompat lint, and at the same time make it a no-op unless you add a feature gate. That would mean rustdoc has to look at the features of dependent crates, because it needs to know where primitives are defined in order to link to them.
3. add it to `INVALID_DOC_ATTRIBUTES`, but still use it to determine where primitives come from
4. do nothing; the behavior will silently change in https://github.com/rust-lang/rust/pull/87073.

My preference is for 2, but I would also be happy with 1 or 3. I don't think we should silently change the behavior.

This PR currently implements 3.
2021-08-16 15:36:44 +00:00
bors
92f3753b07 Auto merge of #84039 - jyn514:uplift-atomic-ordering, r=wesleywiser
Uplift the invalid_atomic_ordering lint from clippy to rustc

This is mostly just a rebase of https://github.com/rust-lang/rust/pull/79654; I've copy/pasted the text from that PR below.

r? `@lcnr` since you reviewed the last one, but feel free to reassign.

---

This is an implementation of https://github.com/rust-lang/compiler-team/issues/390.

As mentioned, in general this turns an unconditional runtime panic into a (compile time) lint failure. It has no false positives, and the only false negatives I'm aware of are if `Ordering` isn't specified directly and is comes from an argument/constant/whatever.

As a result of it having no false positives, and the alternative always being strictly wrong, it's on as deny by default. This seems right.

In the [zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Uplift.20the.20.60invalid_atomic_ordering.60.20lint.20from.20clippy/near/218483957) `@joshtriplett` suggested that lang team should FCP this before landing it. Perhaps libs team cares too?

---

Some notes on the code for reviewers / others below

## Changes from clippy

The code is changed from [the implementation in clippy](68cf94f6a6/clippy_lints/src/atomic_ordering.rs) in the following ways:

1. Uses `Symbols` and `rustc_diagnostic_item`s instead of string literals.
    - It's possible I should have just invoked Symbol::intern for some of these instead? Seems better to use symbol, but it did require adding several.
2. The functions are moved to static methods inside the lint struct, as a way to namespace them.
    - There's a lot of other code in that file — which I picked as the location for this lint because `@jyn514` told me that seemed reasonable.
3. Supports unstable AtomicU128/AtomicI128.
    - I did this because it was almost easier to support them than not — not supporting them would have (ideally) required finding a way not to give them a `rustc_diagnostic_item`, which would have complicated an already big macro.
    - These don't have tests since I wasn't sure if/how I should make tests conditional on whether or not the target has the atomic... This is to a certain extent an issue of 64bit atomics too, but 128-bit atomics are much less common. Regardless, the existing tests should be *more* than thorough enough here.
4. Minor changes like:
    - grammar tweaks ("loads cannot have `Release` **and** `AcqRel` ordering" => "loads cannot have `Release` **or** `AcqRel` ordering")
    - function renames (`match_ordering_def_path` => `matches_ordering_def_path`),
    - avoiding clippy-specific helper methods that don't exist in rustc_lint and didn't seem worth adding for this case (for example `cx.struct_span_lint` vs clippy's `span_lint_and_help` helper).

## Potential issues

(This is just about the code in this PR, not conceptual issues with the lint or anything)

1. I'm not sure if I should have used a diagnostic item for `Ordering` and its variants (I couldn't figure out how really, so if I should do this some pointers would be appreciated).
    - It seems possible that failing to do this might possibly mean there are more cases this lint would miss, but I don't really know how `match_def_path` works and if it has any pitfalls like that, so maybe not.

2. I *think* I deprecated the lint in clippy (CC `@flip1995` who asked to be notified about clippy changes in the future in [this comment](https://github.com/rust-lang/rust/pull/75671#issuecomment-718731659)) but I'm not sure if I need to do anything else there.
    - I'm kind of hoping CI will catch if I missed anything, since `x.py test src/tools/clippy` fails with a lot of errors with and without my changes (and is probably a nonsense command regardless). Running `cargo test` from src/tools/clippy also fails with unrelated errors that seem like refactorings that didnt update clippy? So, honestly no clue.

3. I wasn't sure if the description/example I gave good. Hopefully it is. The example is less thorough than the one from clippy here: https://rust-lang.github.io/rust-clippy/master/index.html#invalid_atomic_ordering. Let me know if/how I should change it if it needs changing.

4. It pulls in the `if_chain` crate. This crate was already used in clippy, and seems like it's used elsewhere in rustc, but I'm willing to rewrite it to not use this if needed (I'd prefer not to, all things being equal).
2021-08-16 06:36:13 +00:00
Joshua Nelson
03df65497e feature gate doc(primitive) 2021-08-16 05:41:16 +00:00
Thom Chiovoloni
402a9c9f5e Uplift the invalid_atomic_ordering lint from clippy to rustc
- Deprecate clippy::invalid_atomic_ordering
- Use rustc_diagnostic_item for the orderings in the invalid_atomic_ordering lint
- Reduce code duplication
- Give up on making enum variants diagnostic items and just look for
`Ordering` instead

  I ran into tons of trouble with this because apparently the change to
  store HIR attrs in a side table also gave the DefIds of the
  constructor instead of the variant itself. So I had to change
  `matches_ordering` to also check the grandparent of the defid as well.

- Rename `atomic_ordering_x` symbols to just the name of the variant
- Fix typos in checks - there were a few places that said "may not be
  Release" in the diagnostic but actually checked for SeqCst in the lint.
- Make constant items const
- Use fewer diagnostic items
- Only look at arguments after making sure the method matches

  This prevents an ICE when there aren't enough arguments.

- Ignore trait methods
- Only check Ctors instead of going through `qpath_res`

  The functions take values, so this couldn't ever be anything else.

- Add if_chain to allowed dependencies
- Fix grammar
- Remove unnecessary allow
2021-08-16 03:55:27 +00:00
Aaron Hill
d8c3a649a6
Remove HashStable impls for FileName and RealFileName
These impls were unused, and incorrectly hashed the local
(non-remapped) path for `RealFileName::Remapped` (which would
break reproducible builds if these impls were used).
2021-08-15 10:48:53 -05:00
bors
85109e257a Auto merge of #87581 - Amanieu:asm_clobber_abi, r=nagisa
Add support for clobber_abi to asm!

This PR adds the `clobber_abi` feature that was proposed in #81092.

Fixes #81092

cc `@rust-lang/wg-inline-asm`

r? `@nagisa`
2021-08-14 22:29:27 +00:00
Gary Guo
1fb1643129 Implement black_box using intrinsic
The new implementation allows some `memcpy`s to be optimized away,
so the uninit value in ui/sanitize/memory.rs is constructed directly
onto the return place. Therefore the sanitizer now says that the
value is allocated by `main` rather than `random`.
2021-08-12 16:16:57 +01:00
Amanieu d'Antras
3fd463a5ca Add support for clobber_abi to asm! 2021-08-12 12:43:11 +01:00
bors
e91405b9d5 Auto merge of #87262 - dtolnay:negative, r=Aaron1011
Support negative numbers in Literal::from_str

proc_macro::Literal has allowed negative numbers in a single literal token ever since Rust 1.29, using https://doc.rust-lang.org/stable/proc_macro/struct.Literal.html#method.isize_unsuffixed and similar constructors.

```rust
let lit = proc_macro::Literal::isize_unsuffixed(-10);
```

However, the suite of constructors on Literal is not sufficient for all use cases, for example arbitrary precision floats, or custom suffixes in FFI macros.

```rust
let lit = proc_macro::Literal::f64_unsuffixed(0.101001000100001000001000000100000001); // :(
let lit = proc_macro::Literal::i???_suffixed(10ulong); // :(
```

For those, macros construct the literal using from_str instead, which preserves arbitrary precision, custom suffixes, base, and digit grouping.

```rust
let lit = "0.101001000100001000001000000100000001".parse::<Literal>().unwrap();
let lit = "10ulong".parse::<Literal>().unwrap();
let lit = "0b1000_0100_0010_0001".parse::<Literal>().unwrap();
```

However, until this PR it was not possible to construct a literal token that is **both** negative **and** preserving of arbitrary precision etc.

This PR fixes `Literal::from_str` to recognize negative integer and float literals.
2021-08-03 04:50:28 +00:00
Cameron Steffen
14f3418f79
Rollup merge of #86176 - nbdd0121:explicit-generic-args, r=jackh726
Implement a `explicit_generic_args_with_impl_trait` feature gate

Implements #83701

When this gate is enabled, explicit generic arguments can be specified even if `impl Trait` is used in argument position. Generic arguments can only be specified for explicit generic parameters but not for the synthetic type parameters from  `impl Trait`

So code like this will be accepted:
```rust
#![feature(explicit_generic_args_with_impl_trait)]

fn foo<T: ?Sized>(_f: impl AsRef<T>) {}
fn main() {
    foo::<str>("".to_string());
}
```
2021-08-02 09:36:49 -05:00
bors
b53a93db2d Auto merge of #87535 - lf-:authors, r=Mark-Simulacrum
rfc3052 followup: Remove authors field from Cargo manifests

Since RFC 3052 soft deprecated the authors field, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information for contributors, we may as well
remove it from crates in this repo.
2021-08-02 05:49:17 +00:00
Gary Guo
9b90e7e980 Implement a explicit_generic_args_with_impl_trait feature gate
When this gate is enabled, explicit generic arguments can be specified even
if `impl Trait` is used in argument position. Generic arguments can only be
specified for explicit generic parameters but not for the synthetic type
parameters from  `impl Trait`
2021-08-02 04:17:01 +01:00
Alexander Regueiro
2dc86a6450 Added feature gate. 2021-07-31 00:51:38 +08:00
Jade
3cf820e17d rfc3052: Remove authors field from Cargo manifests
Since RFC 3052 soft deprecated the authors field anyway, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information, we should remove it from
crates in this repo.
2021-07-29 14:56:05 -07:00
Jonas Schievink
dbd126901a Add feature gates for for and ? in consts 2021-07-29 23:21:54 +02:00
Mara Bos
b64c4f9560 Add new const_format_args!() macro and use it in panics. 2021-07-28 16:12:25 +02:00
Mara Bos
f827d3e285 Make const panic!("..") work in Rust 2021.
During const eval, this replaces calls to core::panicking::panic_fmt and
std::panicking::being_panic_fmt with a call to a new const fn:
core::panicking::const_panic_fmt. That function uses
fmt::Arguments::as_str() to get the str and calls panic_str with that
instead.

panic!() invocations with formatting arguments are still not accepted,
as the creation of such a fmt::Arguments cannot be done in constant
functions right now.
2021-07-28 16:10:41 +02:00
Jacob Pratt
c70147fd66
Permit deriving default on enums with #[default] 2021-07-27 15:47:47 -04:00
kadmin
8759f00c73 Actually infer args in visitors 2021-07-26 21:15:18 +00:00
Charles Lew
ab171c5279 Add internal attribute and tests. 2021-07-20 22:14:43 +08:00
bors
d5af63480f Auto merge of #87225 - estebank:cleanup, r=oli-obk
Various diagnostics clean ups/tweaks

* Always point at macros, including derive macros
* Point at non-local items that introduce a trait requirement
* On private associated item, point at definition
2021-07-19 18:44:27 +00:00
Esteban Küber
ba052bd8de Various diagnostics clean ups/tweaks
* Always point at macros, including derive macros
* Point at non-local items that introduce a trait requirement
* On private associated item, point at definition
2021-07-19 08:43:35 -07:00
David Tolnay
55ff45a5c2
Support negative numbers in Literal::from_str 2021-07-18 14:08:34 -07:00
Yuki Okushi
07faa2e32c
Rollup merge of #87170 - xFrednet:clippy-5393-add-diagnostic-items, r=Manishearth,oli-obk
Add diagnostic items for Clippy

This adds a bunch of diagnostic items to `std`/`core`/`alloc` functions, structs and traits used in Clippy. The actual refactorings in Clippy to use these items will be done in a different PR in Clippy after the next sync.

This PR doesn't include all paths Clippy uses, I've only gone through the first 85 lines of Clippy's [`paths.rs`](ecf85f4bdc/clippy_utils/src/paths.rs) (after rust-lang/rust-clippy#7466) to get some feedback early on. I've also decided against adding diagnostic items to methods, as it would be nicer and more scalable to access them in a nicer fashion, like adding a `is_diagnostic_assoc_item(did, sym::Iterator, sym::map)` function or something similar (Suggested by `@camsteffen` [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/Diagnostic.20Item.20Naming.20Convention.3F/near/225024603))

There seems to be some different naming conventions when it comes to diagnostic items, some use UpperCamelCase (`BinaryHeap`) and some snake_case (`hashmap_type`). This PR uses UpperCamelCase for structs and traits and snake_case with the module name as a prefix for functions. Any feedback on is this welcome.

cc: rust-lang/rust-clippy#5393

r? `@Manishearth`
2021-07-18 14:21:57 +09:00
Camille GILLOT
b35ceeeec7 Simplify Expn creation. 2021-07-17 19:41:14 +02:00
Camille GILLOT
dddaa6d068 Rename expn_info -> expn_data. 2021-07-17 19:41:13 +02:00
Camille GILLOT
0f8573e57b Pass ExpnData by reference. 2021-07-17 19:41:12 +02:00
Camille GILLOT
41c1f39fa8 Drop ExpnData::krate. 2021-07-17 19:41:10 +02:00
Camille GILLOT
dbd2d77641 Drop orig_id. 2021-07-17 19:41:09 +02:00
Camille GILLOT
37a13def48 Encode ExpnId using ExpnHash for incr. comp. 2021-07-17 19:41:08 +02:00
Camille GILLOT
2fe37c5bd1 Choose encoding format in caller code. 2021-07-17 19:41:07 +02:00
Camille GILLOT
078dd37f88 Use LocalExpnId where possible. 2021-07-17 19:41:02 +02:00
Camille GILLOT
6e78d6c9d6 Make the CrateNum part of the ExpnId. 2021-07-17 19:35:33 +02:00
xFrednet
67002db2cf Corrected symbol order after adding diagnostic items 2021-07-17 12:20:43 +02:00
xFrednet
d38f2b0cc1 Added diagnostic items to structs and traits for Clippy 2021-07-15 23:57:02 +02:00
xFrednet
1a900042ab Added diagnostic items to functions for Clippy 2021-07-15 23:47:03 +02:00
Camille GILLOT
c2d43e1329 Simplify metadata decoding. 2021-07-15 19:31:47 +02:00
Camille GILLOT
47ea2ae933 Separate encoding paths.
The two paths will be modified independently in the next few commits.
2021-07-15 19:31:46 +02:00
bors
2155386f31 Auto merge of #87106 - Mark-Simulacrum:edition-no-clone, r=petrochenkov
Avoid cloning ExpnData to access Span edition

ExpnData is a fairly hefty structure to clone; cloning it may not be cheap. In
some cases this may get optimized out, but it's not clear that will always be
the case. Try to avoid that cost.

r? `@ghost` -- opening for a perf run to start with
2021-07-14 01:41:12 +00:00
bors
c7d6bcc788 Auto merge of #87044 - cjgillot:expnhash, r=petrochenkov
Cache expansion hash globally

... instead of computing it multiple times.

Split from #86676
r? `@petrochenkov`
2021-07-13 22:32:58 +00:00
Camille GILLOT
616ce3c5c0 Cache expansion hash. 2021-07-13 23:10:56 +02:00
Camille GILLOT
cff0ea5f88 Move HashStable implementations. 2021-07-13 23:10:55 +02:00
Mark Rousskov
7d373c9c11 Avoid cloning ExpnData to access Span edition
ExpnData is a fairly hefty structure to clone; cloning it may not be cheap. In
some cases this may get optimized out, but it's not clear that will always be
the case. Try to avoid that cost.
2021-07-13 10:57:10 -04:00
bors
ca99e3eb3a Auto merge of #86922 - joshtriplett:target-abi, r=oli-obk
target abi

Implement cfg(target_abi) (RFC 2992)

Add an `abi` field to `TargetOptions`, defaulting to "". Support using
`cfg(target_abi = "...")` for conditional compilation on that field.

Gated by `feature(cfg_target_abi)`.

Add a test for `target_abi`, and a test for the feature gate.

Add `target_abi` to tidy as a platform-specific cfg.

Update targets to use `target_abi`

All eabi targets have `target_abi = "eabi".`
All eabihf targets have `target_abi = "eabihf"`.
`armv6_unknown_freebsd` and `armv7_unknown_freebsd` have `target_abi = "eabihf"`.
All abi64 targets have `target_abi = "abi64"`.
All ilp32 targets have `target_abi = "ilp32"`.
All softfloat targets have `target_abi = "softfloat"`.
All *-uwp-windows-* targets have `target_abi = "uwp"`.
All spe targets have `target_abi = "spe"`.
All macabi targets have `target_abi = "macabi"`.
aarch64-apple-ios-sim has `target_abi = "sim"`.
`x86_64-fortanix-unknown-sgx` has `target_abi = "fortanix"`.
`x86_64-unknown-linux-gnux32` has `target_abi = "x32"`.

Add FIXME entries for targets for which existing values need to change
once `cfg_target_abi` becomes stable. (All of them are tier 3 targets.)

Add a test for `target_abi` in `--print cfg`.
2021-07-13 12:25:10 +00:00
bors
394804bb23 Auto merge of #86857 - fee1-dead:add-attr, r=oli-obk
Add #[default_method_body_is_const]

`@rustbot` label F-const_trait_impl
2021-07-13 06:59:34 +00:00
bors
4581c4ef6f Auto merge of #87042 - petrochenkov:cleanquotspan, r=Aaron1011
Cleanup span quoting

I finally got to reviewing https://github.com/rust-lang/rust/pull/84278.
See the individual commit messages.
r? `@Aaron1011`
2021-07-11 08:46:43 +00:00
bors
99f8efec46 Auto merge of #86416 - Amanieu:asm_clobber_only, r=nagisa
Add clobber-only register classes for asm!

These are needed to properly express a function call ABI using a clobber
list, even though we don't support passing actual values into/out of
these registers.
2021-07-11 01:06:58 +00:00
Vadim Petrochenkov
4ba91a063d rustc_span: Reorder some ExpnData fields in accordance with comments
A drive-by change.
2021-07-11 00:40:25 +03:00
Vadim Petrochenkov
28f4dba438 rustc_span: Revert addition of proc_macro field to ExpnKind::Macro
The flag has a vague meaning and is used for a single diagnostic change that is low benefit and appears only under `-Z macro_backtrace`.
2021-07-10 23:03:35 +03:00
Amanieu d'Antras
e1c3f5e017 Add clobber-only register classes for asm!
These are needed to properly express a function call ABI using a clobber
list, even though we don't support passing actual values into/out of
these registers.
2021-07-10 17:29:00 +02:00
Deadbeef
2db927d8d8
Add #[default_method_body_is_const] 2021-07-10 20:54:44 +08:00
Mara Bos
ad10107600
Rollup merge of #86881 - tmiasko:lookup-line, r=nagisa
Inline implementation of lookup_line

to avoid unnecessary conversions from `Option<usize>` to `isize` and back.
2021-07-09 16:20:32 +02:00
bors
ee86f96ba1 Auto merge of #85828 - scottmcm:raw-eq, r=oli-obk
Stop generating `alloca`s & `memcmp` for simple short array equality

Example:
```rust
pub fn demo(x: [u16; 6], y: [u16; 6]) -> bool { x == y }
```

Before:
```llvm
define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0, i96 %1) unnamed_addr #0 {
start:
  %y = alloca [6 x i16], align 8
  %x = alloca [6 x i16], align 8
  %.0..sroa_cast = bitcast [6 x i16]* %x to i96*
  store i96 %0, i96* %.0..sroa_cast, align 8
  %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96*
  store i96 %1, i96* %.0..sroa_cast3, align 8
  %_11.i.i.i = bitcast [6 x i16]* %x to i8*
  %_14.i.i.i = bitcast [6 x i16]* %y to i8*
  %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i, i8* nonnull dereferenceable(12) %_14.i.i.i, i64 12) #2, !alias.scope !2
  %2 = icmp eq i32 %bcmp.i.i.i, 0
  ret i1 %2
}
```
```x86
playground::demo: # `@playground::demo`
	sub	rsp, 32
	mov	qword ptr [rsp], rdi
	mov	dword ptr [rsp + 8], esi
	mov	qword ptr [rsp + 16], rdx
	mov	dword ptr [rsp + 24], ecx
	xor	rdi, rdx
	xor	esi, ecx
	or	rsi, rdi
	sete	al
	add	rsp, 32
	ret
```

After:
```llvm
define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0, i96 %1) unnamed_addr #0 {
start:
  %2 = icmp eq i96 %0, %1
  ret i1 %2
}
```
```x86
_ZN4mini4demo17h7a8994aaa314c981E:
	xor	rcx, r8
	xor	edx, r9d
	or	rdx, rcx
	sete	al
	ret
```
2021-07-09 09:16:27 +00:00
bors
95fb131521 Auto merge of #86904 - m-ou-se:prelude-collision-check-trait, r=nikomatsakis
Check FromIterator trait impl in prelude collision check.

Fixes #86902.
2021-07-09 06:35:42 +00:00
Scott McMurray
2456495a26 Stop generating allocas+memcmp for simple array equality 2021-07-08 14:55:54 -07:00
Tomasz Miąsko
1719d45013 Inline implementation of lookup_line
to simplify the implementation and avoid unnecessary
conversions from `Option<usize>` to `isize` and back.
2021-07-08 23:30:53 +02:00
Guillaume Gomez
d12b16887b
Rollup merge of #86726 - sexxi-goose:use-diagnostic-item-for-rfc2229-migration, r=nikomatsakis
Use diagnostic items instead of lang items for rfc2229 migrations

This PR removes the `Send`, `UnwindSafe` and `RefUnwindSafe` lang items introduced in https://github.com/rust-lang/rust/pull/84730, and uses diagnostic items instead to check for `Send`, `UnwindSafe` and `RefUnwindSafe` traits for RFC2229 migrations.

r? ```@nikomatsakis```
2021-07-08 18:30:33 +02:00
Guillaume Gomez
a2654fb64c Rework SESSION_GLOBALS API to prevent overwriting it 2021-07-08 16:16:28 +02:00
Josh Triplett
84d6e8aed3 Implement cfg(target_abi) (RFC 2992)
Add an `abi` field to `TargetOptions`, defaulting to "". Support using
`cfg(target_abi = "...")` for conditional compilation on that field.

Gated by `feature(cfg_target_abi)`.

Add a test for `target_abi`, and a test for the feature gate.

Add `target_abi` to tidy as a platform-specific cfg.

This does not add an abi to any existing target.
2021-07-07 08:52:35 -07:00
Mara Bos
60535441c8 Check FromIterator trait impl in prelude collision check. 2021-07-07 13:26:38 +00:00
bors
d04ec47358 Auto merge of #86143 - bjorn3:revert_revert_merge_crate_disambiguator, r=michaelwoerister
Reland "Merge CrateDisambiguator into StableCrateId"

Reverts https://github.com/rust-lang/rust/pull/85891 as this revert of #85804 made perf even worse.

r? `@Mark-Simulacrum`
2021-07-06 11:31:59 +00:00
bjorn3
489ad8b8b5 Revert "Revert "Merge CrateDisambiguator into StableCrateId""
This reverts commit 8176ab8bc1.
2021-07-06 11:28:04 +02:00
Camille GILLOT
3162c37b59 Store macro parent module in ExpnData. 2021-07-06 08:07:06 +02:00
bors
96859dbaf6 Auto merge of #86778 - tmiasko:fast-multiline, r=davidtwco
Avoid byte to char position conversions in `is_multiline`

Converting a byte position into a char position is currently linear in
the number of multibyte characters in the source code. Avoid it when
checking if a range spans across lines.

This makes it feasible to compile source files with a large number of
multibyte characters.
2021-07-03 16:06:35 +00:00
Tomasz Miąsko
7a410763fa Avoid byte to char position conversions in is_multiline
Converting a byte position into a char position is currently linear in
the number of multibyte characters in the source code. Avoid it when
checking if a range spans across lines.

This makes it feasible to compile source files with a large number of
multibyte characters.
2021-07-01 13:30:00 +02:00
Roxane Fruytier
3e569dd2df Remove lang items Send, UnwindSafe and RefUnwindSafe 2021-06-29 17:47:57 -04:00
Josh Triplett
ab0f63ecdf rustc_span: Explicitly handle crates that differ from package names
The sha-1 and md-5 packages contain crates named sha1 and md5,
respectively. This discrepancy makes it somewhat more challenging to
automate detection of unused crates. Explicitly rename the packages to
the names of the crates they contain, to simplify such detection.
2021-06-24 23:48:53 -07:00
bors
8cb207ae69 Auto merge of #86386 - inquisitivecrystal:better-errors-for-display-traits-v3, r=estebank
Better errors for Debug and Display traits

Currently, if someone tries to pass value that does not implement `Debug` or `Display` to a formatting macro, they get a very verbose and confusing error message. This PR changes the error messages for missing `Debug` and `Display` impls to be less overwhelming in this case, as suggested by #85844. I was a little less aggressive in changing the error message than that issue proposed. Still, this implementation would be enough to reduce the number of messages to be much more manageable.

After this PR, information on the cause of an error involving a `Debug` or `Display` implementation would suppressed if the requirement originated within a standard library macro. My reasoning was that errors originating from within a macro are confusing when they mention details that the programmer can't see, and this is particularly problematic for `Debug` and `Display`, which are most often used via macros. It is possible that either a broader or a narrower criterion would be better. I'm quite open to any feedback.

Fixes #85844.
2021-06-23 03:16:04 +00:00
bors
80926fc409 Auto merge of #86368 - michaelwoerister:lexing-ice, r=davidtwco
Disambiguate between SourceFiles from different crates even if they have the same path

This PR fixes an ICE that can occur when the compiler encounters a source file that is part of both the local crate and an upstream crate:

1. While importing source files from an upstream crate the compiler creates a `SourceFile` entry for `foo.rs` in the `SourceMap`. Since this is an imported source file its `src` field is `None`.
2. At a later point the parser encounters `foo.rs` again. It tells the `SourceMap` to load the file but because we already have an entry for `foo.rs` the `SourceMap` will return the existing version with `src == None`.
3. The parser proceeds under the assumption that `src.is_some()` and panics when actually trying to use the file's contents.

This PR fixes the issue by adding the source file's associated `CrateNum` to the `SourceMap`'s interning key. As a consequence the two instances of the file will each have a separate entry in the `SourceMap`. They just happen to share the same file path. This approach seemed less problematic to me than trying to mutate the `SourceFile` after it had already been created.

Another, more involved, approach might be to merge the `src` and the `external_src` field.

Fixes #85955
2021-06-22 14:53:58 +00:00
bors
44f4a87d70 Auto merge of #85707 - jam1garner:future_prelude_collision_lint, r=nikomatsakis
Add `future_prelude_collision` lint

Implements #84594. (RFC rust-lang/rfcs#3114 ([rendered](https://github.com/rust-lang/rfcs/blob/master/text/3114-prelude-2021.md))) Not entirely complete but wanted to have my progress decently available while I finish off the last little bits.

Things left to implement:

* [x] UI tests for lints
* [x] Only emit lint for 2015 and 2018 editions
* [ ] Lint name/message bikeshedding
* [x] Implement for `FromIterator` (from best I can tell, the current approach as mentioned from [this comment](https://github.com/rust-lang/rust/issues/84594#issuecomment-847288288) won't work due to `FromIterator` instances not using dot-call syntax, but if I'm correct about this then that would also need to be fixed for `TryFrom`/`TryInto`)*
* [x] Add to `rust-2021-migration` group? (See #85512) (added to `rust-2021-compatibility` group)
* [ ] Link to edition guide in lint docs

*edit: looked into it, `lookup_method` will also not be hit for `TryFrom`/`TryInto` for non-dotcall syntax. If anyone who is more familiar with typecheck knows the equivalent for looking up associated functions, feel free to chime in.
2021-06-22 07:01:54 +00:00
bors
4573a4a879 Auto merge of #86383 - shamatar:slice_len_lowering, r=bjorn3
Add MIR pass to lower call to `core::slice::len` into `Len` operand

During some larger experiment with range analysis I've found that code like `let l = slice.len()` produces different MIR then one found in bound checks. This optimization pass replaces terminators that are calls to `core::slice::len` with just a MIR operand and Goto terminator.

It uses some heuristics to remove the outer borrow that is made to call `core::slice::len`, but I assume it can be eliminated, just didn't find how.

Would like to express my gratitude to `@oli-obk` who helped me a lot on Zullip
2021-06-21 22:24:13 +00:00
Michael Woerister
c3c4ab5ed2 Encode SourceFile source crate as StableCrateId in incr. comp. OnDiskCache. 2021-06-21 15:30:16 +02:00
Michael Woerister
47327145e3 Disambiguate between SourceFiles from different crates even if they have the same path. 2021-06-21 13:38:46 +02:00
Alex Vlasov
aa53928ed7 Squashed implementation of the pass 2021-06-20 16:09:42 +02:00
Yuki Okushi
34f38bf760
Make s pre-interned 2021-06-17 09:45:19 +09:00
Aris Merchant
f1f1c9b25b Improve errors for missing Debug and Display impls 2021-06-16 01:13:28 -07:00
Yuki Okushi
5936ecc24f
Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics, r=m-ou-se
Stabilize `ops::ControlFlow` (just the type)

Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR).

With the new `?` desugar implemented, [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6).  (At the time of making this PR, godbolt was still on the 2021-05-01 nightly, where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).)  That resolves the only blocker I know of, so I'd like to propose that `ControlFlow` be considered for stabilization.

Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058, where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)).  Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594), and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589, https://github.com/jonhoo/rust-imap/issues/194).

As this will need an FCP, picking a libs member manually:
r? `@m-ou-se`

## Stabilized APIs

```rust
#[derive(Debug, Clone, Copy, PartialEq)]
pub enum ControlFlow<B, C = ()> {
    /// Exit the operation without running subsequent phases.
    Break(B),
    /// Move on to the next phase of the operation as normal.
    Continue(C),
}
```

As well as using `?` on a `ControlFlow<B, _>` in a function returning `ControlFlow<B, _>`.  (Note, in particular, that there's no `From::from`-conversion on the `Break` value, the way there is for `Err`s.)

## Existing APIs *not* stabilized here

All the associated methods and constants: `break_value`, `is_continue`, `map_break`, [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE), etc.

Some of the existing methods in nightly seem reasonable, some seem like they should be removed, and some need more discussion to decide.  But none of them are *essential*, so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow), they're all omitted from this PR.

They can be considered separately later, as further usage demonstrates which are important.
2021-06-15 17:40:08 +09:00
jam1garner
1626e1938a Add support for associated functions to future_prelude_collision lint 2021-06-14 13:27:24 -04:00
jam1garner
79388aa067 Add future_prelude_collision lint 2021-06-14 13:27:23 -04:00
bors
0f6ba39fd8 Auto merge of #86180 - cjgillot:defmv, r=petrochenkov
Hash DefId in rustc_span.

This is mostly just moving code around. Changes are simplifications of unneeded callbacks from rustc_span to rustc_middle.

r? `@petrochenkov`
2021-06-12 06:09:20 +00:00
Yuki Okushi
79c0559ce1
Rollup merge of #86153 - tmiasko:dummy-span, r=estebank
Print dummy spans as `no-location`

Fixes #58808.
2021-06-12 01:15:59 +09:00
Camille GILLOT
72e9589149 Make DummyHashStableContext dummier. 2021-06-11 16:54:34 +02:00
Camille GILLOT
d1931b6406 Sprinkle inline. 2021-06-11 16:48:24 +02:00
Camille GILLOT
a7a50b0c0a Hash DefId in rustc_span. 2021-06-11 12:25:02 +02:00
Ryan Levick
6936349233 Add support for using qualified paths with structs in expression and pattern
position.
2021-06-10 13:18:41 +02:00
Tomasz Miąsko
fab319be73 Print dummy spans as no-location 2021-06-09 00:33:46 +02:00
bors
e4a6032706 Auto merge of #85903 - bjorn3:rustc_serialize_cleanup, r=varkor
Remove unused functions and arguments from rustc_serialize
2021-06-07 14:40:26 +00:00
bjorn3
8176ab8bc1 Revert "Merge CrateDisambiguator into StableCrateId"
This reverts commit d0ec85d3fb.
2021-06-07 10:37:45 +02:00
bors
f434217aab Auto merge of #79608 - alessandrod:bpf, r=nagisa
BPF target support

This adds `bpfel-unknown-none` and `bpfeb-unknown-none`, two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target, where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker.

I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.
2021-06-06 01:02:32 +00:00
Yuki Okushi
36f1ed6de2
Rollup merge of #85850 - bjorn3:less_feature_gates, r=jyn514
Remove unused feature gates

The first commit removes a usage of a feature gate, but I don't expect it to be controversial as the feature gate was only used to workaround a limitation of rust in the past. (closures never being `Clone`)

The second commit uses `#[allow_internal_unstable]` to avoid leaking the `trusted_step` feature gate usage from inside the index newtype macro. It didn't work for the `min_specialization` feature gate though.

The third commit removes (almost) all feature gates from the compiler that weren't used anyway.
2021-06-04 13:42:54 +09:00
Tomasz Miąsko
c1f6495b8e Miscellaneous inlining improvements 2021-06-02 08:49:58 +02:00
bors
625d5a693e Auto merge of #85829 - bjorn3:simplify_crate_num, r=jackh726
Remove CrateNum::ReservedForIncrCompCache

It's only use is easily replaceable with `Option<CrateNum>`.
2021-06-01 20:09:03 +00:00
bjorn3
a2c4affe86 Remove unused functions and arguments from rustc_serialize 2021-06-01 19:29:11 +02:00
bjorn3
312f964478 Remove unused feature gates 2021-05-31 13:55:43 +02:00
bjorn3
9de82d7611 Use allow_internal_unstable more in rustc_index 2021-05-31 12:13:47 +02:00
bjorn3
1ef98856c7 Remove CrateNum::ReservedForIncrCompCache 2021-05-30 14:33:16 +02:00
bjorn3
d0ec85d3fb Merge CrateDisambiguator into StableCrateId 2021-05-30 12:51:34 +02:00
Jacob Pratt
bc2f0fb5a9
Specialize implementations
Implementations in stdlib are now optimized as they were before.
2021-05-26 18:07:09 -04:00
Scott McMurray
65a0a8b386 Stabilize ops::ControlFlow (just the type) 2021-05-23 13:20:05 -07:00
Alessandro Decina
b2a6967114 Add support for BPF inline assembly 2021-05-23 18:03:27 +10:00
Ralf Jung
1207b7fa0b
Rollup merge of #85439 - mgacek8:add_diagnostic_item_to_CStr_type, r=davidtwco
Add diagnostic item to `CStr`

Required for clippy issue: https://github.com/rust-lang/rust-clippy/issues/7145
2021-05-20 00:19:07 +02:00
bors
4e3e6db011 Auto merge of #84767 - scottmcm:try_trait_actual, r=lcnr
Implement the new desugaring from `try_trait_v2`

~~Currently blocked on https://github.com/rust-lang/rust/issues/84782, which has a PR in https://github.com/rust-lang/rust/pull/84811~~ Rebased atop that fix.

`try_trait_v2` tracking issue: https://github.com/rust-lang/rust/issues/84277

Unfortunately this is already touching a ton of things, so if you have suggestions for good ways to split it up, I'd be happy to hear them.  (The combination between the use in the library, the compiler changes, the corresponding diagnostic differences, even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits.

r? `@ghost`

~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.
2021-05-18 20:50:01 +00:00
Mateusz Gacek
d730cc6646 Add diagnostic item to CStr 2021-05-18 15:45:30 +02:00
bors
9964284fed Auto merge of #84571 - jedel1043:issue-49804-impl, r=petrochenkov
Parse unnamed fields of struct and union type

Added the `unnamed_fields` feature gate.

This is a prototype of [RFC 2102](https://github.com/rust-lang/rust/issues/49804), so any suggestions are greatly appreciated.

r? `@petrochenkov`
2021-05-17 12:15:26 +00:00
jedel1043
059b68dd67 Implement Anonymous{Struct, Union} in the AST
Add unnamed_fields feature gate and gate unnamed fields on parsing
2021-05-16 09:49:16 -05:00
Jonas Schievink
bd16825767 Allow async {} expressions in const contexts 2021-05-16 02:06:40 +02:00
Dhruv Jauhar
a7e1cec621 add new attribute rustc_insignificant_dtor and a query to check if a type has a significant drop 2021-05-14 22:57:33 -04:00
bors
6d395a1c29 Auto merge of #85186 - nikomatsakis:issue-83538-polluted-cache, r=jackh726
have on_completion record subcycles

have on_completion record subcycles

Rework `on_completion` method so that it removes all
provisional cache entries that are "below" a completed
node (while leaving those entries that are not below
the node).

This corrects an imprecise result that could in turn lead
to an incremental compilation failure. Under the old
scheme, if you had:

* A depends on...
   * B depends on A
   * C depends on...
       * D depends on C
 * T: 'static

then the provisional results for A, B, C, and D would all
be entangled. Thus, if A was `EvaluatedToOkModuloRegions`
(because of that final condition), then the result for C and
D would also be demoted to "ok modulo regions".

In reality, though, the result for C depends only on C and itself,
and is not dependent on regions. If we happen to evaluate the
cycle starting from C, we would never reach A, and hence the
result would be "ok".

Under the new scheme, the provisional results for C and D
are moved to the permanent cache immediately and are not affected
by the result of A.

Fixes #83538

r? `@Aaron1011`
2021-05-13 19:36:46 +00:00
bors
d2df620789 Auto merge of #85110 - RalfJung:no-rustc_args_required_const, r=oli-obk
Remove rustc_args_required_const attribute

Now that stdarch no longer needs it (thanks `@Amanieu!),` we can kill the `rustc_args_required_const` attribute. This means that lifetime extension of references to temporaries is the only remaining job that promotion is performing. :-)

r? `@oli-obk`
Fixes https://github.com/rust-lang/rust/issues/69493
2021-05-13 13:37:32 +00:00
Niko Matsakis
c7cb72828d introduce a unit testing feature rustc_evaluate_where_clauses
This attribute will cause us to invoke evaluate on every where clause of an
invoked function and to generate an error with the result.

Without this, it is very difficult to observe the effects of invoking the trait
evaluator.
2021-05-13 04:49:20 -04:00
bors
72d07257ed Auto merge of #84732 - DrChat:asm_powerpc, r=Amanieu
Add asm!() support for PowerPC

This includes GPRs and FPRs only.
Note that this does not include PowerPC64.

For my reference, this was mostly duplicated from PR #73214.
2021-05-13 05:40:55 +00:00
Ralf Jung
44a8e8d745 entirely remove rustc_args_required_const attribute 2021-05-12 16:15:27 +02:00
bors
28e2b29b89 Auto merge of #84730 - sexxi-goose:rox-auto-trait, r=nikomatsakis
Add auto traits and clone trait migrations for RFC2229

This PR
- renames the existent RFC2229 migration `disjoint_capture_drop_reorder` to `disjoint_capture_migration`
- add additional migrations for auto traits and clone trait

Closes rust-lang/project-rfc-2229#29
Closes rust-lang/project-rfc-2229#28

r? `@nikomatsakis`
2021-05-12 13:33:32 +00:00
bors
e1ff91f439 Auto merge of #83813 - cbeuw:remap-std, r=michaelwoerister
Fix `--remap-path-prefix` not correctly remapping `rust-src` component paths and unify handling of path mapping with virtualized paths

This PR fixes #73167 ("Binaries end up containing path to the rust-src component despite `--remap-path-prefix`") by preventing real local filesystem paths from reaching compilation output if the path is supposed to be remapped.

`RealFileName::Named` introduced in #72767 is now renamed as `LocalPath`, because this variant wraps a (most likely) valid local filesystem path.

`RealFileName::Devirtualized` is renamed as `Remapped` to be used for remapped path from a real path via `--remap-path-prefix` argument, as well as real path inferred from a virtualized (during compiler bootstrapping) `/rustc/...` path. The `local_path` field is now an `Option<PathBuf>`, as it will be set to `None` before serialisation, so it never reaches any build output. Attempting to serialise a non-`None` `local_path` will cause an assertion faliure.

When a path is remapped, a `RealFileName::Remapped` variant is created. The original path is preserved in `local_path` field and the remapped path is saved in `virtual_name` field. Previously, the `local_path` is directly modified which goes against its purpose of "suitable for reading from the file system on the local host".

`rustc_span::SourceFile`'s fields `unmapped_path` (introduced by #44940) and `name_was_remapped` (introduced by #41508 when `--remap-path-prefix` feature originally added) are removed, as these two pieces of information can be inferred from the `name` field: if it's anything other than a `FileName::Real(_)`, or if it is a `FileName::Real(RealFileName::LocalPath(_))`, then clearly `name_was_remapped` would've been false and `unmapped_path` would've been `None`. If it is a `FileName::Real(RealFileName::Remapped{local_path, virtual_name})`, then `name_was_remapped` would've been true and `unmapped_path` would've been `Some(local_path)`.

cc `@eddyb` who implemented `/rustc/...` path devirtualisation
2021-05-12 11:05:56 +00:00
Aaron Hill
f916b0474a
Implement span quoting for proc-macros
This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:

```
error[E0412]: cannot find type `MissingType` in this scope
  --> $DIR/auxiliary/span-from-proc-macro.rs:37:20
   |
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
   | ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL |             field: MissingType
   |                    ^^^^^^^^^^^ not found in this scope
   |
  ::: $DIR/span-from-proc-macro.rs:8:1
   |
LL | #[error_from_attribute]
   | ----------------------- in this macro invocation
```

Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`

This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.

This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
  macro to get run. This saves all of the sapns in the input to `quote!`
  into the metadata of *the proc-macro-crate* (which we are currently
  compiling). The `quote!` macro then expands to a call to
  `proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
  and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.

The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.

This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`

Custom quoting currently has a few limitations:

In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.

Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.
2021-05-12 00:51:31 -04:00
Dr. Chat
b1bb5d662c Add initial asm!() support for PowerPC
This includes GPRs and FPRs only
2021-05-11 19:04:16 -05:00
Andy Wang
37dbe868c9
Split span_to_string into span_to_diagnostic/embeddable_string 2021-05-11 00:04:12 +01:00
Dylan DPC
b5092627c7
Rollup merge of #85044 - ChrisDenton:file-exists, r=jackh726
Use `path.exists()` instead of `fs::metadata(path).is_ok()`

It's more explicit and potentially allows platforms to optimize the existence check.
2021-05-08 01:06:26 +02:00
Dylan DPC
44bee536fe
Rollup merge of #84887 - jyn514:index-span, r=Xanewok
Remove SpanInterner::get

- It's used exactly once, so it's trivial to replace
- It doesn't match the normal convention for containers: normally
`get()` returns an option and indexing panics. Instead `SpanInterner::get()` panics
  and there's no indexing operation available.
2021-05-08 01:06:23 +02:00
Chris Denton
d9a58f4c87
Use path.exists() instead of fs::metadata(path).is_ok()
It's more explicit and allows platforms to optimize the existence check.
2021-05-07 17:32:40 +01:00
Scott McMurray
ca92b5a23a Actually implement the feature in the compiler
Including all the bootstrapping tweaks in the library.
2021-05-06 11:37:45 -07:00
Roxane
9afea614bf Add additional migrations to handle auto-traits and clone traits
Combine all 2229 migrations under one flag name
2021-05-06 14:17:59 -04:00
Luqman Aden
db555e1284 Implement RFC 2951: Native link modifiers
This commit implements both the native linking modifiers infrastructure
as well as an initial attempt at the individual modifiers from the RFC.
It also introduces a feature flag for the general syntax along with
individual feature flags for each modifier.
2021-05-05 16:04:25 -07:00
Andy Wang
5417b45c26
Use local and remapped paths where appropriate 2021-05-05 15:31:28 +01:00
Andy Wang
fb4f6439f6
Revamp RealFileName public methods 2021-05-05 15:31:03 +01:00
Andy Wang
f8e55da6de
Remove impl Display for FileName and add FileNameDisplay wrapper type 2021-05-05 15:31:02 +01:00
Andy Wang
9e0426d784
Make local_path in RealFileName::Remapped Option to be removed in exported metadata 2021-05-05 15:10:57 +01:00
Andy Wang
6720a37042
Rename RealFileName::Named to LocalPath and Devirtualized to Remapped 2021-05-05 15:10:50 +01:00
Joshua Nelson
b73ad09dfd Remove SpanInterner::get
- It's used exactly once, so it's trivial to replace
- It doesn't match the normal convention for containers: normally
`get()` returns and option and indexing panics. Instead `get()` panicked
  and there's no indexing operation available.
2021-05-03 17:32:06 -04:00
Mark Rousskov
5065144d6d Use new thread-local const-init
Let's see if this gives us any speedup - some of the TLS state modified in this
commit *is* pretty heavily accessed, so we can hope!
2021-05-02 14:06:07 -04:00
bors
bcd696d722 Auto merge of #84401 - crlf0710:impl_main_by_path, r=petrochenkov
Implement RFC 1260 with feature_name `imported_main`.

This is the second extraction part of #84062 plus additional adjustments.
This (mostly) implements RFC 1260.

However there's still one test case failure in the extern crate case. Maybe `LocalDefId` doesn't work here? I'm not sure.

cc https://github.com/rust-lang/rust/issues/28937
r? `@petrochenkov`
2021-04-30 06:59:37 +00:00
Charles Lew
d261df4a72 Implement RFC 1260 with feature_name imported_main. 2021-04-29 08:35:08 +08:00
bors
ca075d268d Auto merge of #83386 - mark-i-m:stabilize-pat2015, r=nikomatsakis
Stabilize `:pat_param` and remove `:pat2021`

Blocked on #83384

cc `@rust-lang/lang` #79278

If I understand `@nikomatsakis` in  https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/or.20patterns/near/231133873, another FCP is not needed.

r? `@nikomatsakis`
2021-04-28 20:35:17 +00:00
mark
2a9db919ff remove pat2021 2021-04-27 21:15:59 -05:00
Rich Kadel
888d0b4c96 Derived Eq no longer shows uncovered
The Eq trait has a special hidden function. MIR `InstrumentCoverage`
would add this function to the coverage map, but it is never called, so
the `Eq` trait would always appear uncovered.

Fixes: #83601

The fix required creating a new function attribute `no_coverage` to mark
functions that should be ignored by `InstrumentCoverage` and the
coverage `mapgen` (during codegen).

While testing, I also noticed two other issues:

* spanview debug file output ICEd on a function with no body. The
workaround for this is included in this PR.
* `assert_*!()` macro coverage can appear covered if followed by another
`assert_*!()` macro. Normally they appear uncovered. I submitted a new
Issue #84561, and added a coverage test to demonstrate this issue.
2021-04-27 11:11:56 -07:00
bors
13a2615883 Auto merge of #84147 - cuviper:array-method-dispatch, r=nikomatsakis,m-ou-se
Cautiously add IntoIterator for arrays by value

Add the attribute described in #84133, `#[rustc_skip_array_during_method_dispatch]`, which effectively hides a trait from method dispatch when the receiver type is an array.

Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally, but `array.into_iter()` has edition-dependent behavior, returning `slice::Iter` for 2015 and 2018 editions, or `array::IntoIter` for 2021 and later.

r? `@nikomatsakis`
cc `@LukasKalbertodt` `@rust-lang/libs`
2021-04-25 07:26:49 +00:00
bors
b56b175c6c Auto merge of #84310 - RalfJung:const-fn-feature-flags, r=oli-obk
further split up const_fn feature flag

This continues the work on splitting up `const_fn` into separate feature flags:
* `const_fn_trait_bound` for `const fn` with trait bounds
* `const_fn_unsize` for unsizing coercions in `const fn` (looks like only `dyn` unsizing is still guarded here)

I don't know if there are even any things left that `const_fn` guards... at least libcore and liballoc do not need it any more.

`@oli-obk` are you currently able to do reviews?
2021-04-24 23:16:03 +00:00
Yuki Okushi
e109aa3613
Rollup merge of #83519 - oli-obk:assign_shrink_your_normal_code, r=pnkfelix
Implement a lint that highlights all moves larger than a configured limit

Tracking issue: #83518
[MCP 420](https://github.com/rust-lang/compiler-team/issues/420) still ~blazing~ in progress

r? ```@pnkfelix```

The main open issue I see with this minimal impl of the feature is that the lint is immediately "stable" (so it can be named on stable), even if it is never executed on stable. I don't think we have the concept of unstable lint names or hiding lint names without an active feature gate, so that would be a bigger change.
2021-04-25 01:53:09 +09:00
bors
481ba16439 Auto merge of #84339 - alexcrichton:llvm-fptoint-sat, r=nagisa
rustc: Use LLVM's new saturating float-to-int intrinsics

This commit updates rustc, with an applicable LLVM version, to use
LLVM's new `llvm.fpto{u,s}i.sat.*.*` intrinsics to implement saturating
floating-point-to-int conversions. This results in a little bit tighter
codegen for x86/x86_64, but the main purpose of this is to prepare for
upcoming changes to the WebAssembly backend in LLVM where wasm's
saturating float-to-int instructions will now be implemented with these
intrinsics.

This change allows simplifying a good deal of surrounding code, namely
removing a lot of wasm-specific behavior. WebAssembly no longer has any
special-casing of saturating arithmetic instructions and the need for
`fptoint_may_trap` is gone and all handling code for that is now
removed. This means that the only wasm-specific logic is in the
`fpto{s,u}i` instructions which only get used for "out of bounds is
undefined behavior". This does mean that for the WebAssembly target
specifically the Rust compiler will no longer be 100% compatible with
pre-LLVM 12 versions, but it seems like that's unlikely to be relied on
by too many folks.

Note that this change does immediately regress the codegen of saturating
float-to-int casts on WebAssembly due to the specialization of the LLVM
intrinsic not being present in our LLVM fork just yet. I'll be following
up with an LLVM update to pull in those patches, but affects a few other
SIMD things in flight for WebAssembly so I wanted to separate this change.

Eventually the entire `cast_float_to_int` function can be removed when
LLVM 12 is the minimum version, but that will require sinking the
complexity of it into other backends such as Cranelfit.
2021-04-23 18:35:49 +00:00
Alex Crichton
de2a4601ab rustc: Use LLVM's new saturating float-to-int intrinsics
This commit updates rustc, with an applicable LLVM version, to use
LLVM's new `llvm.fpto{u,s}i.sat.*.*` intrinsics to implement saturating
floating-point-to-int conversions. This results in a little bit tighter
codegen for x86/x86_64, but the main purpose of this is to prepare for
upcoming changes to the WebAssembly backend in LLVM where wasm's
saturating float-to-int instructions will now be implemented with these
intrinsics.

This change allows simplifying a good deal of surrounding code, namely
removing a lot of wasm-specific behavior. WebAssembly no longer has any
special-casing of saturating arithmetic instructions and the need for
`fptoint_may_trap` is gone and all handling code for that is now
removed. This means that the only wasm-specific logic is in the
`fpto{s,u}i` instructions which only get used for "out of bounds is
undefined behavior". This does mean that for the WebAssembly target
specifically the Rust compiler will no longer be 100% compatible with
pre-LLVM 12 versions, but it seems like that's unlikely to be relied on
by too many folks.

Note that this change does immediately regress the codegen of saturating
float-to-int casts on WebAssembly due to the specialization of the LLVM
intrinsic not being present in our LLVM fork just yet. I'll be following
up with an LLVM update to pull in those patches, but affects a few other
SIMD things in flight for WebAssembly so I wanted to separate this change.

Eventually the entire `cast_float_to_int` function can be removed when
LLVM 12 is the minimum version, but that will require sinking the
complexity of it into other backends such as Cranelfit.
2021-04-21 07:15:53 -07:00
Oli Scherer
a2f2179026 Add an attribute to be able to configure the limit 2021-04-20 09:30:28 -04:00
klensy
f43ee8ebf6 fix few typos 2021-04-19 15:57:08 +03:00
Ralf Jung
bd9556956a fix feature use in rustc libs 2021-04-18 22:05:45 +02:00
Ralf Jung
fbfaab2cb7 separate feature flag for unsizing casts in const fn 2021-04-18 19:11:29 +02:00
Ralf Jung
fdad6ab3a3 move 'trait bounds on const fn' to separate feature gate 2021-04-18 18:36:41 +02:00
Josh Stone
b79af2fcde Implement #[rustc_skip_array_during_method_dispatch] 2021-04-16 11:11:59 -07:00
bors
d4bc912c48 Auto merge of #84217 - crlf0710:remove_main_attr_pure, r=petrochenkov
Remove #[main] attribute.

This removes the #[main] attribute support from the compiler according to the decisions within #29634. For existing use cases within test harness generation, replaced it with a newly-introduced internal attribute `#[rustc_main]`.

This is first part extracted from #84062 .

Closes #29634.

r? `@petrochenkov`
2021-04-16 08:01:45 +00:00
Charles Lew
fc357039f9 Remove #[main] attribute. 2021-04-16 13:04:02 +08:00
bors
7af1f55ae3 Auto merge of #84205 - workingjubilee:more-simd-intrin, r=bjorn3
Add simd_{round,trunc} intrinsics

LLVM supports many functions from math.h in its IR. Many of these
have SIMD instructions on various platforms. So, let's add round and
trunc so std::arch can use them.

Yes, exact comparison is intentional: rounding must always return a
valid integer-equal value, except for inf/NAN.
2021-04-15 21:00:11 +00:00
mark
0566ccc72f rename pat2015 to pat_param 2021-04-15 13:52:09 -05:00
Jubilee Young
003b8eadd7 Add more SIMD math.h intrinsics
LLVM supports many functions from math.h in its IR. Many of these have
single-instruction variants on various platforms. So, let's add them so
std::arch can use them.

Yes, exact comparison is intentional: rounding must always return a
valid integer-equal value, except for inf/NAN.
2021-04-14 15:25:06 -07:00
bors
7537b20626 Auto merge of #83948 - ABouttefeux:lint-nullprt-deref, r=RalfJung
add lint deref_nullptr detecting when a null ptr is dereferenced

fixes #83856
changelog: add lint that detect code like
```rust
unsafe {
      &*core::ptr::null::<i32>()
 };
unsafe {
     addr_of!(std::ptr::null::<i32>())
};
let x: i32 = unsafe {*core::ptr::null()};
let x: i32 = unsafe {*core::ptr::null_mut()};
unsafe {*(0 as *const i32)};
unsafe {*(core::ptr::null() as *const i32)};
```
```
warning: Dereferencing a null pointer causes undefined behavior
 --> src\main.rs:5:26
  |
5 |     let x: i32 = unsafe {*core::ptr::null()};
  |                          ^^^^^^^^^^^^^^^^^^
  |                          |
  |                          a null pointer is dereferenced
  |                          this code causes undefined behavior when executed
  |
  = note: `#[warn(deref_nullptr)]` on by default
```

Limitation:
It does not detect code like
```rust
const ZERO: usize = 0;
unsafe {*(ZERO as *const i32)};
```
or code where `0` is not directly a literal
2021-04-14 18:04:22 +00:00
Alex Crichton
482a3d06c3 rustc: Add a new wasm ABI
This commit implements the idea of a new ABI for the WebAssembly target,
one called `"wasm"`. This ABI is entirely of my own invention
and has no current precedent, but I think that the addition of this ABI
might help solve a number of issues with the WebAssembly targets.

When `wasm32-unknown-unknown` was first added to Rust I naively
"implemented an abi" for the target. I then went to write `wasm-bindgen`
which accidentally relied on details of this ABI. Turns out the ABI
definition didn't match C, which is causing issues for C/Rust interop.
Currently the compiler has a "wasm32 bindgen compat" ABI which is the
original implementation I added, and it's purely there for, well,
`wasm-bindgen`.

Another issue with the WebAssembly target is that it's not clear to me
when and if the default C ABI will change to account for WebAssembly's
multi-value feature (a feature that allows functions to return multiple
values). Even if this does happen, though, it seems like the C ABI will
be guided based on the performance of WebAssembly code and will likely
not match even what the current wasm-bindgen-compat ABI is today. This
leaves a hole in Rust's expressivity in binding WebAssembly where given
a particular import type, Rust may not be able to import that signature
with an updated C ABI for multi-value.

To fix these issues I had the idea of a new ABI for WebAssembly, one
called `wasm`. The definition of this ABI is "what you write
maps straight to wasm". The goal here is that whatever you write down in
the parameter list or in the return values goes straight into the
function's signature in the WebAssembly file. This special ABI is for
intentionally matching the ABI of an imported function from the
environment or exporting a function with the right signature.

With the addition of a new ABI, this enables rustc to:

* Eventually remove the "wasm-bindgen compat hack". Once this
  ABI is stable wasm-bindgen can switch to using it everywhere.
  Afterwards the wasm32-unknown-unknown target can have its default ABI
  updated to match C.

* Expose the ability to precisely match an ABI signature for a
  WebAssembly function, regardless of what the C ABI that clang chooses
  turns out to be.

* Continue to evolve the definition of the default C ABI to match what
  clang does on all targets, since the purpose of that ABI will be
  explicitly matching C rather than generating particular function
  imports/exports.

Naturally this is implemented as an unstable feature initially, but it
would be nice for this to get stabilized (if it works) in the near-ish
future to remove the wasm32-unknown-unknown incompatibility with the C
ABI. Doing this, however, requires the feature to be on stable because
wasm-bindgen works with stable Rust.
2021-04-08 08:03:18 -07:00
Simonas Kazlauskas
54dc7cebce Remove the insta-stable cfg(wasm)
The addition of `cfg(wasm)` was an oversight on my end that has a number
of downsides:

* It was introduced as an insta-stable addition, forgoing the usual
  staging mechanism we use for potentially far-reaching changes;
* It is a breaking change for people who are using `--cfg wasm` either
  directly or via cargo for other purposes;
* It is not entirely clear if a bare `wasm` cfg is a right option or
  whether `wasm` family of targets are special enough to warrant
  special-casing these targets specifically.

As for the last point, there appears to be a fair amount of support for
reducing the boilerplate in specifying architectures from the same
family, while ignoring their pointer width. The suggested way forward
would be to propose such a change as a separate RFC as it is potentially
a quite contentious addition.
2021-04-07 23:09:56 +03:00
Aliénore Bouttefeux
389100921a add lint deref_nullptr 2021-04-06 22:01:00 +02:00
bors
a6e7a5aa5d Auto merge of #81234 - repnop:fn-alignment, r=lcnr
Allow specifying alignment for functions

Fixes #75072

This allows the user to specify alignment for functions, which can be useful for low level work where functions need to necessarily be aligned to a specific value.

I believe the error cases not covered in the match are caught earlier based on my testing so I had them just return `None`.
2021-04-06 04:35:26 +00:00
Wesley Norris
448d07683a Allow specifying alignment for functions 2021-04-05 17:36:51 -04:00
Dylan DPC
0d12422f2d
Rollup merge of #80525 - devsnek:wasm64, r=nagisa
wasm64 support

There is still some upstream llvm work needed before this can land.
2021-04-05 00:24:23 +02:00
Gus Caplan
da66a31572
wasm64 2021-04-04 11:29:34 -05:00
bors
5662d9343f Auto merge of #80965 - camelid:rename-doc-spotlight, r=jyn514
Rename `#[doc(spotlight)]` to `#[doc(notable_trait)]`

Fixes #80936.

"spotlight" is not a very specific or self-explaining name.
Additionally, the dialog that it triggers is called "Notable traits".
So, "notable trait" is a better name.

* Rename `#[doc(spotlight)]` to `#[doc(notable_trait)]`
* Rename `#![feature(doc_spotlight)]` to `#![feature(doc_notable_trait)]`
* Update documentation
* Improve documentation

r? `@Manishearth`
2021-04-02 07:04:58 +00:00
Joshua Nelson
441dc3640a Remove (lots of) dead code
Found with https://github.com/est31/warnalyzer.

Dubious changes:
- Is anyone else using rustc_apfloat? I feel weird completely deleting
  x87 support.
- Maybe some of the dead code in rustc_data_structures, in case someone
  wants to use it in the future?
- Don't change rustc_serialize

  I plan to scrap most of the json module in the near future (see
  https://github.com/rust-lang/compiler-team/issues/418) and fixing the
  tests needed more work than I expected.

TODO: check if any of the comments on the deleted code should be kept.
2021-03-27 22:16:33 -04:00
Josh Stone
72ebebe474 Use iter::zip in compiler/ 2021-03-26 09:32:31 -07:00
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
Camelid
34c6cee397 Rename #[doc(spotlight)] to #[doc(notable_trait)]
"spotlight" is not a very specific or self-explaining name.
Additionally, the dialog that it triggers is called "Notable traits".
So, "notable trait" is a better name.

* Rename `#[doc(spotlight)]` to `#[doc(notable_trait)]`
* Rename `#![feature(doc_spotlight)]` to `#![feature(doc_notable_trait)]`
* Update documentation
* Improve documentation
2021-03-15 13:59:54 -07: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
Jonas Schievink
285ea2f80d
Rollup merge of #82107 - petrochenkov:minexpclean, r=Aaron1011
expand: Some cleanup

See individual commits for details.

r? ``@Aaron1011``
2021-02-15 16:07:04 +01: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
Andrea Nall
5ef202520f add diagnostic items
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-15 02:27:28 +00:00
Mara Bos
a428ab17ab Improve suggestion for panic!(format!(..)). 2021-02-14 18:52:47 +01:00
Vadim Petrochenkov
0038eaee6b rustc_span: Remove obsolete allow_internal_unstable_backcompat_hack 2021-02-14 19:42:55 +03:00
Dylan DPC
c8dacf95ae
Rollup merge of #82029 - tmiasko:debug, r=matthewjasper
Use debug log level for developer oriented logs

The information logged here is of limited general interest, while at the
same times makes it impractical to simply enable logging and share the
resulting logs due to the amount of the output produced.

Reduce log level from info to debug for developer oriented information.

For example, when building cargo, this reduces the amount of logs
generated by `RUSTC_LOG=info cargo build` from 265 MB to 79 MB.

Continuation of changes from 81350.
2021-02-14 16:54:52 +01:00
Dylan DPC
29ed864dc3
Rollup merge of #80523 - LeSeulArtichaut:inline-sym, r=jyn514
#[doc(inline)] sym_generated

Manually doc-inlines `rustc_span::sym_generated` into `sym`.
Previously the docs would not get inlined, causing the symbols to be undocumented as `sym_generated` is private.

r? `@jyn514`
2021-02-14 16:54:35 +01:00
Tomasz Miąsko
361dcd5ca7 Use debug log level for developer oriented logs
The information logged here is of limited general interest, while at the
same times makes it impractical to simply enable logging and share the
resulting logs due to the amount of the output produced.

Reduce log level from info to debug for developer oriented information.

For example, when building cargo, this reduces the amount of logs
generated by `RUSTC_LOG=info cargo build` from 265 MB to 79 MB.

Continuation of changes from 81350.
2021-02-13 00:00:00 +00:00
Dylan DPC
58d72aedee
Rollup merge of #81506 - vo4:hwasan, r=nagisa
HWAddressSanitizer support

#  Motivation
Compared to regular ASan, HWASan has a [smaller overhead](https://source.android.com/devices/tech/debug/hwasan). The difference in practice is that HWASan'ed code is more usable, e.g. Android device compiled with HWASan can be used as a daily driver.

# Example
```
fn main() {
    let xs = vec![0, 1, 2, 3];
    let _y = unsafe { *xs.as_ptr().offset(4) };
}
```
```
==223==ERROR: HWAddressSanitizer: tag-mismatch on address 0xefdeffff0050 at pc 0xaaaad00b3468
READ of size 4 at 0xefdeffff0050 tags: e5/00 (ptr/mem) in thread T0
    #0 0xaaaad00b3464  (/root/main+0x53464)
    #1 0xaaaad00b39b4  (/root/main+0x539b4)
    #2 0xaaaad00b3dd0  (/root/main+0x53dd0)
    #3 0xaaaad00b61dc  (/root/main+0x561dc)
    #4 0xaaaad00c0574  (/root/main+0x60574)
    #5 0xaaaad00b6290  (/root/main+0x56290)
    #6 0xaaaad00b6170  (/root/main+0x56170)
    #7 0xaaaad00b3578  (/root/main+0x53578)
    #8 0xffff81345e70  (/lib64/libc.so.6+0x20e70)
    #9 0xaaaad0096310  (/root/main+0x36310)

[0xefdeffff0040,0xefdeffff0060) is a small allocated heap chunk; size: 32 offset: 16
0xefdeffff0050 is located 0 bytes to the right of 16-byte region [0xefdeffff0040,0xefdeffff0050)
allocated here:
    #0 0xaaaad009bcdc  (/root/main+0x3bcdc)
    #1 0xaaaad00b1eb0  (/root/main+0x51eb0)
    #2 0xaaaad00b20d4  (/root/main+0x520d4)
    #3 0xaaaad00b2800  (/root/main+0x52800)
    #4 0xaaaad00b1cf4  (/root/main+0x51cf4)
    #5 0xaaaad00b33d4  (/root/main+0x533d4)
    #6 0xaaaad00b39b4  (/root/main+0x539b4)
    #7 0xaaaad00b61dc  (/root/main+0x561dc)
    #8 0xaaaad00b3578  (/root/main+0x53578)
    #9 0xaaaad0096310  (/root/main+0x36310)

Thread: T0 0xeffe00002000 stack: [0xffffc0590000,0xffffc0d90000) sz: 8388608 tls: [0xffff81521020,0xffff815217d0)
Memory tags around the buggy address (one tag corresponds to 16 bytes):
  0xfefcefffef80: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0xfefcefffef90: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0xfefcefffefa0: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0xfefcefffefb0: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0xfefcefffefc0: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0xfefcefffefd0: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0xfefcefffefe0: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0xfefcefffeff0: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
=>0xfefceffff000: a2  a2  05  00  e5 [00] 00  00  00  00  00  00  00  00  00  00
  0xfefceffff010: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0xfefceffff020: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0xfefceffff030: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0xfefceffff040: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0xfefceffff050: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0xfefceffff060: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0xfefceffff070: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0xfefceffff080: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
Tags for short granules around the buggy address (one tag corresponds to 16 bytes):
  0xfefcefffeff0: ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..
=>0xfefceffff000: ..  ..  c5  ..  .. [..] ..  ..  ..  ..  ..  ..  ..  ..  ..  ..
  0xfefceffff010: ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..
See https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html#short-granules for a description of short granule tags
Registers where the failure occurred (pc 0xaaaad00b3468):
    x0  e500efdeffff0050  x1  0000000000000004  x2  0000ffffc0d8f5a0  x3  0200efff00000000
    x4  0000ffffc0d8f4c0  x5  000000000000004f  x6  00000ffffc0d8f36  x7  0000efff00000000
    x8  e500efdeffff0050  x9  0200efff00000000  x10 0000000000000000  x11 0200efff00000000
    x12 0200effe000006b0  x13 0200effe000006b0  x14 0000000000000008  x15 00000000c00000cf
    x16 0000aaaad00a0afc  x17 0000000000000003  x18 0000000000000001  x19 0000ffffc0d8f718
    x20 ba00ffffc0d8f7a0  x21 0000aaaad00962e0  x22 0000000000000000  x23 0000000000000000
    x24 0000000000000000  x25 0000000000000000  x26 0000000000000000  x27 0000000000000000
    x28 0000000000000000  x29 0000ffffc0d8f650  x30 0000aaaad00b3468
```

# Comments/Caveats
* HWASan is only supported on arm64.
* I'm not sure if I should add a feature gate or piggyback on the existing one for sanitizers.
* HWASan requires `-C target-feature=+tagged-globals`. That flag should probably be set transparently to the user. Not sure how to go about that.

# TODO
* Need more tests.
* Update documentation.
* Fix symbolization.
* Integrate with CI
2021-02-12 22:53:30 +01:00
Jacob Pratt
c28f2a8bee
Stabilize str_split_once 2021-02-09 23:17:11 -05:00
Mara Bos
2c8d1c8cef
Rollup merge of #81735 - klensy:span-fix, r=varkor
faster few span methods

Touched few methods, so it should be (hopefully) faster.

First two changes: instead splitting string from start and taking only last piece, split it from the end.
Last: swapped conditions, to first check boolean parameter.
2021-02-08 19:28:15 +01:00
Tri Vo
c7d9bffe76 HWASan support 2021-02-07 23:48:58 -08:00