Commit Graph

20 Commits

Author SHA1 Message Date
Cameron Steffen
33b9b95305 Introduce get_diagnostic_name 2021-10-06 08:40:28 -05:00
Michael Woerister
d0be27c8ec Use on-disk-hash-table format for DefPathHashMap in hir::definitions. 2021-09-14 13:54:41 +02:00
Mark Rousskov
06661ba759 Update to new bootstrap compiler 2021-06-28 11:30:49 -04:00
bjorn3
312f964478 Remove unused feature gates 2021-05-31 13:55:43 +02:00
Jacob Pratt
bc2f0fb5a9
Specialize implementations
Implementations in stdlib are now optimized as they were before.
2021-05-26 18:07:09 -04:00
Pietro Albini
9e22b844dd remove cfg(bootstrap) 2021-05-24 11:07:48 -04:00
Joshua Nelson
e48b6b4599 Stabilize extended_key_value_attributes
# Stabilization report

 ## Summary

This stabilizes using macro expansion in key-value attributes, like so:

 ```rust
 #[doc = include_str!("my_doc.md")]
 struct S;

 #[path = concat!(env!("OUT_DIR"), "/generated.rs")]
 mod m;
 ```

See the changes to the reference for details on what macros are allowed;
see Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455)
for alternatives that were considered and rejected ("why accept no more
and no less?")

This has been available on nightly since 1.50 with no major issues.

 ## Notes

 ### Accepted syntax

The parser accepts arbitrary Rust expressions in this position, but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g., `#[doc]`).  Note that decorators and the like may be able to observe other expression forms.

 ### Expansion ordering

Expansion of macro expressions in "inert" attributes occurs after decorators have executed, analogously to macro expressions appearing in the function body or other parts of decorator input.

There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion, that can work).

 ## Test cases

 - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs
 - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs

The feature has also been dogfooded extensively in the compiler and
standard library:

- https://github.com/rust-lang/rust/pull/83329
- https://github.com/rust-lang/rust/pull/83230
- https://github.com/rust-lang/rust/pull/82641
- https://github.com/rust-lang/rust/pull/80534

 ## Implementation history

- Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412
- Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121
- Preliminary work to restrict expansion that would conflict with this
feature: https://github.com/rust-lang/rust/pull/77271
- Initial implementation: https://github.com/rust-lang/rust/pull/78837
- Fix for an ICE: https://github.com/rust-lang/rust/pull/80563

 ## Unresolved Questions

~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns, but they have been resolved as of this final report.~~

 ## Additional Information

 There are two workarounds that have a similar effect for `#[doc]`
attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons:

```rust
macro_rules! forward_inner_docs {
    ($e:expr => $i:item) => {
        #[doc = $e]
        $i
    };
}

forward_inner_docs!(include_str!("lib.rs") => struct S {});
```

This also works for other attributes (like `#[path = concat!(...)]`).
The other is to use `doc(include)`:

```rust
 #![feature(external_doc)]
 #[doc(include = "lib.rs")]
 struct S {}
```

The first works, but is non-trivial for people to discover, and
difficult to read and maintain. The second is a strange special-case for
a particular use of the macro. This generalizes it to work for any use
case, not just including files.

I plan to remove `doc(include)` when this is stabilized. The
`forward_inner_docs` workaround will still compile without warnings, but
I expect it to be used less once it's no longer necessary.
2021-05-18 01:01:36 -04:00
Ralf Jung
bd9556956a fix feature use in rustc libs 2021-04-18 22:05:45 +02:00
mark
db5629adcb stabilize or_patterns 2021-03-19 19:45:32 -05:00
bors
04fce73196 Auto merge of - camelid:lang-item-docs, r=jyn514
Improve lang item generated docs

cc https://rust-lang.zulipchat.com/#narrow/stream/146229-wg-secure-code/topic/Is.20.60core.60.20part.20of.20the.20compiler.3F/near/226738260

r? `@jyn514`
2021-03-11 06:38:22 +00:00
bors
76c500ec6c Auto merge of - 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
Camelid
da0099a9ff Enable extended_key_value_attributes in rustc_hir 2021-02-28 11:56:16 -08:00
Michael Woerister
9e5054498b Add unit test to ensure that both parts of a DefPathHash depend on the defining crate's ID. 2021-02-04 16:33:58 +01:00
Mara Bos
24e0940169 Stabilize feature(iterator_fold_self): Iterator::reduce 2021-02-04 11:31:11 +01:00
Jonas Schievink
1e99f26894
Rollup merge of - SimonSapin:array-intoiter-type, r=m-ou-se
Stabilize by-value `[T; N]` iterator `core::array::IntoIter`

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

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

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

`new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then, although it will stay stable.
2021-01-31 01:47:25 +01:00
Patryk Wychowaniec
d2f8e398f1
Rework diagnostics for wrong number of generic args 2021-01-10 13:07:40 +01:00
Simon Sapin
61c49d4042 Stabilize by-value [T; N] iterator core::array::IntoIter
Tracking issue: https://github.com/rust-lang/rust/issues/65798

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

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

`new` would become unnecessary when `IntoIterator` is implemented
and might be deprecated then, although it will stay stable.
2020-12-29 09:16:46 +01:00
Joshua Nelson
3797f29aad [WIP] give better errors for broken intra doc links 2020-09-05 13:48:19 -04:00
marmeladema
67b8f9491c hir: replace lazy_static by SyncLazy from std 2020-09-01 22:06:47 +01:00
mark
9e5f7d5631 mv compiler to compiler/ 2020-08-30 18:45:07 +03:00