| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Fix doc link
Result of first searching via:
find src -type f -exec fgrep -l dynamically-sized-types--sized {} \;
and then replacing all relevant occurrences via:
find src/{libcore,test/ui} -type f -exec sed -i.bak \
s/dynamically-sized-types--sized/dynamically-sized-types-and-sized/g {} \;
find src -type f -name '*.bak' -exec rm {} \;
(Note: Commands run on macOS 10.13 (BSD). `sed -i.bak` should work on
GNU/Linux as well, but not tested.)
EDIT: Did not compile / test Rust for this change at all.
Clickable links for comparison:
https://doc.rust-lang.org/book/second-edition/ch19-04-advanced-types.html#dynamically-sized-types--sized (broken)
https://doc.rust-lang.org/book/second-edition/ch19-04-advanced-types.html#dynamically-sized-types-and-sized (fixed)
|
|
The link for comparison:
- https://doc.rust-lang.org/book/second-edition/ch19-04-advanced-types.html#dynamically-sized-types--sized (broken)
- https://doc.rust-lang.org/book/second-edition/ch19-04-advanced-types.html#dynamically-sized-types-and-sized (fixed)
This commit is the result of (first) searching via:
find src -type f -print0 | xargs -0 fgrep -l dynamically-sized-types--sized
and then replacing all relevant occurrences via:
find src/{libcore,test/ui} -type f -print0 | xargs -0 sed -i.bak \
s/dynamically-sized-types--sized/dynamically-sized-types-and-sized/g
find src/{libcore,test/ui} -type f -name '*.bak' -print0 | xargs -0 rm
(Note: Commands run on macOS 10.13 (BSD). `sed -i.bak` should work on
GNU/Linux as well, but not tested.)
|
|
r=QuietMisdreavus
Pass edition flags to compiler from rustdoc as expected
Fixes #52357.
|
|
Move some `compile-fail` tests to `ui`
Re: #44844.
|
|
|
|
rustc: Stabilize the `proc_macro` feature
This commit stabilizes some of the `proc_macro` language feature as well as a
number of APIs in the `proc_macro` crate as [previously discussed][1]. This
means that on stable Rust you can now define custom procedural macros which
operate as attributes attached to items or `macro_rules!`-like bang-style
invocations. This extends the suite of currently stable procedural macros,
custom derives, with custom attributes and custom bang macros.
Note though that despite the stabilization in this commit procedural macros are
still not usable on stable Rust. To stabilize that we'll need to stabilize at
least part of the `use_extern_macros` feature. Currently you can define a
procedural macro attribute but you can't import it to call it!
A summary of the changes made in this PR (as well as the various consequences)
is:
* The `proc_macro` language and library features are now stable.
* Other APIs not stabilized in the `proc_macro` crate are now named under a
different feature, such as `proc_macro_diagnostic` or `proc_macro_span`.
* A few checks in resolution for `proc_macro` being enabled have switched over
to `use_extern_macros` being enabled. This means that code using
`#![feature(proc_macro)]` today will likely need to move to
`#![feature(use_extern_macros)]`.
It's intended that this PR, once landed, will be followed up with an attempt to
stabilize a small slice of `use_extern_macros` just for procedural macros to
make this feature 100% usable on stable.
[1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252
|
|
This commit stabilizes some of the `proc_macro` language feature as well as a
number of APIs in the `proc_macro` crate as [previously discussed][1]. This
means that on stable Rust you can now define custom procedural macros which
operate as attributes attached to items or `macro_rules!`-like bang-style
invocations. This extends the suite of currently stable procedural macros,
custom derives, with custom attributes and custom bang macros.
Note though that despite the stabilization in this commit procedural macros are
still not usable on stable Rust. To stabilize that we'll need to stabilize at
least part of the `use_extern_macros` feature. Currently you can define a
procedural macro attribute but you can't import it to call it!
A summary of the changes made in this PR (as well as the various consequences)
is:
* The `proc_macro` language and library features are now stable.
* Other APIs not stabilized in the `proc_macro` crate are now named under a
different feature, such as `proc_macro_diagnostic` or `proc_macro_span`.
* A few checks in resolution for `proc_macro` being enabled have switched over
to `use_extern_macros` being enabled. This means that code using
`#![feature(proc_macro)]` today will likely need to move to
`#![feature(use_extern_macros)]`.
It's intended that this PR, once landed, will be followed up with an attempt to
stabilize a small slice of `use_extern_macros` just for procedural macros to
make this feature 100% usable on stable.
[1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252
|
|
|
|
Revert #52266
Reverts #52266 until the performance issues with that PR are ironed out.
|
|
structured suggestion for renamed-and-removed-lints
r? @estebank
|
|
This reverts commit 2c5cd9ce53d2d25041db0cb02b40ba460ffa8908.
|
|
This reverts commit 94b32adb71a75a3f5b53a39c52c62c2ce1a7cc56.
|
|
This reverts commit dd3f445ed264ffc09ea42bd8d89853242e3a26f4.
|
|
|
|
|
|
CTFE: use binary_op to compare integer with match disriminant
This is needed to unblock https://github.com/solson/miri/pull/401: There is code in the Windows initialization functions that uses `match` to test whether a pointer is NULL.
I will add a testcase in miri; I was not sure where to add a testcase in Rust itself.
r? @oli-obk
|
|
resolve: Functions introducing procedural macros reserve a slot in the macro namespace as well
Similarly to https://github.com/rust-lang/rust/pull/52234, this gives us symmetry between internal and external views of a crate, but in this case it's always an error to call a procedural macro in the same crate in which it's defined.
Closes https://github.com/rust-lang/rust/issues/52225
|
|
|
|
|
|
|
|
rustdoc: don't panic when the cross-re-export handler sees a proc-macro
When i moved the macro cross-re-export inlining code into `clean::inline`, i thought that if a macro had a `Def` that said it was a bang macro, it wouldn't be a proc macro. I thought wrong. Turns out, the `quote!()` in `libproc_macro` is actually a proc-macro, and when the `quote!()` macro is re-exported, this proc-macro is accessed in its place. This causes any `proc_macro::*` glob re-export to pull in this proc-macro, causing the assertion i added to fire, leading to an ICE. This replaces that with an Option that ignores proc-macros for the time being.
Fixes https://github.com/rust-lang/rust/issues/52129
|
|
|
|
Reach the body of functions returning `impl Trait` but don't treat it as public
fixes #52128
r? @pnkfelix
cc @eddyb
|
|
Removed the promotable field from CheckCrateVisitor...
and replaced it with the custom enum Promotability.
r? @oli-obk
|
|
structs Promotable and NotPromotable.
|
|
rustc: Tweak expansion of #[proc_macro] for 2018
The syntactical expansion of `#[proc_macro]` and related attributes currently
contains absolute paths which conflicts with a lint for the 2018 edition,
causing issues like #52214. This commit puts a band-aid on the issue by ensuring
that procedural macros can also migrate to the 2018 edition for now by tweaking
the expansion based on what features are activated. A more long-term solution
would probably tweak the edition hygiene of spans, but this should do the trick
for now.
Closes #52214
|
|
|
|
namespace as well
|
|
|
|
Don't display default generic parameters in diagnostics that compare types
In errors like:
```
expected type: `RawVec<foo, Global>`
found type: `foo`
```
`RawVec` being defined as `RawVec<T, A: Alloc = Global>`, the error is better written as
```
expected type: `RawVec<foo>`
found type: `foo`
```
In fact, that is already what happens when `foo` is not an ADT, because in that case, the diagnostic handler doesn't try to highlight something, and just uses the `Display` trait instead of its own logic.
e.g.
```
expected type: `RawVec<usize>`
found type: `usize`
```
|
|
proc_macro: Fix crate root detection
Fixes https://github.com/rust-lang/rust/issues/52270
|
|
|
|
Fix ICE when using a pointer cast as array size
Fixes #52023. I'm not sure if the comment https://github.com/rust-lang/rust/issues/52023#issuecomment-402402392 suggested we also emit `E0080`, but just emitting `E0018` seems reasonable for now.
r? @oli-obk
|
|
Add the `amdgpu-kernel` ABI.
Technically, there are requirements imposed by the LLVM
`AMDGPUTargetMachine` on functions with this ABI (eg, the return type
must be void), but I'm unsure exactly where this should be enforced.
|
|
Technically, there are requirements imposed by the LLVM
`AMDGPUTargetMachine` on functions with this ABI (eg, the return type
must be void), but I'm unsure exactly where this should be enforced.
|
|
r=alexcrichton
Preliminary work for incremental ThinLTO.
Since implementing incremental ThinLTO is a bit more involved than I initially thought, I'm splitting out some of the things that already work. This PR (1) adds a way accessing some ThinLTO information in `rustc` and (2) does some cleanup around CGU/object file naming (which makes things quite a bit nicer).
This is probably best reviewed one commit at a time.
|
|
Rollup of 17 pull requests
Successful merges:
- #51962 (Provide llvm-strip in llvm-tools component)
- #52003 (Implement `Option::replace` in the core library)
- #52156 (Update std::ascii::ASCIIExt deprecation notes)
- #52280 (llvm-tools-preview: fix build-manifest)
- #52290 (Deny bare trait objects in src/librustc_save_analysis)
- #52293 (Deny bare trait objects in librustc_typeck)
- #52299 (Deny bare trait objects in src/libserialize)
- #52300 (Deny bare trait objects in librustc_target and libtest)
- #52302 (Deny bare trait objects in the rest of rust)
- #52310 (Backport 1.27.1 release notes to master)
- #52315 (Resolve FIXME(#27942))
- #52316 (task: remove wrong comments about non-existent LocalWake trait)
- #52322 (Update llvm-rebuild-trigger in light of LLVM 7 upgrade)
- #52330 (Don't silently ignore invalid data in target spec)
- #52333 (CI: Enable core dump on Linux, and print their stack trace on segfault. )
- #52346 (Fix typo in improper_ctypes suggestion)
- #52350 (Bump bootstrap compiler to 1.28.0-beta.10)
Failed merges:
r? @ghost
|
|
Fix typo in improper_ctypes suggestion
closes #52345
|
|
Don't silently ignore invalid data in target spec
This is technically a breaking change, but only because invalid data was previously silently being ignored.
|
|
|
|
|
|
NLL: Suggest `ref mut` and `&mut self`
Fixes #51244. Supersedes #51249, I think.
Under the old lexical lifetimes, the compiler provided helpful suggestions about adding `mut` when you tried to mutate a variable bound as `&self` or (explicit) `ref`. NLL doesn't have those suggestions yet. This pull request adds them.
I didn't bother making the help text exactly the same as without NLL, but I can if that's important.
(Originally this was supposed to be part of #51612, but I got bogged down trying to fit everything in one PR.)
|
|
The syntactical expansion of `#[proc_macro]` and related attributes currently
contains absolute paths which conflicts with a lint for the 2018 edition,
causing issues like #52214. This commit puts a band-aid on the issue by ensuring
that procedural macros can also migrate to the 2018 edition for now by tweaking
the expansion based on what features are activated. A more long-term solution
would probably tweak the edition hygiene of spans, but this should do the trick
for now.
Closes #52214
|
|
closes #52345
|
|
nll experiment: compute SCCs instead of iterative region solving
This is an attempt to speed up region solving by replacing the current iterative dataflow with a SCC computation. The idea is to detect cycles (SCCs) amongst region constraints and then compute just one value per cycle. The graph with all cycles removed is of course a DAG, so we can then solve constraints "bottom up" once the liveness values are known.
I kinda ran out of time this morning so the last commit is a bit sloppy but I wanted to get this posted, let travis run on it, and maybe do a perf run, before I clean it up.
|
|
Change RangeInclusive to a three-field struct.
Fix #45222.
This PR also reverts #48012 (i.e. removed the `try_fold`/`try_rfold` specialization for `RangeInclusive`) because LLVM no longer has trouble recognizing a RangeInclusive loop.
|
|
|
