Commit graph

278 commits

Author SHA1 Message Date
bors
ed33787335 Auto merge of #85284 - eggyal:custom-profiler-runtime, r=jackh726
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-06-18 04:39:01 +00:00
bors
6936ca8c99 Auto merge of #86311 - LeSeulArtichaut:cleanup-array-iter, r=jackh726
Use the now available implementation of `IntoIterator` for arrays
2021-06-15 07:46:48 +00:00
LeSeulArtichaut
e3ca81fd5a Use the now available implementation of IntoIterator for arrays 2021-06-14 23:40:09 +02:00
bors
304441960e Auto merge of #86117 - ehuss:force-warns-underscore, r=rylev
Fix force-warns to allow dashes.

The `--force-warns` flag was not allowing lint names with dashes, only supporting underscores.  This changes it to allow dashes to match the behavior of the A/W/D/F flags.
2021-06-14 17:21:28 +00:00
Eric Huss
7905473021 Fix force-warns to allow dashes. 2021-06-10 08:38:26 -07:00
1000teslas
2a76762695 gcc-lld mvp
ignore test if rust-lld not found

create ld -> rust-lld symlink at build time instead of run time

for testing in ci

copy instead of symlinking

remove linux check

test for linker, suggestions from bjorn3

fix overly restrictive lld matcher

use -Zgcc-ld flag instead of -Clinker-flavor

refactor code adding lld to gcc path

revert ci changes

suggestions from petrochenkov

rename gcc_ld to gcc-ld in dirs
2021-06-10 17:10:40 +10:00
bjorn3
8176ab8bc1 Revert "Merge CrateDisambiguator into StableCrateId"
This reverts commit d0ec85d3fb.
2021-06-07 10:37:45 +02:00
bors
9e6f0e878d Auto merge of #84234 - jyn514:blanket-hash, r=Aaron1011
Implement DepTrackingHash for `Option` through blanket impls instead of macros

This avoids having to add a new macro call for both the `Option` and the type itself.

Noticed this while working on https://github.com/rust-lang/rust/pull/84233.
r? `@Aaron1011`
2021-06-05 01:08:51 +00:00
bors
595088d602 Auto merge of #85788 - rylev:force-warns, r=nikomatsakis
Support for force-warns

Implements https://github.com/rust-lang/rust/issues/85512.

This PR adds a new command line option `force-warns` which will force the provided lints to warn even if they are allowed by some other mechanism such as `#![allow(warnings)]`.

Some remaining issues:
* https://github.com/rust-lang/rust/issues/85512 mentions that `force-warns` should also be capable of taking lint groups instead of individual lints. This is not implemented.
* If a lint has a higher warning level than `warn`, this will cause that lint to warn instead. We probably want to allow the lint to error if it is set to a higher lint and is not allowed somewhere else.
* One test is currently ignored because it's not working - when a deny-by-default lint is allowed, it does not currently warn under `force-warns`. I'm not sure why, but I wanted to get this in before the weekend.

r? `@nikomatsakis`
2021-06-04 13:31:51 +00:00
Joshua Nelson
76502deb53 Implement DepTrackingHash for Option through blanket impls instead of macros
This avoids having to add a new macro call for both the `Option` and the
type itself.
2021-06-04 08:46:59 -04:00
Ryan Levick
3b206b7a70 Force warn on lint groups as well 2021-06-02 17:09:07 +02:00
Tomasz Miąsko
c1f6495b8e Miscellaneous inlining improvements 2021-06-02 08:49:58 +02:00
Guillaume Gomez
2ffe87a434
Rollup merge of #85473 - infinity0:master, r=jackh726
fix split-debuginfo error message
2021-06-01 11:29:42 +02:00
bors
657bc01888 Auto merge of #85702 - Aaron1011:no-vec-sort, r=michaelwoerister
Don't sort a `Vec` before computing its `DepTrackingHash`

Previously, we sorted the vec prior to hashing, making the hash
independent of the original (command-line argument) order. However, the
original vec was still always kept in the original order, so we were
relying on the rest of the compiler always working with it in an
'order-independent' way.

This assumption was not being upheld by the `native_libraries` query -
the order of the entires in its result depends on the order of entries
in `Options.libs`. This lead to an 'unstable fingerprint' ICE when the
`-l` arguments were re-ordered.

This PR removes the sorting logic entirely. Re-ordering command-line
arguments (without adding/removing/changing any arguments) seems like a
really niche use case, and correctly optimizing for it would require
additional work. By always hashing arguments in their original order, we
can entirely avoid a cause of 'unstable fingerprint' errors.
2021-05-31 20:03:18 +00:00
bors
aab93ca37f Auto merge of #85559 - 12101111:sanitizer-crt-static, r=nagisa
Diagnose use sanitizers with crt-static

Fix: https://github.com/rust-lang/rust/issues/85459
2021-05-30 23:38:10 +00:00
bors
758c00ea40 Auto merge of #85362 - jsgf:fix-emit-metadata, r=estebank
Use command line metadata path if provided

If the command-line has `--emit metadata=some/path/libfoo.rmeta` then
use that.

Closes #85356

I couldn't find any existing tests for the `--emit TYPE=PATH` command line syntax, so I wasn't sure how to test this aside from ad-hoc manual testing. Is there a ui test type for "generated output file with expected name"?
2021-05-30 17:39:45 +00:00
bjorn3
d0ec85d3fb Merge CrateDisambiguator into StableCrateId 2021-05-30 12:51:34 +02:00
Jeremy Fitzhardinge
2835351feb Use command line metadata path if provided
If the command-line has `--emit metadata=some/path/libfoo.rmeta` then
use that.

Closes #85356
2021-05-28 22:24:24 -07:00
Ryan Levick
69a19bfd43 Initial support for force-warns 2021-05-28 18:19:59 +02:00
12101111
4376484439
Diagnose use sanitizers with crt-static 2021-05-29 00:15:28 +08:00
Aaron Hill
605513a513
Don't sort a Vec before computing its DepTrackingHash
Previously, we sorted the vec prior to hashing, making the hash
independent of the original (command-line argument) order. However, the
original vec was still always kept in the original order, so we were
relying on the rest of the compiler always working with it in an
'order-independent' way.

This assumption was not being upheld by the `native_libraries` query -
the order of the entires in its result depends on the order of entries
in `Options.libs`. This lead to an 'unstable fingerprint' ICE when the
`-l` arguments were re-ordered.

This PR removes the sorting logic entirely. Re-ordering command-line
arguments (without adding/removing/changing any arguments) seems like a
really niche use case, and correctly optimizing for it would require
additional work. By always hashing arguments in their original order, we
can entirely avoid a cause of 'unstable fingerprint' errors.
2021-05-25 22:11:39 -05:00
Guillaume Gomez
6b0b81b098
Rollup merge of #85361 - bjorn3:rustdoc_target_json_path_canonicalize, r=jyn514
Use TargetTriple::from_path in rustdoc

This fixes the problem reported in https://github.com/Rust-for-Linux/linux/pull/272 where rustdoc requires the absolute path of a target spec json instead of accepting a relative path like rustc.
2021-05-25 13:05:09 +02:00
bjorn3
f22a80890a Use parse_target_triple in rustdoc 2021-05-24 19:53:44 +02:00
Pietro Albini
9e22b844dd remove cfg(bootstrap) 2021-05-24 11:07:48 -04:00
Ximin Luo
96a5e6b01e fix split-debuginfo error message 2021-05-19 15:39:59 +01: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
17b60b8738 Auto merge of #83129 - LeSeulArtichaut:thir-unsafeck, r=nikomatsakis
Introduce the beginning of a THIR unsafety checker

This poses the foundations for the THIR unsafety checker, so that it can be implemented incrementally:
- implements a rudimentary `Visitor` for the THIR (which will definitely need some tweaking in the future)
- introduces a new `-Zthir-unsafeck` flag which tells the compiler to use THIR unsafeck instead of MIR unsafeck
- implements detection of unsafe functions
- adds revisions to the UI tests to test THIR unsafeck alongside MIR unsafeck

This uses a very simple query design, where bodies are unsafety-checked on a body per body basis. This however has some big flaws:
- the unsafety-checker builds the THIR itself, which means a lot of work is duplicated with MIR building constructing its own copy of the THIR
- unsafety-checking closures is currently completely wrong: closures should take into account the "safety context" in which they are created, here we are considering that closures are always a safe context

I had intended to fix these problems in follow-up PRs since they are always gated under the `-Zthir-unsafeck` flag (which is explicitely noted to be unsound).

r? `@nikomatsakis`
cc https://github.com/rust-lang/project-thir-unsafeck/issues/3 https://github.com/rust-lang/project-thir-unsafeck/issues/7
2021-05-13 10:49:29 +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
bors
ac923d94f8 Auto merge of #83610 - bjorn3:driver_cleanup, r=cjgillot
rustc_driver cleanup

Best reviewed one commit at a time.
2021-05-12 08:38:03 +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
LeSeulArtichaut
29780f43e2 Introduce the (WIP) THIR unsafety checker 2021-05-11 15:33:00 +02:00
LingMan
41779f60ec
Fix typo in variable name
All other sibling functions call this variable "slot", so "slote" was most likely a typo.
2021-05-11 01:17:08 +02:00
Guillaume Gomez
6ec1de7d4f
Rollup merge of #85152 - nagisa:target-search-rustlib, r=Mark-Simulacrum
Adjust target search algorithm for rustlib path

With this the concerns expressed in #83800 should be addressed.

r? `@Mark-Simulacrum`
2021-05-10 20:05:27 +02:00
Simonas Kazlauskas
b7c5599d22 Adjust target search algorithm for rustlib path
With this the concerns expressed in #83800 should be addressed.
2021-05-10 19:15:19 +03:00
Vadim Petrochenkov
273e0a2a05 rustc_session: Use Iterator::find instead of manual search 2021-05-10 14:52:31 +03:00
Vadim Petrochenkov
9d18d4df0e rustc_session: Move more option building code from the options! macro 2021-05-10 14:41:45 +03:00
bors
c55c26cb36 Auto merge of #83800 - xobs:impl-16351-nightly, r=nagisa
Add default search path to `Target::search()`

The function `Target::search()` accepts a target triple and returns a `Target` struct defining the requested target.

There is a `// FIXME 16351: add a sane default search path?` comment that indicates it is desirable to include some sort of default. This was raised in https://github.com/rust-lang/rust/issues/16351 which was closed without any resolution.

https://github.com/rust-lang/rust/pull/31117 was proposed, however that has platform-specific logic that is unsuitable for systems without `/etc/`.

This patch implements the suggestion raised in https://github.com/rust-lang/rust/issues/16351#issuecomment-180878193 where a `target.json` file may be placed in `$(rustc --print sysroot)/lib/rustlib/<target-triple>/target.json`. This allows shipping a toolchain distribution as a single file that gets extracted to the sysroot.
2021-05-09 22:01:26 +00:00
bors
7a2f446889 Auto merge of #83894 - nikic:newpm, r=nagisa
Improve support for NewPM

This adds various missing bits of support for NewPM and allows us to successfully run stage 2 tests with NewPM enabled.

This does not yet enable NewPM by default, as there are still known issue on LLVM 12 (such as a weak fat LTO pipeline). The plan is to make the switch after we update to LLVM 13.
2021-05-09 16:19:21 +00:00
Joshua Nelson
f25aa5767f Remove unused opt_span_warn function 2021-05-08 23:14:09 -04:00
Joshua Nelson
96509b4835 Make Diagnostic::span_fatal unconditionally raise an error
It had no callers which didn't immediately call `raise()`, and this
unifies the behavior with `Session`.
2021-05-08 23:12:04 -04:00
Nikita Popov
0318883cd6 Make -Z new-llvm-pass-manager an Option<bool>
To allow it to have an LLVM version dependent default.
2021-05-08 10:58:08 +02:00
Yuki Okushi
283ef86784
Rollup merge of #84815 - richkadel:coverage-docs-update-2021-05, r=tmandry
Update coverage docs and command line help

r? `@tmandry`
cc: `@wesleywiser`
2021-05-07 15:20:24 +09:00
Rich Kadel
f58a362d18 Update coverage docs and command line help 2021-05-06 12:20: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
Ralf Jung
b1e152c7e5
Rollup merge of #84803 - jyn514:duplicate-macros, r=petrochenkov
Reduce duplication in `impl_dep_tracking_hash` macros

Cherry-picked from https://github.com/rust-lang/rust/pull/84234 since it will be a while until it lands.
2021-05-05 17:52:22 +02: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
0407919083
Use RealFileName for Session::working_dir as it may also be remapped 2021-05-05 15:10:57 +01:00
Dylan DPC
966e9e2471
Rollup merge of #84072 - nagisa:target-family-two-the-movie, r=petrochenkov
Allow setting `target_family` to multiple values, and implement `target_family="wasm"`

As per the conclusion in [this thread](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Are.20we.20comfortable.20with.20adding.20an.20insta-stable.20cfg.28wasm.29.3F/near/233158441), this implements an ability to specify any number of `target_family` values, allowing for more flexible generic groups, or "families", to be created than just the OS-based unix/windows dichotomy.

cc https://github.com/rust-lang/reference/pull/1006
2021-05-03 00:32:40 +02:00
bjorn3
b5e049de08 Remove dummy_config 2021-05-02 17:59:48 +02:00
Joshua Nelson
d5bda3c4fe Fix nit in rustc_session::options 2021-05-02 10:08:08 -04:00