Eliminate the `SessionGlobals` from `librustc_ast`.
By moving `{known,used}_attrs` from `SessionGlobals` to `Session`. This
means they are accessed via the `Session`, rather than via TLS. A few
`Attr` methods and `librustc_ast` functions are now methods of
`Session`.
All of this required passing a `Session` to lots of functions that didn't
already have one. Some of these functions also had arguments removed, because
those arguments could be accessed directly via the `Session` argument.
`contains_feature_attr()` was dead, and is removed.
Some functions were moved from `librustc_ast` elsewhere because they now need
to access `Session`, which isn't available in that crate.
- `entry_point_type()` --> `librustc_builtin_macros`
- `global_allocator_spans()` --> `librustc_metadata`
- `is_proc_macro_attr()` --> `Session`
bors [Sat, 8 Aug 2020 00:00:52 +0000 (00:00 +0000)]
Auto merge of #75048 - eggyal:force-no-tco-start-backtrace-frame, r=Mark-Simulacrum
Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away
I've stumbled across some situations where there (unexpectedly) was no `__rust_begin_short_backtrace` frame on the stack during unwinding.
On closer examination, it appeared that the calls to that function had been tail-call optimised away.
This PR follows [@bjorn3's suggestion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Disabling.20tail.20call.20optimisation.3F/near/205699133), by adding calls to `black_box` that hint to rustc not to perform TCO.
bors [Fri, 7 Aug 2020 17:57:30 +0000 (17:57 +0000)]
Auto merge of #75255 - davidtwco:polymorphisation-symbol-mangling-v0-upvar-closures, r=lcnr
instance: polymorphize upvar closures/generators
This PR modifies how instances are polymorphized so that closures and generators have any closures or generators captured within their upvars also polymorphized.
With the new symbol mangling, a fully polymorphised closure will produce the same symbol regardless of what it was instantiated with. However, when that polymorphised closure captures another closure as an upvar, then the type of that other closure in the upvar substitution wouldn't have been polymorphised. The other closure will still refer to the initial substitutions. Therefore, the polymorphised closure will end up hashing differently but producing the same symbol - triggering `assert_symbols_are_distinct` in MIR partitioning. The old mangling scheme had a hash at the end that meant this didn't happen (this would still have been an issue, we just didn't have a way to notice).
See [this Zulip discussion for further elaboration](https://rust-lang.zulipchat.com/#narrow/stream/216091-t-compiler.2Fwg-polymorphization/topic/symbol.20mangling.20v0.20.E2.9C.95.20polymorphisation/near/206152008).
David Wood [Fri, 7 Aug 2020 16:50:45 +0000 (17:50 +0100)]
ty: add `MAY_POLYMORPHIZE` flag
This commit adds a `MAY_POLYMORPHIZE` which checks for closures and
generators so that polymorphization of substs does not need to traverse
every substs.
David Wood [Fri, 7 Aug 2020 16:11:16 +0000 (17:11 +0100)]
instance: always polymorphize substs
By always polymorphizing substitutions, functions which take closures as
arguments (e.g. `impl Fn()`) can have fewer mono items when some of the
argument closures can be polymorphized.
David Wood [Fri, 7 Aug 2020 11:28:52 +0000 (12:28 +0100)]
instance: polymorphize upvar closures/generators
This commit modifies how instances are polymorphized so that closures
and generators have any closures or generators captured within their
upvars also polymorphized - this avoids symbol clashes with the new
symbol mangling scheme.
bors [Fri, 7 Aug 2020 13:29:25 +0000 (13:29 +0000)]
Auto merge of #74627 - petrochenkov:docbeauty2, r=Aaron1011
rustc_ast: Stop using "string typing" for doc comment tokens
Explicitly store their kind and style retrieved during lexing in the `token::DocComment`.
Also don't "beautify" doc comments before converting them to `#[doc]` attributes when passing them to macros (both declarative and procedural).
The trimming of empty lines, lines containing only `*`s, etc is purely a rustdoc's job as a part of its presentation of doc strings to users, rustc must not do this and must pass tokens as precisely as possible internally.
bors [Fri, 7 Aug 2020 08:36:15 +0000 (08:36 +0000)]
Auto merge of #70052 - Amanieu:hashbrown7, r=Mark-Simulacrum
Update hashbrown to 0.8.1
This update includes:
- https://github.com/rust-lang/hashbrown/pull/146, which improves the performance of `Clone` and implements `clone_from`.
- https://github.com/rust-lang/hashbrown/pull/159, which reduces the size of `HashMap` by 8 bytes.
- https://github.com/rust-lang/hashbrown/pull/162, which avoids creating small 1-element tables.
bors [Fri, 7 Aug 2020 06:40:53 +0000 (06:40 +0000)]
Auto merge of #75244 - Manishearth:rollup-dzfyjva, r=Manishearth
Rollup of 4 pull requests
Successful merges:
- #74774 (adds [*mut|*const] ptr::set_ptr_value)
- #75079 (Disallow linking to items with a mismatched disambiguator)
- #75203 (Make `IntoIterator` lifetime bounds of `&BTreeMap` match with `&HashMap` )
- #75227 (Fix ICE when using asm! on an unsupported architecture)
Rollup merge of #75203 - canova:btreemap-into-iter, r=dtolnay
Make `IntoIterator` lifetime bounds of `&BTreeMap` match with `&HashMap`
This is a pretty small change on the lifetime bounds of `IntoIterator` implementations of both `&BTreeMap` and `&mut BTreeMap`. This is loosening the lifetime bounds, so more code should be accepted with this PR. This is lifetime bounds will still be implicit since we have `type Item = (&'a K, &'a V);` in the implementation. This change will make the HashMap and BTreeMap share the same signature, so we can share the same function/trait with both HashMap and BTreeMap in the code.
Fixes #74034.
r? @dtolnay hey, I was touching this file on my previous PR and wanted to fix this on the way. Would you mind taking a look at this, or redirecting it if you are busy?
Rollup merge of #74774 - oliver-giersch:set_data_ptr, r=dtolnay
adds [*mut|*const] ptr::set_ptr_value
I propose the addition of these two functions to `*mut T` and `*const T`, respectively. The motivation for this is primarily byte-wise pointer arithmetic on (potentially) fat pointers, i.e. for types with a `T: ?Sized` bound. A concrete use-case has been discussed in [this](https://internals.rust-lang.org/t/byte-wise-fat-pointer-arithmetic/12739) thread.
TL;DR: Currently, byte-wise pointer arithmetic with potentially fat pointers in not possible in either stable or nightly Rust without making assumptions about the layout of fat pointers, which is currently still an implementation detail and not formally stabilized. This PR adds one function to `*mut T` and `*const T` each, allowing to circumvent this restriction without exposing any internal implementation details.
One possible alternative would be to add specific byte-wise pointer arithmetic functions to the two pointer types in addition to the already existing count-wise functions. However, I feel this fairly niche use case does not warrant adding a whole set of new functions like `add_bytes`, `offset_bytes`, `wrapping_offset_bytes`, etc. (times two, one for each pointer type) to `libcore`.
Yuki Okushi [Fri, 7 Aug 2020 00:35:24 +0000 (09:35 +0900)]
Rollup merge of #75210 - nnethercote:change-type-of-available_cgus, r=ecstatic-morse
Change the type of `AssertModuleSource::available_cgus`.
It's currently a `BTreeSet<Symbol>`, which is a strange type. The
`BTreeSet` suggests that element order is important, but `Symbol` is a
type whose ordering isn't useful to humans. The ordering of the
collection only manifests in an obscure error message ("no module named
`...`") that doesn't appear in any tests.
This commit changes the `Symbol` to a `String`, which is more
typical.
Joshua Nelson [Thu, 6 Aug 2020 22:11:47 +0000 (18:11 -0400)]
Use the proper kind for associated items
See comments in the diff; this is such a hack.
The reason this can't be done properly in `register_res` is because
there's no way to get back the parent type: calling
`tcx.parent(assoc_item)` gets you the _impl_, not the type.
You can call `tcx.impl_trait_ref(impl_).self_ty()`, but there's no way
to go from that to a DefId without unwrapping.
Change the type of `AssertModuleSource::available_cgus`.
It's currently a `BTreeSet<Symbol>`, which is a strange type. The
`BTreeSet` suggests that element order is important, but `Symbol` is a
type whose ordering isn't useful to humans. The ordering of the
collection only manifests in an obscure error message ("no module named
`...`") that doesn't appear in any tests.
This commit changes the `Symbol` to a `String`, which is more
typical.
bors [Thu, 6 Aug 2020 12:12:59 +0000 (12:12 +0000)]
Auto merge of #74889 - JohnTitor:hrtb-tests, r=nikomatsakis
Add HRTB-related regression test
Closes #59311 and cc #71546
This closes the former but the test is taken from https://github.com/rust-lang/rust/issues/71546#issuecomment-620638437 since it seems they have the same cause and it's simplified.
bors [Thu, 6 Aug 2020 03:23:57 +0000 (03:23 +0000)]
Auto merge of #75008 - eddyb:rmeta-indexed-trait-impls, r=nikomatsakis
rustc_metadata: track the simplified Self type for every trait impl.
For the `traits_impls_of` query, we index the impls by `fast_reject::SimplifiedType` (a "shallow type"), which allows some simple cases like `impl Trait<..> for Foo<..>` to be efficiently iterated over, by e.g. `for_each_relevant_impl`.
This PR encodes the `fast_reject::SimplifiedType` cross-crate to avoid needing to deserialize the `Self` type of every `impl` in order to simplify it - the simplification itself should be cheap, but the deserialization is less so.
We could go further from here and make loading the list of impls lazy, for a given simplified `Self` type, but that would have more complicated implications for performance, and this PR doesn't do anything in that regard.
bors [Wed, 5 Aug 2020 17:58:55 +0000 (17:58 +0000)]
Auto merge of #75005 - adamreichold:limit-vector-count, r=Amanieu
Limit I/O vector count on Unix
Unix systems enforce limits on the vector count when performing vectored I/O via the readv and writev system calls and return EINVAL when these limits are exceeded. This changes the standard library to handle those limits as short reads and writes to avoid forcing its users to query these limits using platform specific mechanisms.
bors [Wed, 5 Aug 2020 16:08:53 +0000 (16:08 +0000)]
Auto merge of #75194 - Aaron1011:feature/macro-backtrace-numbers, r=eddyb
Show backtrace numbers in backtrace whenever more than one is involved
Previously, we only displayed 'frame' numbers in a macro backtrace when more
than two frames were involved. This commit should help make backtrace
more readable, since these kinds of messages can quickly get confusing.
Aaron Hill [Wed, 5 Aug 2020 15:02:25 +0000 (11:02 -0400)]
Show backtrace numbers in backtrace whenever more than one is involved
Previously, we only displayed 'frame' numbers in a macro backtrace when more
than two frames were involved. This commit should help make backtrace
more readable, since these kinds of messages can quickly get confusing.
Adam Reichold [Sat, 1 Aug 2020 14:06:00 +0000 (16:06 +0200)]
Rely only on POSIX semantics for I/O vector count
All #[cfg(unix)] platforms follow the POSIX standard and define _SC_IOV_MAX so
that we rely purely on POSIX semantics to determine the limits on I/O vector
count.
Adam Reichold [Sat, 1 Aug 2020 12:29:42 +0000 (14:29 +0200)]
Memoize the I/O vector count limit
Keep the I/O vector count limit in a `SyncOnceCell` to avoid the overhead of
repeatedly calling `sysconf` as these limits are guaranteed to not change during
the lifetime of a process by POSIX.
Adam Reichold [Sat, 1 Aug 2020 12:18:11 +0000 (14:18 +0200)]
Query maximum vector count on Linux and macOS
Both Linux and MacOS enforce limits on the vector count when performing vectored
I/O via the readv and writev system calls and return EINVAL when these limits
are exceeded. This changes the standard library to handle those limits as short
reads and writes to avoid forcing its users to query these limits using
platform specific mechanisms.
bors [Wed, 5 Aug 2020 06:55:42 +0000 (06:55 +0000)]
Auto merge of #75155 - davidtwco:polymorphization-incr-comp-optimisations, r=lcnr
polymorphization: various improvements
This PR includes a handful of polymorphisation-related changes:
- @Mark-Simulacrum's suggestions [from this comment](https://github.com/rust-lang/rust/pull/74633#issuecomment-668684433):
- Use a `FiniteBitSet<u32>` over a `FiniteBitSet<u64>` as most functions won't have 64 generic parameters.
- Don't encode polymorphisation results in metadata when every parameter is used (in this case, just invoking polymorphisation will probably be quicker).
- @lcnr's suggestion [from this comment](https://github.com/rust-lang/rust/pull/74717#discussion_r463690015).
- Add an debug assertion in `ensure_monomorphic_enough` to make sure that polymorphisation did what we expect.
bors [Wed, 5 Aug 2020 05:08:19 +0000 (05:08 +0000)]
Auto merge of #75037 - richkadel:llvm-coverage-map-gen-5.2, r=wesleywiser
Completes support for coverage in external crates
Follow-up to #74959 :
The prior PR corrected for errors encountered when trying to generate
the coverage map on source code inlined from external crates (including
macros and generics) by avoiding adding external DefIds to the coverage
map.
This made it possible to generate a coverage report including external
crates, but the external crate coverage was incomplete (did not include
coverage for the DefIds that were eliminated.
The root issue was that the coverage map was converting Span locations
to source file and locations, using the SourceMap for the current crate,
and this would not work for spans from external crates (compliled with a
different SourceMap).
The solution was to convert the Spans to filename and location during
MIR generation instead, so precompiled external crates would already
have the correct source code locations embedded in their MIR, when
imported into another crate.
bors [Wed, 5 Aug 2020 03:04:21 +0000 (03:04 +0000)]
Auto merge of #75174 - JohnTitor:rollup-z9djftk, r=JohnTitor
Rollup of 5 pull requests
Successful merges:
- #75139 (Remove log alias from librustdoc)
- #75140 (Clean up E0745)
- #75149 (Correct a typo in interpret/memory.rs)
- #75152 (Replace `Memoryblock` with `NonNull<[u8]>`)
- #75168 (Update books)
Lzu Tao [Wed, 5 Aug 2020 02:49:26 +0000 (02:49 +0000)]
Use u32::from_ne_bytes to fix a FIXME
Co-authored-by: Weiyi Wang <wwylele@gmail.com> Co-authored-by: Adam Reichold <adam.reichold@t-online.de> Co-authored-by: Josh Stone <cuviper@gmail.com> Co-authored-by: Scott McMurray <scottmcm@users.noreply.github.com> Co-authored-by: tmiasko <tomasz.miasko@gmail.com>
Yuki Okushi [Wed, 5 Aug 2020 02:40:11 +0000 (11:40 +0900)]
Rollup merge of #75168 - ehuss:update-books, r=ehuss
Update books
## reference
7 commits in b329ce37424874ad4db94f829a55807c6e21d2cb..c9b2736a059469043177e1e4ed41a55d7c63ac28
2020-07-20 08:54:08 -0700 to 2020-08-03 03:34:03 -0700
- Fix documented build output path. (rust-lang-nursery/reference#870)
- Update token usage table. (rust-lang-nursery/reference#868)
- Allow trait inner attributes (rust-lang-nursery/reference#864)
- patterns.md - add word "underscore" to _ paragraph (rust-lang-nursery/reference#865)
- Drive-by mention unsafe fn closure coercion (rust-lang-nursery/reference#802)
- grammar: Change "For awhile" to "For a while" (rust-lang-nursery/reference#857)
- Added Unpin to list of Auto Traits (rust-lang-nursery/reference#854)
## book
7 commits in a914f2c7e5cdb771fa465de142381a51c53b580e..363293c1c5ce9e84ea3935a5e29ce8624801208a
2020-07-21 09:20:05 -0500 to 2020-08-03 15:56:30 -0500
- replace commas with m-dashes to improve readability of chapter 4.1 (rust-lang/book#2419)
- Update TOML link to official website (rust-lang/book#2411)
- Add github repo link (rust-lang/book#2265)
- Remove the version number entirely so we can stop updating it
- Add link to the `Vec<T>` API documentation (rust-lang/book#2249)
- link to stdlib atomic docs (rust-lang/book#2361)
- mdbook version used is now 0.4.x (rust-lang/book#2410)
`run()` returns `Result<(), String>`. But on failure it always returns
an empty string, and then `wrap_return()` treats an empty string
specially, by not reporting the error.
It turns out we already have the `ErrorReported` type for this sort of
behaviour. This commit changes `run()` to use it.