Commit Graph

351 Commits

Author SHA1 Message Date
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
Denis Merigoux
d4ea9fa3fb
Restore the num_def_ids_untracked public function giving the total number of exported symbols for each crate
Restored underlying num_def_ids_method

Update compiler/rustc_metadata/src/rmeta/decoder/cstore_impl.rs

Changed name to fit with naming convention

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

Update compiler/rustc_metadata/src/rmeta/decoder/cstore_impl.rs

Replace regular doc with Rustdoc comment

Co-authored-by: Joshua Nelson <jyn514@gmail.com>

Clarifies third-party use of num_def_ids_untracked
2021-06-03 09:27:41 +02:00
Camille GILLOT
0e71283495 Restrict access to crate_name.
Also remove original_crate_name, which had the exact same implementation
2021-06-02 18:35:32 +02:00
Camille Gillot
4e3b220b02
Update compiler/rustc_metadata/src/rmeta/mod.rs
Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>
2021-06-02 14:00:49 +02:00
bors
7350f655ef Auto merge of #85908 - cjgillot:private-dep-query, r=Aaron1011
Make is_private_dep a query.

Part of #85153

r? `@Aaron1011`
2021-06-02 08:06:45 +00: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
Camille GILLOT
202d39a96b Drop metadata_encoding_version. 2021-06-01 21:12:27 +02:00
Camille GILLOT
28afaeec17 Make is_private_dep a query. 2021-06-01 21:03:55 +02:00
Camille Gillot
0f0f3138cb
Revert "Reduce the amount of untracked state in TyCtxt" 2021-06-01 09:05:22 +02:00
bjorn3
312f964478 Remove unused feature gates 2021-05-31 13:55:43 +02:00
Camille GILLOT
2543028161 Drop metadata_encoding_version. 2021-05-30 20:05:46 +02:00
Camille GILLOT
1119b48e02 Correct comments about untracked accesses. 2021-05-30 20:04:37 +02:00
Camille GILLOT
f0e5e22806 Make is_private_dep a query. 2021-05-30 20:04:22 +02:00
Camille GILLOT
10fb4b2fe5 Restrict access to crate_name.
Also remove original_crate_name, which had the exact same implementation
2021-05-30 19:54:04 +02:00
Camille GILLOT
5d9f96ab27 Make resolutions a query. 2021-05-30 19:47:00 +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
Pietro Albini
9e22b844dd remove cfg(bootstrap) 2021-05-24 11:07:48 -04:00
Alan Egerton
93c636211c
Provide option for specifying the profiler runtime
Currently, if `-Zinstrument-coverage` is enabled, the target is linked
against the `library/profiler_builtins` crate (which pulls in LLVM's
compiler-rt runtime).

This option enables backends to specify an alternative runtime crate for
handling injected instrumentation calls.
2021-05-17 08:31:33 +01:00
bors
3396a383bb Auto merge of #85178 - cjgillot:local-crate, r=oli-obk
Remove CrateNum parameter for queries that only work on local crate

The pervasive `CrateNum` parameter is a remnant of the multi-crate rustc idea.

Using `()` as query key in those cases avoids having to worry about the validity of the query key.
2021-05-17 01:42:03 +00:00
Andy Wang
f3c18bb50d
Reuse variable 2021-05-16 12:38:49 +01:00
Andy Wang
1ced98ac65
Remap after prepending cwd 2021-05-16 12:31:01 +01:00
bors
1025db84a6 Auto merge of #85211 - Aaron1011:metadata-invalid-span, r=michaelwoerister
Preserve `SyntaxContext` for invalid/dummy spans in crate metadata

Fixes #85197

We already preserved the `SyntaxContext` for invalid/dummy spans in the
incremental cache, but we weren't doing the same for crate metadata.
If an invalid (lo/hi from different files) span is written to the
incremental cache, we will decode it with a 'dummy' location, but keep
the original `SyntaxContext`. Since the crate metadata encoder was only
checking for `DUMMY_SP` (dummy location + root `SyntaxContext`),
the metadata encoder would treat it as a normal span, encoding the
`SyntaxContext`. As a result, the final span encoded to the metadata
would change across sessions, even if the crate itself was unchanged.

This could lead to an 'unstable fingerprint' ICE under the following conditions:
1. We compile a crate with an invalid span using incremental compilation. The metadata encoder discards the `SyntaxContext` since the span is invalid, while the incremental cache encoder preserves the `SyntaxContext`
2. From another crate, we execute a foreign query, decoding the invalid span from the metadata as `DUMMY_SP` (e.g. with `SyntaxContext::root()`). This span gets hashed into the query fingerprint. So far, this has always happened through the `optimized_mir` query.
3. We recompile the first crate using our populated incremental cache, without changing anything. We load the (previously) invalid span from our incremental cache - it gets converted to a span with a dummy (but valid) location, along with the original `SyntaxContext`. This span gets written out to the crate metadata - since it now has a valid location, we preserve its `SyntaxContext`.
4. We recompile the second crate, again using a populated incremental cache. We now re-run the foreign query `optimized_mir` - the foreign crate hash is unchanged, but we end up decoding a different span (it now ha a non-root `SyntaxContext`). This results in the fingerprint changing, resulting in an ICE.

This PR updates our encoding of spans in the crate metadata to mirror
the encoding of spans into the incremental cache. We now always encode a
`SyntaxContext`, and encode location information for spans with a
non-dummy location.
2021-05-14 16:58:30 +00:00
Guillaume Gomez
3db335b934
Rollup merge of #85068 - luqmana:78708-xcrate-diag, r=estebank
Fix diagnostic for cross crate private tuple struct constructors

Fixes #78708.

There was already some limited support for certain cross-crate scenarios but that didn't handle a tuple struct rexported from an inner module for example (e.g. the NonZero* types as seen in #85049).

```Rust
➜  cat bug.rs
fn main() {
    let _x = std::num::NonZeroU32(12);
    let n = std::num::NonZeroU32::new(1).unwrap();
    match n {
        std::num::NonZeroU32(i) => {},
    }
}
```

**Before:**
<details>

```Rust
➜  rustc +nightly bug.rs
error[E0423]: expected function, tuple struct or tuple variant, found struct `std::num::NonZeroU32`
   --> bug.rs:2:14
    |
2   |       let _x = std::num::NonZeroU32(12);
    |                ^^^^^^^^^^^^^^^^^^^^^^^^ help: use struct literal syntax instead: `std::num::NonZeroU32 { 0: val }`
    |
   ::: /home/luqman/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/nonzero.rs:148:1
[snip]
error[E0532]: expected tuple struct or tuple variant, found struct `std::num::NonZeroU32`
   --> bug.rs:5:9
    |
5   |           std::num::NonZeroU32(i) => {},
    |           ^^^^^^^^^^^^^^^^^^^^^^^ help: use struct pattern syntax instead: `std::num::NonZeroU32 { 0 }`
    |
   ::: /home/luqman/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/nonzero.rs:148:1
[snip]

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0423, E0532.
For more information about an error, try `rustc --explain E0423`.
```
</details>

**After:**
<details>

```Rust
➜  /rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc bug.rs
error[E0423]: cannot initialize a tuple struct which contains private fields
   --> bug.rs:2:14
    |
2   |     let _x = std::num::NonZeroU32(12);
    |              ^^^^^^^^^^^^^^^^^^^^
    |
note: constructor is not visible here due to private fields
   --> /rust/library/core/src/num/nonzero.rs:148:1
[snip]
error[E0532]: cannot match against a tuple struct which contains private fields
 --> bug.rs:5:9
  |
5 |         std::num::NonZeroU32(i) => {},
  |         ^^^^^^^^^^^^^^^^^^^^
  |
note: constructor is not visible here due to private fields
 --> bug.rs:5:30
  |
5 |         std::num::NonZeroU32(i) => {},
  |                              ^ private field

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0423, E0532.
For more information about an error, try `rustc --explain E0423`.
```
</details>

One question is if we should only collect the needed info for the cross-crate case after encountering an error instead of always doing it. Perf run perhaps to gauge the impact.
2021-05-13 15:54:10 +02:00
Aaron Hill
cdca3c81c1
Preserve SyntaxContext for invalid/dummy spans in crate metadata
Fixes #85197

We already preserved the `SyntaxContext` for invalid/dummy spans in the
incremental cache, but we weren't doing the same for crate metadata.
If an invalid (lo/hi from different files) span is written to the
incremental cache, we will decode it with a 'dummy' location, but keep
the original `SyntaxContext`. Since the crate metadata encoder was only
checking for `DUMMY_SP` (dummy location + root `SyntaxContext`),
the metadata encoder would treat it as a normal span, encoding the
`SyntaxContext`. As a result, the final span encoded to the metadata
would change across sessions, even if the crate itself was unchanged.

This PR updates our encoding of spans in the crate metadata to mirror
the encoding of spans into the incremental cache. We now always encode a
`SyntaxContext`, and encode location information for spans with a
non-dummy location.
2021-05-12 15:44:46 -04:00
Camille GILLOT
1fb9cad50a Use () for analysis. 2021-05-12 14:01:16 +02:00
Camille GILLOT
7f25b9f7a6 Use () for visible_parent_map. 2021-05-12 13:58:45 +02:00
Camille GILLOT
837f3e3e67 Use () for inherent_impls. 2021-05-12 13:58:44 +02:00
Camille GILLOT
75f4f6ee4f Use () for mir_keys. 2021-05-12 13:58:43 +02:00
Camille GILLOT
b7bf467fa3 Use () for proc_macro_decls_static. 2021-05-12 13:58:43 +02:00
Camille GILLOT
e9e1900af7 Use () for plugin_registrar_fn. 2021-05-12 13:58:43 +02:00
Camille GILLOT
85a14d70bb Use () in dependency_formats. 2021-05-12 13:58:41 +02: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
Luqman Aden
57fda67291 Fix diagnostic for matching/creating x-crate re-exported tuple structs with private fields.
The more helpful diagnostic already existed but wasn't working if the
struct in question was a re-export from a different crate.
2021-05-08 00:33:31 -07: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
0ac9ca4f88
Add -Z simulate-remapped-rust-src-base option to simulate path virutalisation during bootstrapping 2021-05-05 15:31:32 +01:00
Andy Wang
fb4f6439f6
Revamp RealFileName public methods 2021-05-05 15:31:03 +01:00
Andy Wang
e5445f3722
Emit RealFileName::Remapped on expanded relative path if working_dir has been remapped 2021-05-05 15:10:58 +01:00
Andy Wang
0407919083
Use RealFileName for Session::working_dir as it may also be remapped 2021-05-05 15:10:57 +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
Justus K
b6120bfb35
Add type to differentiate between fake and real DefId's 2021-05-04 19:34:12 +02:00
Brent Kerby
6679f5ceb1 Change 'NULL' to 'null' 2021-05-02 17:46:00 -06:00
Joshua Nelson
39648ea467 Make real_rust_path_dir a TRACKED_NO_CRATE_HASH option
This also adds support for doc-comments to Options.
2021-04-27 16:48:25 +00:00
Dylan DPC
379a55c64e
Rollup merge of #84450 - jyn514:missing-std, r=petrochenkov
Give a better error when `std` or `core` are missing

- Suggest using `rustup target add` if `RUSTUP_HOME` is set. I don't know if there's any precedent for doing this, but it seems harmless enough and it will be a big help.
- On nightly, suggest using `cargo build -Z build-std` if `CARGO` is set
- Add a note about `#![no_std]` if `std` is missing but not core
- Add a note that std may be unsupported if `std` is missing but not core

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

r? `@petrochenkov`
2021-04-25 23:15:11 +02:00
Joshua Nelson
d326a4b4c9 Give a better error when std or core are missing
- Suggest using `rustup target add` if `RUSTUP_HOME` is set. I don't know if there's any precedent for doing this, but it seems harmless enough and it will be a big help.
- Add a note about `#![no_std]` if `std` is missing but not core
- On nightly, suggest using `cargo build -Z build-std` if `CARGO` is set
- Add a note that std may be unsupported if `std` is missing but not core
- Don't suggest `#![no_std]` when the load isn't injected by the
  compiler
2021-04-25 16:45:31 +00:00
Josh Stone
b79af2fcde Implement #[rustc_skip_array_during_method_dispatch] 2021-04-16 11:11:59 -07:00
Dylan DPC
3c2e4ff525
Rollup merge of #83820 - petrochenkov:nolinkargs, r=nagisa
Remove attribute `#[link_args]`

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

The attribute could always be replaced with `-C link-arg`, but cargo didn't provide a reasonable way to pass such flags to rustc.
Now cargo supports `cargo:rustc-link-arg*` directives in build scripts (https://doc.rust-lang.org/cargo/reference/unstable.html#extra-link-arg), so this attribute can be removed.
2021-04-05 00:24:33 +02:00
Dylan DPC
a1c34493d4
Rollup merge of #73945 - est31:unused_externs, r=Mark-Simulacrum
Add an unstable --json=unused-externs flag to print unused externs

This adds an unstable flag to print a list of the extern names not used by cargo.

This PR will enable cargo to collect unused dependencies from all units and provide warnings.
The companion PR to cargo is: https://github.com/rust-lang/cargo/pull/8437

The goal is eventual stabilization of this flag in rustc as well as in cargo.

Discussion of this feature is mostly contained inside these threads: #57274 #72342 #72603

The feature builds upon the internal datastructures added by #72342

Externs are uniquely identified by name and the information is sufficient for cargo.
If the mode is enabled, rustc will print json messages like:

```
{"unused_extern_names":["byteorder","openssl","webpki"]}
```

For a crate that got passed byteorder, openssl and webpki dependencies but needed none of them.

### Q: Why not pass -Wunused-crate-dependencies?
A: See [ehuss's comment here](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355)
   TLDR: it's cleaner. Rust's warning system wasn't built to be filtered or edited by cargo.
   Even a basic implementation of the feature would have to change the "n warnings emitted" line that rustc prints at the end.
   Cargo ideally wants to synthesize its own warnings anyways. For example, it would be hard for rustc to emit warnings like
   "dependency foo is only used by dev targets", suggesting to make it a dev-dependency instead.

### Q: Make rustc emit used or unused externs?
A: Emitting used externs has the advantage that it simplifies cargo's collection job.
   However, emitting unused externs creates less data to be communicated between rustc and cargo.
   Often you want to paste a cargo command obtained from `cargo build -vv` for doing something
   completely unrelated. The message is emitted always, even if no warning or error is emitted.
   At that point, even this tiny difference in "noise" matters. That's why I went with emitting unused externs.

### Q: One json msg per extern or a collective json msg?
A: Same as above, the data format should be concise. Having 30 lines for the 30 crates a crate uses would be disturbing to readers.
   Also it helps the cargo implementation to know that there aren't more unused deps coming.

### Q: Why use names of externs instead of e.g. paths?
A: Names are both sufficient as well as neccessary to uniquely identify a passed `--extern` arg.
   Names are sufficient because you *must* pass a name when passing an `--extern` arg.
   Passing a path is optional on the other hand so rustc might also figure out a crate's location from the file system.
   You can also put multiple paths for the same extern name, via e.g. `--extern hello=/usr/lib/hello.rmeta --extern hello=/usr/local/lib/hello.rmeta`,
   but rustc will only ever use one of those paths.
   Also, paths don't identify a dependency uniquely as it is possible to have multiple different extern names point to the same path.
   So paths are ill-suited for identification.

### Q: What about 2015 edition crates?
A: They are fully supported.
   Even on the 2015 edition, an explicit `--extern` flag is is required to enable `extern crate foo;` to work (outside of sysroot crates, which this flag doesn't warn about anyways).
   So the lint would still fire on 2015 edition crates if you haven't included a dependency specified in Cargo.toml using `extern crate foo;` or similar.
   The lint won't fire if your sole use in the crate is through a `extern crate foo;`   statement, but that's not its job.
   For detecting unused `extern crate foo` statements, there is the `unused_extern_crates` lint
   which can be enabled by `#![warn(unused_extern_crates)]` or similar.

cc ```@jsgf``` ```@ehuss``` ```@petrochenkov``` ```@estebank```
2021-04-04 19:19:58 +02:00
Vadim Petrochenkov
5839bff0ba Remove attribute #[link_args] 2021-04-03 21:25:53 +03:00
bors
97717a5618 Auto merge of #83682 - bjorn3:mmap_wrapper, r=cjgillot
Add an Mmap wrapper to rustc_data_structures

This wrapper implements StableAddress and falls back to directly reading the file on wasm32.

Taken from #83640, which I will close due to the perf regression.
2021-04-03 13:23:42 +00:00
Camille GILLOT
9d8f833e05 Remove hir::CrateItem. 2021-03-30 20:31:06 +02:00
bjorn3
8331dbe6d0 Add an Mmap wrapper to rustc_data_structures
This wrapper implements StableAddress and falls back to directly reading
the file on wasm32
2021-03-30 18:57:03 +02:00
Michael Woerister
09bab38291 Fix #83045 by moving some crate loading verification code to a better place. 2021-03-26 09:59:10 +01:00
bors
dbc37a97dc Auto merge of #83307 - richkadel:cov-unused-functions-1.1, r=tmandry
coverage bug fixes and optimization support

Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.

Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.

Fixes: #82144

Invalid LLVM coverage data produced when compiled with -C opt-level=1

Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.

The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:

1. Rust's coverage map does not include any overlapping code regions,
   making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
   functions, including generics. (Clang does not generate coverage for
   uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
   sufficient for including in the coverage results; while Clang must
   generate the complete LLVM IR for each unused function, even though
   it will never be called.

This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.

Fixes: #79651

Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates

Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.

Fixes: #82875

Invalid LLVM coverage data produced with crate brotli_decompressor

Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.

FYI: `@wesleywiser`

r? `@tmandry`
2021-03-25 05:07:34 +00:00
kadmin
7116bb5c33 Update with comments 2021-03-23 17:16:20 +00:00
kadmin
ea2af70466 Update with comments
A bunch of nits fixed, and a new test for pretty printing the AST.
2021-03-23 17:16:20 +00:00
kadmin
9fe793ae5d Add query for const_param_default 2021-03-23 17:16:20 +00:00
varkor
8ef81388e2 Some refactoring 2021-03-23 17:16:20 +00:00
bors
5d04957a4b Auto merge of #79278 - mark-i-m:stabilize-or-pattern, r=nikomatsakis
Stabilize or_patterns (RFC 2535, 2530, 2175)

closes #54883

This PR stabilizes the or_patterns feature in Rust 1.53.

This is blocked on the following (in order):
- [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021
- [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705)
    - It looks like we will need to pursue some sort of edition-based transition for `:pat`.
- [x] Nomination and discussion by T-lang
- [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100).
- [ ] An FCP on stabilization

EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177
2021-03-22 19:48:27 +00:00
bors
d04c3aa865 Auto merge of #83273 - cjgillot:endecode, r=michaelwoerister
Simplify encoder and decoder

Extracted from https://github.com/rust-lang/rust/pull/83036 and https://github.com/rust-lang/rust/pull/82780.
2021-03-22 12:18:57 +00:00
mark
db5629adcb stabilize or_patterns 2021-03-19 19:45:32 -05:00
Rich Kadel
bcf755562a coverage bug fixes and optimization support
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.

Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.

Fixes: #82144

Invalid LLVM coverage data produced when compiled with -C opt-level=1

Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.

The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:

1. Rust's coverage map does not include any overlapping code regions,
   making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
   functions, including generics. (Clang does not generate coverage for
   uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
   sufficient for including in the coverage results; while Clang must
   generate the complete LLVM IR for each unused function, even though
   it will never be called.

This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.

Fixes: #79651

Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates

Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.

Fixes: #82875

Invalid LLVM coverage data produced with crate brotli_decompressor

Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.
2021-03-19 17:11:50 -07:00
Camille GILLOT
11b3409b5d Remove FingerprintEncoder/Decoder. 2021-03-19 19:36:05 +01:00
Camille GILLOT
09a638820e Move raw bytes handling to Encoder/Decoder. 2021-03-19 19:35:22 +01:00
Dylan DPC
23128c4183
Rollup merge of #83236 - cjgillot:memmap, r=joshtriplett
Upgrade memmap to memmap2

memmap is no longer maintained. memmap2 is a fork that is still maintained. https://rustsec.org/advisories/RUSTSEC-2020-0077.html

The remaining use of memmap is through measureme.
2021-03-19 15:03:28 +01:00
Camille GILLOT
458d044c5b Upgrade memmap to memmap2 in other crates. 2021-03-18 18:36:55 +01:00
Camille GILLOT
fcd6f20700 Iterate for super_predicates. 2021-03-17 17:30:50 +01:00
Camille GILLOT
c74a3553ae Filter generics. 2021-03-16 20:07:26 +01:00
Camille GILLOT
4223db76b9 Iterate on inferred_outlives. 2021-03-16 20:07:26 +01:00
Camille GILLOT
58bca6f658 Iterate on explicit_predicates. 2021-03-16 20:07:26 +01:00
Camille GILLOT
dda31b97c8 Iterate on generics_of. 2021-03-16 20:07:25 +01:00
Camille GILLOT
6337594e3c Iterate on variances_of. 2021-03-16 20:07:25 +01:00
Camille GILLOT
ab1782975a Iterate on crate_inherent_impls for metadata. 2021-03-13 14:17:55 +01:00
Camille GILLOT
c701872a6c Remove hir::Item::attrs. 2021-03-09 19:27:50 +01:00
Camille GILLOT
a987bbb97c Remove hir::Crate::attrs. 2021-03-09 19:22:55 +01:00
est31
d8c9a28703 Fix the tests 2021-03-08 08:18:50 +01:00
est31
3a62eb74db Emit the lint level of the unused-crate-dependencies
Also, turn off the lint when the unused dependencies json flag
is specified so that cargo doesn't have to supress the lint
2021-03-08 08:18:46 +01:00
est31
3f2ca47a79 Gate the printing on --json=unused-externs 2021-03-08 08:17:48 +01:00
est31
aef1e35edc Emit unused externs 2021-03-08 08:17:48 +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
Amanieu d'Antras
d87eec1bf6 Add #[rustc_legacy_const_generics] 2021-02-23 17:25:55 +00: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
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
Matthias Krüger
4390a61b64 avoid full-slicing slices
If we already have a slice, there is no need to get another full-range slice from that, just use the original.
clippy::redundant_slicing
2021-02-16 00:31:11 +01:00
Camille GILLOT
c4e7427081 Only store a LocalDefId in hir::MacroDef. 2021-02-15 19:35:55 +01:00
Camille GILLOT
996dc8d5c5 Only store a LocalDefId in hir::ForeignItem. 2021-02-15 19:32:29 +01:00
Camille GILLOT
cebbba081e Only store a LocalDefId in hir::Item.
Items are guaranteed to be HIR owner.
2021-02-15 19:32:10 +01:00
klensy
93c8ebe022 bumped smallvec deps 2021-02-14 18:03:11 +03:00
Mara Bos
b376c50aa2
Rollup merge of #81861 - tmiasko:mir-bytes, r=wesleywiser
Show MIR bytes separately in -Zmeta-stats output

The size of serialized MIR is substantial enough to deserve its own category.
2021-02-08 19:28:23 +01:00
Jeremy Fitzhardinge
82ccb6582a Add --extern-loc to augment unused crate dependency diagnostics
This allows a build system to indicate a location in its own dependency
specification files (eg Cargo's `Cargo.toml`) which can be reported
along side any unused crate dependency.

This supports several types of location:
 - 'json' - provide some json-structured data, which is included in the json diagnostics
     in a `tool_metadata` field
 - 'raw' - emit the provided string into the output. This also appears as a json string in
     `tool_metadata`.

If no `--extern-location` is explicitly provided then a default json entry of the form
`"tool_metadata":{"name":<cratename>,"path":<cratepath>}` is emitted.
2021-02-07 14:54:20 -08:00
Tomasz Miąsko
a14ec1cedf Show MIR bytes separately in -Zmeta-stats output 2021-02-07 00:00:00 +00:00
bors
23adf9fd84 Auto merge of #81215 - cjgillot:defkey-mir, r=oli-obk
Encode MIR metadata by iterating on DefId instead of traversing the HIR tree

Split out of https://github.com/rust-lang/rust/pull/80347.

This part only traverses `mir_keys` and encodes MIR according to the def kind.

r? `@oli-obk`
2021-02-05 18:21:47 +00:00
Camille GILLOT
09ac459bc7 Encode less consts. 2021-02-04 18:02:14 +01:00
Camille GILLOT
0658d8c097 Address review. 2021-02-03 14:29:18 +01:00
Michael Woerister
22d489be76 Let a portion of DefPathHash uniquely identify the DefPath's crate.
This allows to directly map from a DefPathHash to the crate it
originates from, without constructing side tables to do that mapping.

It also allows to reliably and cheaply check for DefPathHash collisions.
2021-02-02 17:40:29 +01:00
Ryan Levick
6c7ecd007f Pre-canoncalize ExternLocation::ExactPaths 2021-01-29 11:02:12 +01:00
Ryan Levick
36835b704f Check for rmeta crates when getting existing crates from cache 2021-01-26 19:39:24 +01:00
Camille GILLOT
5a60f0a86f Sort mir_keys to ensure consistent diagnostic order. 2021-01-24 12:45:26 +01:00
Camille GILLOT
d88420a52a Review comment. 2021-01-24 12:44:59 +01:00
Camille GILLOT
23d415a484 Refactor MIR metadata emission. 2021-01-24 12:44:58 +01:00
Camille GILLOT
f071b5066a Introduce should_encode_mir. 2021-01-24 12:42:33 +01:00
Camille GILLOT
89360931f2 Fix proc macro crate encoding. 2021-01-23 13:57:43 +01:00
Camille GILLOT
4eb0bbd2a8 Filter stability. 2021-01-23 13:57:17 +01:00
Camille GILLOT
4e60ecf783 Iterate on deprecation. 2021-01-23 13:56:50 +01:00
Camille GILLOT
4468473e1b Iterate on const_stability. 2021-01-23 13:56:24 +01:00
Camille GILLOT
f1a7e1df3a Iterate on stability. 2021-01-23 13:55:57 +01:00
Camille GILLOT
7a5620c63a Iterate DefId to encode expn_that_defined. 2021-01-23 13:55:35 +01:00
Camille GILLOT
293e885daa Iterate DefId to encode attributes. 2021-01-23 13:54:22 +01:00
Camille GILLOT
f1bf6d0e48 Iterate DefId to encode visibility. 2021-01-23 13:53:26 +01:00
Camille GILLOT
a185cdbc59 Iterate to encode def_kind. 2021-01-23 13:51:00 +01:00
Camille GILLOT
c58a6fa422 Iterate DefId to encode spans. 2021-01-23 13:44:02 +01:00
Camille GILLOT
0b6c9e9f88 Encode DefKind directly. 2021-01-23 13:42:56 +01:00
Jack Huey
674735b109 Impl EncodableWithShorthand for PredicateKind 2021-01-17 02:49:30 -05:00
Jack Huey
f2ed9a3a8c Can't use EncodableWithShorthand for Predicate 2021-01-16 19:17:59 -05:00
bors
fcbd305ee9 Auto merge of #80602 - tgnottingham:cratemetadata_you_aint_special, r=michaelwoerister
Remove DepKind::CrateMetadata and pre-allocation of DepNodes

Remove much of the special-case handling around crate metadata
dependency tracking by replacing `DepKind::CrateMetadata` and the
pre-allocation of corresponding `DepNodes` with on-demand invocation
of the `crate_hash` query.
2021-01-15 21:13:35 +00:00
LingMan
a56bffb4f9 Use Option::map_or instead of .map(..).unwrap_or(..) 2021-01-14 19:23:59 +01:00
Tomasz Miąsko
ea4cbff264 Encode optimized MIR of generators when emitting metadata 2021-01-14 00:00:00 +00:00
bors
a62a76047e Auto merge of #77524 - Patryk27:fixes/66228, r=estebank
Rework diagnostics for wrong number of generic args (fixes #66228 and #71924)

This PR reworks the `wrong number of {} arguments` message, so that it provides more details and contextual hints.
2021-01-13 20:35:58 +00:00
bors
9bc8b00b4a Auto merge of #80718 - tmiasko:skip-opt-mir, r=oli-obk
Consistently avoid constructing optimized MIR when not doing codegen

The optimized MIR for closures is being encoded unconditionally, while
being unnecessary for cargo check. This turns out to be especially
costly with MIR inlining enabled, since it triggers computation of
optimized MIR for all callees that are being examined for inlining
purposes https://github.com/rust-lang/rust/pull/77307#issuecomment-751915450.

Skip encoding of optimized MIR for closures, enum constructors, struct
constructors, and trait fns when not doing codegen, like it is already
done for other items since 49433.
2021-01-13 17:48:41 +00:00
bors
150d1fee04 Auto merge of #79322 - jyn514:refactor-impl, r=estebank
Separate out a `hir::Impl` struct

This makes it possible to pass the `Impl` directly to functions, instead
of having to pass each of the many fields one at a time. It also
simplifies matches in many cases.

See `rustc_save_analysis::dump_visitor::process_impl` or `rustdoc::clean::clean_impl` for a good example of how this makes `impl`s easier to work with.

r? `@petrochenkov` maybe?
2021-01-13 01:40:41 +00:00
Joshua Nelson
a8ff647deb Separate out a hir::Impl struct
This makes it possible to pass the `Impl` directly to functions, instead
of having to pass each of the many fields one at a time. It also
simplifies matches in many cases.
2021-01-12 20:32:33 -05:00
Tomasz Miąsko
16857317a6 Skip promoted mir of struct constructors & enum constructors 2021-01-13 00:33:36 +01:00
Tomasz Miąsko
a6dd7b5056 Consistently avoid constructing optimized MIR when not doing codegen
The optimized MIR for closures is being encoded unconditionally, while
being unnecessary for cargo check. This turns out to be especially
costly with MIR inlining enabled, since it triggers computation of
optimized MIR for all callees that are being examined for inlining
purposes.

Skip encoding of optimized MIR for closures, enum constructors, struct
constructors, and trait fns when not doing codegen, like it is already
done for other items since 49433.
2021-01-13 00:33:36 +01:00
Tomasz Miąsko
1bf3949398 Reorder MIR encoding checks
Start from least expensive checks when deciding whether to encode MIR or not.

No functional changes intended.
2021-01-12 21:18:39 +01:00
Tyson Nottingham
8e7cbc28a6 Prevent potential bug resulting from changing crate_hash query name 2021-01-12 11:22:58 -08:00
Tyson Nottingham
0962e5eba9 Return to defining crate_hash similarly to other query providers 2021-01-12 11:22:58 -08:00
Tyson Nottingham
62139ffad4 Remove DepKind::CrateMetadata and pre-allocation of DepNodes
Remove much of the special-case handling around crate metadata
dependency tracking by replacing `DepKind::CrateMetadata` and the
pre-allocation of corresponding `DepNodes` with on-demand invocation
of the `crate_hash` query.
2021-01-12 11:22:57 -08:00
bors
704e47f78b Auto merge of #78407 - oli-obk:ub_checkable_ctfe, r=RalfJung,pnkfelix
Make CTFE able to check for UB...

... by not doing any optimizations on the `const fn` MIR used in CTFE. This means we duplicate all `const fn`'s MIR now, once for CTFE, once for runtime. This PR is for checking the perf effect, so we have some data when talking about https://github.com/rust-lang/const-eval/blob/master/rfcs/0000-const-ub.md

To do this, we now have two queries for obtaining mir: `optimized_mir` and `mir_for_ctfe`. It is now illegal to invoke `optimized_mir` to obtain the MIR of a const/static item's initializer, an array length, an inline const expression or an enum discriminant initializer. For `const fn`, both `optimized_mir` and `mir_for_ctfe` work, the former returning the MIR that LLVM should use if the function is called at runtime. Similarly it is illegal to invoke `mir_for_ctfe` on regular functions.

This is all checked via appropriate assertions and I don't think it is easy to get wrong, as there should be no `mir_for_ctfe` calls outside the const evaluator or metadata encoding. Almost all rustc devs should keep using `optimized_mir` (or `instance_mir` for that matter).
2021-01-12 17:26:56 +00:00
Tyson Nottingham
52f21791fb Serialize incr comp structures to file via fixed-size buffer
Reduce a large memory spike that happens during serialization by writing
the incr comp structures to file by way of a fixed-size buffer, rather
than an unbounded vector.

Effort was made to keep the instruction count close to that of the
previous implementation. However, buffered writing to a file inherently
has more overhead than writing to a vector, because each write may
result in a handleable error. To reduce this overhead, arrangements are
made so that each LEB128-encoded integer can be written to the buffer
with only one capacity and error check. Higher-level optimizations in
which entire composite structures can be written with one capacity and
error check are possible, but would require much more work.

The performance is mostly on par with the previous implementation, with
small to moderate instruction count regressions. The memory reduction is
significant, however, so it seems like a worth-while trade-off.
2021-01-11 12:13:22 -08:00
Patryk Wychowaniec
d2f8e398f1
Rework diagnostics for wrong number of generic args 2021-01-10 13:07:40 +01:00
Yuki Okushi
598d189e9b
Rollup merge of #80643 - LingMan:unwrap, r=oli-obk
Move variable into the only branch where it is relevant

At the `if` branch `filter` (the `let` binding) is `None` iff `filter` (the parameter) was `None`.
We can branch on the parameter, move the binding into the `if`, and the complexity of handling
`Option<Option<_>` largely dissolves.

`@rustbot` modify labels +C-cleanup +T-compiler

Note: I have no idea how hot this code is. If this method frequently gets called with a `None` filter, there might be a small perf improvement.
2021-01-05 09:52:44 +09:00
oli
1f5fb3e056 Differentiate between the availability of ctfe MIR and runtime MIR 2021-01-04 21:40:38 +00:00
oli
cccd40f9b5 Keep an unoptimized duplicate of const fn around
This allows CTFE to reliably detect UB, as otherwise
optimizations may hide UB.
2021-01-04 21:40:38 +00:00
oli
8e4fe6647f Require the encode_promoted_mir caller to know whether MIR for this item actually exists 2021-01-04 21:40:38 +00:00
oli
248b4dbc4f Limit trait item mir encoding to items with default bodies 2021-01-04 21:40:38 +00:00
oli
dadf937a12 Remove mir encode calls that didn't actually encode anything 2021-01-04 21:40:38 +00:00
oli
552f391969 Make encode_optimized_mir always perform its action and instead require the callers to know whether they actually want this 2021-01-04 21:40:38 +00:00
bors
887398ff68 Auto merge of #80610 - Aaron1011:unhash-def-path-hash, r=varkor
Use `UnhashMap` whenever we have a key of `DefPathHash`
2021-01-04 07:49:01 +00:00
Guillaume Gomez
539c435b50
Rollup merge of #80646 - bugadani:meta, r=petrochenkov
Clean up in `each_child_of_item`

This PR hopes to eliminate some of the surprising elements I encountered while reading the function.
- `macros_only` is checked against inside the loop body, but if it is `true`, the loop is skipped anyway
- only query `span` when relevant
- no need to allocate attribute vector
2021-01-03 17:09:13 +01:00
Guillaume Gomez
ff1f21a8fd
Rollup merge of #80628 - matthiaskrgr:match_ref_pats, r=varkor
reduce borrowing and (de)referencing around match patterns (clippy::match_ref_pats)
2021-01-03 17:09:11 +01:00
Dániel Buga
4d3227fe1c Move variable into condition where it's used 2021-01-03 13:55:43 +01:00
Dániel Buga
250fb72d1b No need to collect result of get_item_attrs 2021-01-03 13:55:40 +01:00
Dániel Buga
675059a9eb Clean up convoluted macros_only logic 2021-01-03 12:47:38 +01:00
bors
18cb4ad3b9 Auto merge of #80247 - tmiasko:indent, r=bjorn3
Fix indentation of -Z meta-stats output
2021-01-03 09:16:24 +00:00
LingMan
af7134e7de Move variable into the only branch where it is relevant
At the `if` branch `filter` (the `let` binding) is `None` iff `filter` (the parameter) was `None`.
We can branch on the parameter, move the binding into the `if`, and the complexity of handling
`Option<Option<_>` largely dissolves.
2021-01-03 10:07:22 +01:00
Matthias Krüger
8a90626a46 reduce borrowing and (de)referencing around match patterns (clippy::match_ref_pats) 2021-01-02 20:09:17 +01:00
Aaron Hill
0dc9b26523
Use UnhashMap whenever we have a key of DefPathHash 2021-01-01 23:51:07 -05:00
Rémy Rakic
1fc3c4c16d adjust const generics defaults FIXMEs to the new feature gate 2021-01-01 11:01:01 +01:00
Joshua Nelson
edeac1778c Rename kw::Invalid -> kw::Empty
See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Is.20there.20a.20symbol.20for.20the.20empty.20string.3F/near/220054471
for context.
2020-12-30 09:50:02 -05:00
Tomasz Miąsko
a046d4014a Fix indentation of -Z meta-stats output 2020-12-20 00:00:00 +00:00
Yuki Okushi
2808038518
Rollup merge of #80039 - LeSeulArtichaut:rm-tyencoder-tcx, r=matthewjasper
Remove unused `TyEncoder::tcx` required method

Unsure if this is helpful or not...

r? ``@ghost`` cc ``@matthewjasper`` ``@jackh726``
2020-12-17 11:44:03 +09:00
Rich Kadel
36c639a2ce Convenience funcs for some_option.unwrap_or(...)
This ensures consistent handling of default values for options that are
None if not specified on the command line.
2020-12-14 17:27:27 -08:00
LeSeulArtichaut
a72b739bf0 Remove unused TyEncoder::tcx required method 2020-12-14 23:33:47 +01:00
Rich Kadel
4f550f1f93 Improve warnings on incompatible options involving -Zinstrument-coverage
Adds checks for:

* `no_core` attribute
* explicitly-enabled `legacy` symbol mangling
* mir_opt_level > 1 (which enables inlining)

I removed code from the `Inline` MIR pass that forcibly disabled
inlining if `-Zinstrument-coverage` was set. The default `mir_opt_level`
does not enable inlining anyway. But if the level is explicitly set and
is greater than 1, I issue a warning.

The new warnings show up in tests, which is much better for diagnosing
potential option conflicts in these cases.
2020-12-14 12:55:46 -08:00
Aaron Hill
a332e2b38f
Account for gaps in def path table during decoding
When encoding a proc-macro crate, there may be gaps in the table (since
we only encode the crate root and proc-macro items). Account for this by
checking if the entry is present, rather than using `unwrap()`
2020-12-08 13:02:53 -05:00
Vadim Petrochenkov
908bf5a310 rustc_metadata: Remove some dead code 2020-12-03 00:05:24 +03:00
bors
4cbda829c0 Auto merge of #74967 - Aaron1011:feature/incr-def-path-table, r=pnkfelix
Implement lazy decoding of DefPathTable during incremental compilation

PR https://github.com/rust-lang/rust/pull/75813 implemented lazy decoding of the `DefPathTable` from crate metadata. However, it requires decoding the entire `DefPathTable` when incremental compilation is active, so that we can map a decoded `DefPathHash` to a `DefId` from an arbitrary crate.

This PR adds support for lazy decoding of dependency `DefPathTable`s when incremental compilation si active.

When we load the incremental cache and dep
graph, we need the ability to map a `DefPathHash` to a `DefId` in the
current compilation session (if the corresponding definition still
exists).

This is accomplished by storing the old `DefId` (that is, the `DefId`
from the previous compilation session) for each `DefPathHash` we need to
remap. Since a `DefPathHash` includes the owning crate, the old crate is
guaranteed to be the right one (if the definition still exists). We then
use the old `DefIndex` as an initial guess, which we validate by
comparing the expected and actual `DefPathHash`es. In most cases,
foreign crates will be completely unchanged, which means that we our
guess will be correct. If our guess is wrong, we fall back to decoding
the entire `DefPathTable` for the foreign crate. This still represents
an improvement over the status quo, since we can skip decoding the
entire `DefPathTable` for other crates (where all of our guesses were
correct).
2020-12-01 14:30:02 +00:00
Camille GILLOT
9dd32e177e Encode proc_macro directly.
Encode proc_macro name directly.

Do not store None values.
2020-11-27 20:39:49 +01:00
Camille GILLOT
60c3bbd844 Formatting. 2020-11-26 21:32:29 +01:00
Camille GILLOT
032f68d625 Remove ForeignMod struct. 2020-11-26 21:32:27 +01:00
Camille GILLOT
419a9186a4 Store ForeignItem in a side table. 2020-11-26 21:29:27 +01:00
Aaron Hill
e935d3832c
Lazy DefPath decoding for incremental compilation 2020-11-25 14:49:15 -05:00
varkor
cf32afcf48 Stabilise then 2020-11-22 13:45:14 +00:00
Hannah McLaughlin
d38dbcb19f Improve error message when we try to get_type on something that does not have a type 2020-11-18 21:20:51 +00:00
Dániel Buga
f0d0d87a20 Push to result vector instead of allocating
Co-authored-by: lcnr <bastian_kauschke@hotmail.de>
2020-11-13 11:19:25 +01:00
Dániel Buga
660d8a6550 Eliminate some temporary vectors & Remove unnecessary mark_attr_used 2020-11-13 11:19:23 +01:00
Nicholas-Baron
261ca04c92 Changed unwrap_or to unwrap_or_else in some places.
The discussion seems to have resolved that this lint is a bit "noisy" in
that applying it in all places would result in a reduction in
readability.

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

The general rule seems to be that anything that is obviously an
allocation (`Box`, `Vec`, `vec![]`) should be in a closure, even if it
is a 0-sized allocation.
2020-11-10 20:07:47 -08:00
Vadim Petrochenkov
bf66988aa1 Collapse all uses of target.options.foo into target.foo
with an eye on merging `TargetOptions` into `Target`.

`TargetOptions` as a separate structure is mostly an implementation detail of `Target` construction, all its fields logically belong to `Target` and available from `Target` through `Deref` impls.
2020-11-08 17:29:13 +03:00
bors
7b5a9e9cd2 Auto merge of #78448 - rylev:cache-foreign_modules, r=wesleywiser
foreign_modules query hash table lookups

When compiling a large monolithic crate we're seeing huge times in the `foreign_modules` query due to repeated iteration over foreign modules (in order to find a module by its id). This implements hash table lookups so that which massively reduces time spent in that query in this particular case. We'll need to see if the overhead of creating the hash table has a negative impact on performance in more normal compilation scenarios.

I'm working with `@wesleywiser` on this.
2020-11-03 04:27:27 +00:00
Joshua Nelson
bfecb18771 Fix some more clippy warnings 2020-10-30 10:12:56 -04:00
Tomasz Miąsko
2661a4edb9 Avoid BorrowMutError with RUSTC_LOG=debug
$ touch empty.rs
$ env RUSTC_LOG=debug rustc +stage1 --crate-type=lib empty.rs

Fails with a `BorrowMutError` because source map files are already
borrowed while `features_query` attempts to format a log message
containing a span.

Release the borrow before the query to avoid the issue.
2020-10-29 18:09:53 +01:00
Ryan Levick
81444b2049 Remove some cruft from foreign_modules refactor 2020-10-27 20:17:48 +01:00
Ryan Levick
69dc98161a Cache foreign_modules query 2020-10-27 16:21:55 +01:00
Aaron Hill
283053a742
Compute proper module parent during resolution
Fixes #75982

The direct parent of a module may not be a module
(e.g. `const _: () =  { #[path = "foo.rs"] mod foo; };`).

To find the parent of a module for purposes of resolution, we need to
walk up the tree until we hit a module or a crate root.
2020-10-24 14:28:13 -04:00
Vadim Petrochenkov
cee5521a03 Calculate visibilities once in resolve
Then use them through a query based on resolver outputs
2020-10-19 11:57:50 +03:00
est31
4fa5578774 Replace target.target with target and target.ptr_width with target.pointer_width
Preparation for a subsequent change that replaces
rustc_target::config::Config with its wrapped Target.

On its own, this commit breaks the build. I don't like making
build-breaking commits, but in this instance I believe that it
makes review easier, as the "real" changes of this PR can be
seen much more easily.

Result of running:

find compiler/ -type f -exec sed -i -e 's/target\.target\([)\.,; ]\)/target\1/g' {} \;
find compiler/ -type f -exec sed -i -e 's/target\.target$/target/g' {} \;
find compiler/ -type f -exec sed -i -e 's/target.ptr_width/target.pointer_width/g' {} \;
./x.py fmt
2020-10-15 12:02:24 +02:00
est31
215cd36e1c Remove unused code from remaining compiler crates 2020-10-14 04:14:32 +02:00
Dániel Buga
0d27b765a6 Take functions by value 2020-10-10 16:19:53 +02:00
Matthew Jasper
f958e6c246 Separate bounds and predicates for associated/opaque types 2020-10-06 11:19:29 +01:00
Matthew Jasper
d297147e62 Split bounds from predicates 2020-10-06 11:19:22 +01:00
Aaron Hill
8d11f90a16
Record expansion_that_defined into crate metadata
Fixes #77523

Now that hygiene serialization is implemented, we also need to record
`expansion_that_defined` so that we properly handle a foreign
`SyntaxContext`.
2020-10-05 16:01:19 -04:00
Vadim Petrochenkov
384eb2691f rustc_metadata: Do not forget to encode inherent impls for foreign types 2020-09-30 22:58:35 +03:00
bors
d902752866 Auto merge of #77118 - exrook:stability-generic-parameters-2, r=varkor
Stability annotations on generic parameters (take 2.5)

Rebase of #72314 + more tests

Implements rust-lang/wg-allocators#2.
2020-09-27 12:51:21 +00:00
Aaron Hill
b9653568a7
Encode less metadata for proc-macro crates
Currently, we serialize the same crate metadata for proc-macro crates as
we do for normal crates. This is quite wasteful - almost none of this
metadata is ever used, and much of it can't even be deserialized (if it
contains a foreign `CrateNum`).

This PR changes metadata encoding to skip encoding the majority of crate
metadata for proc-macro crates. Most of the `Lazy<[T]>` fields are left
completetly empty, while the non-lazy fields are left as-is.

Additionally, proc-macros now have a def span that does not include
their body. This was done for normal functions in #75465, but was missed
for proc-macros.

As a result of this PR, we should only ever encode local `CrateNum`s
when encoding proc-macro crates. I've added a specialized serialization
impl for `CrateNum` to assert this.
2020-09-26 12:26:27 -04:00
Jonas Schievink
6f3da3d53f
Rollup merge of #77121 - duckymirror:html-root-url, r=jyn514
Updated html_root_url for compiler crates

Closes #77103

r? @jyn514
2020-09-25 02:29:45 +02:00
Erik Hofmayer
138a2e5eaa /nightly/nightly-rustc 2020-09-23 21:51:56 +02:00
Erik Hofmayer
dd66ea2d3d Updated html_root_url for compiler crates 2020-09-23 21:14:43 +02:00
Dylan DPC
98e5ee7df0
Rollup merge of #76939 - lcnr:const-evaluatable-cont, r=oli-obk
emit errors during AbstractConst building

There changes are currently still untested, so I don't expect this to pass CI 😆

It seems to me like this is the direction we want to go in, though we didn't have too much of a discussion about this.

r? @oli-obk
2020-09-23 14:54:02 +02:00
Avi Dessauer
a7a2086053 Stability annotations on generic trait parameters 2020-09-22 21:53:48 -04:00
Aaron Hill
e734733a9e
Record tcx.def_span instead of item.span in crate metadata
This was missed in PR #75465. As a result, a few places have been using
the full body span of functions, instead of just the header span.
2020-09-21 15:10:16 -04:00
Bastian Kauschke
d4039c55c9 wip emit errors during AbstractConst building 2020-09-19 22:17:52 +02:00
Bastian Kauschke
30ff1ef3d0 support const_evaluatable_checked across crate boundaries 2020-09-18 17:11:34 +02:00
Matthias Krüger
fd9be8f7aa don't lazily evaulate some trivial values for Option::None replacements (clippy::unnecessary_lazy_evaluations) 2020-09-15 23:17:51 +02:00
bors
1eb00abf35 Auto merge of #76656 - jonas-schievink:fewer-unstable-metadata-queries, r=lcnr
Don't query stability data when `staged_api` is off

This data only needs to be encoded when `#![feature(staged_api)]` or `-Zforce-unstable-if-unmarked` is on. Running these queries takes measurable time on large crates with many items, so skip it when the unstable flags have not been enabled.
2020-09-14 00:26:43 +00:00
Aaron Hill
a67d248b13
Properly encode spans with a dummy location and non-root SyntaxContext
Previously, we would throw away the `SyntaxContext` of any span with a
dummy location during metadata encoding. This commit makes metadata Span
encoding consistent with incr-cache Span encoding - an 'invalid span'
tag is only used when it doesn't lose any information.
2020-09-12 23:26:17 -04:00
Jonas Schievink
a447c21afa Don't query unstable data when staged_api is off 2020-09-13 02:10:39 +02:00
Aaron Hill
c1011165e6
Attach TokenStream to ast::Visibility
A `Visibility` does not have outer attributes, so we only capture tokens
when parsing a `macro_rules!` matcher
2020-09-10 17:33:06 -04:00
LeSeulArtichaut
3e14b684dd Change ty.kind to a method 2020-09-04 17:47:51 +02:00