| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Reuse CrateNum for proc-macro crates even when cross-compiling
Proc-macros are always compiled for the host, so this should be the same
in every way as recompiling the crate.
I am not sure why the previous code special-cased the target, since the
compiler properly gives an error when trying to load a crate for a
different host:
```
error[E0461]: couldn't find crate `dependency` with expected target triple x86_64-unknown-linux-gnu
--> /home/joshua/rustc4/src/test/ui/cfg-dependent.rs:8:2
|
LL | dependency::is_64();
| ^^^^^^^^^^
|
= note: the following crate versions were found:
crate `dependency`, target triple i686-unknown-linux-gnu: /home/joshua/rustc4/build/x86_64-unknown-linux-gnu/test/ui/cfg-dependent/auxiliary/libdependency.so
```
I think another possible fix is to remove the check altogether. But I'm
not sure, and this fix works, so I'm not making the larger change here.
Fixes https://github.com/rust-lang/rust/issues/56935.
r? `@petrochenkov` cc `@alexcrichton`
|
|
Proc-macros are always compiled for the host, so this should be the same
in every way as recompiling the crate.
I am not sure why the previous code special-cased the target, since the
compiler properly gives an error when trying to load a crate for a
different host:
```
error[E0461]: couldn't find crate `dependency` with expected target triple x86_64-unknown-linux-gnu
--> /home/joshua/rustc4/src/test/ui/cfg-dependent.rs:8:2
|
LL | dependency::is_64();
| ^^^^^^^^^^
|
= note: the following crate versions were found:
crate `dependency`, target triple i686-unknown-linux-gnu: /home/joshua/rustc4/build/x86_64-unknown-linux-gnu/test/ui/cfg-dependent/auxiliary/libdependency.so
```
I think another possible fix is to remove the check altogether. But I'm
not sure, and this fix works, so I'm not making the larger change here.
|
|
Rollup of 6 pull requests
Successful merges:
- #87027 (expand: Support helper attributes for built-in derive macros)
- #87056 (Fix codeblocks overflow)
- #87117 (Shrink the CrateStore dynamic interface.)
- #87120 (rustdoc: Remove unnecessary `extern crate` aliases)
- #87125 (Fix Ayu theme `<code>` color)
- #87130 (Update browser-ui-test package version)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=Mark-Simulacrum
Update browser-ui-test package version
It adds a check to prevent to have empty CSS values in `assert-css` command.
r? `@Mark-Simulacrum`
|
|
Fix Ayu theme <code> color
Fixes #87072 (the second regression).
r? `@notriddle`
|
|
rustdoc: Remove unnecessary `extern crate` aliases
|
|
Fix codeblocks overflow
Fixes #87043.
Instead of completely relying on `pulldown-cmark` (and its potential changes), I decided to move the generation of codeblocks HTML directly in rustdoc so we can unify the DOM and the CSS classes.
r? `@Nemo157`
|
|
expand: Support helper attributes for built-in derive macros
This is needed for https://github.com/rust-lang/rust/pull/86735 (derive macro `Default` should have a helper attribute `default`).
With this PR we can specify helper attributes for built-in derives using syntax `#[rustc_builtin_macro(MacroName, attributes(attr1, attr2, ...))]` which mirrors equivalent syntax for proc macros `#[proc_macro_derive(MacroName, attributes(attr1, attr2, ...))]`.
Otherwise expansion infra was already ready for this.
The attribute parsing code is shared between proc macro derives and built-in macros (`fn parse_macro_name_and_helper_attrs`).
|
|
r=oli-obk,wesleywiser
Handle non-integer const generic parameters in debuginfo type names.
This PR fixes an ICE introduced by https://github.com/rust-lang/rust/pull/85269 which started emitting const generic arguments for debuginfo names but did not cover the case where such an argument could not be evaluated to a flat string of bits.
The fix implemented in this PR is very basic: If `try_eval_bits()` fails for the constant in question, we fall back to generating a stable hash of the constant and emit that instead. This way we get a (virtually) unique name and side step the problem of generating a string representation of a potentially complex value.
The downside is that the generated name will be rather opaque. E.g. the regression test adds a function `const_generic_fn_non_int<()>` which is then rendered as `const_generic_fn_non_int<{CONST#fe3cfa0214ac55c7}>`. I think it's an open question how to deal with this more gracefully.
I'd be interested in ideas on how to do this better.
r? `@wesleywiser`
cc `@dpaoliello` (do you see any problems with this approach?)
cc `@Mark-Simulacrum` & `@nagisa` (who I've seen comment on debuginfo issues recently -- anyone else?)
Fixes https://github.com/rust-lang/rust/issues/86893
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is leftover from when `doctest` used to be called `test`. Remove it
now, it's unnecessary and makes the code harder to read.
|
|
r=Manisheart,notriddle
Add GUI test for "go to first" feature
It adds a test for #85876 to ensure the feature is working as expected and prevent potential regression.
cc ```@jeanlucthumm```
r? ```@Manishearth```
|
|
Suggest a path separator if a stray colon is found in a match arm
Attempts to fix #87086.
r? `@estebank`
|
|
Upgrade `cc` crate to 1.0.69
This pulls another fix for #83043, i.e., alexcrichton/cc-rs#605.
r? ``@alexcrichton``
|
|
Unignore some pretty printing tests
Closes #37201
r? ````@petrochenkov````
|
|
Search result colors
Part of #87072 (fixes the first and fourth regressions and add tests to prevent it from happening again).
cc ````@Nemo157````
r? ````@camelid````
|
|
Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com>
|
|
|
|
|
|
Fix internal `default_hash_types` lint to use resolved path
I run into false positives now and then (mostly in Clippy) when I want to name some util after HashMap.
|
|
target abi
Implement cfg(target_abi) (RFC 2992)
Add an `abi` field to `TargetOptions`, defaulting to "". Support using
`cfg(target_abi = "...")` for conditional compilation on that field.
Gated by `feature(cfg_target_abi)`.
Add a test for `target_abi`, and a test for the feature gate.
Add `target_abi` to tidy as a platform-specific cfg.
Update targets to use `target_abi`
All eabi targets have `target_abi = "eabi".`
All eabihf targets have `target_abi = "eabihf"`.
`armv6_unknown_freebsd` and `armv7_unknown_freebsd` have `target_abi = "eabihf"`.
All abi64 targets have `target_abi = "abi64"`.
All ilp32 targets have `target_abi = "ilp32"`.
All softfloat targets have `target_abi = "softfloat"`.
All *-uwp-windows-* targets have `target_abi = "uwp"`.
All spe targets have `target_abi = "spe"`.
All macabi targets have `target_abi = "macabi"`.
aarch64-apple-ios-sim has `target_abi = "sim"`.
`x86_64-fortanix-unknown-sgx` has `target_abi = "fortanix"`.
`x86_64-unknown-linux-gnux32` has `target_abi = "x32"`.
Add FIXME entries for targets for which existing values need to change
once `cfg_target_abi` becomes stable. (All of them are tier 3 targets.)
Add a test for `target_abi` in `--print cfg`.
|
|
Use clang 12.0.1 on dist-x86_64/i686-linux
The LLD + ThinLTO __morestack bug has been fixed in 12.0.1, so
we can now update our clang version. This also means that we no
longer need to build Python 2.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add #[default_method_body_is_const]
`@rustbot` label F-const_trait_impl
|
|
Implement Mutation- and BorrowOfLayoutConstrainedField in thir-unsafeck
Since nobody has so far claimed Mutation- and BorrowOfLayoutConstrainedField in rust-lang/project-thir-unsafeck#7, I have taken the liberty of implementing them in thir-unsafeck.
r? `@LeSeulArtichaut`
|
|
Rollup of 11 pull requests
Successful merges:
- #86344 (Split MaybeUninit::write into new feature gate and stabilize it)
- #86811 (Remove unstable `io::Cursor::remaining`)
- #86846 (stdio_locked: add tracking issue)
- #86887 (rustdoc: remove dead code in `clean`)
- #87007 (Fix rust-analyzer install when not available.)
- #87035 (Fix implementors display)
- #87065 (Fix ICE with unsized type in const pattern)
- #87070 (Simplify future incompatible reporting.)
- #87077 (:arrow_up: rust-analyzer)
- #87078 (Rustdoc: suggest removing disambiguator if linking to field)
- #87089 (CTFE engine: small cleanups)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Rustdoc: suggest removing disambiguator if linking to field
This fixes #85615.
`@rustbot` label T-rustdoc
|
|
:arrow_up: rust-analyzer
`@bors` r+
|
|
Fix ICE with unsized type in const pattern
Fixes #87046. The `deref_const()` query currently contains the following check:
https://github.com/rust-lang/rust/blob/e9a387d6cf5961a7f2dcb671da3147bd413355c4/compiler/rustc_mir/src/const_eval/mod.rs#L191-L204
i.e. this will cause an ICE for every unsized type except slices. An error is reported with my changes if such a type is used as a const pattern (this should not be a breaking change, since so far, this has caused an ICE).
|
|
Fix implementors display
Part of https://github.com/rust-lang/rust/issues/86632.
This PR does a few things:
* It fixes of the JS rendered implementors.
* It generates anchors for JS rendered implementors to make it coherent with the others.
* It adds a test to ensure that we won't have the same issue again.
* It changes the way we render the rustdoc-gui crates to simplify it a bit and also to allow to have dependencies without going through compiletest.
Before:
After:
I plan to add the `[src]` links in another PR because this one is already big enough.
cc `@Mark-Simulacrum` (for the bootstrap changes)
r? `@Nemo157`
|
|
Fix rust-analyzer install when not available.
This changes it so that `x.py install` won't fail if rust-analyzer isn't available. This was changed in #86568 to handle the case where installing on stable/beta, and `extended=true`, to skip rust-analyzer. But I neglected to update the install part to also ignore it.
Fixes #86999
|
|
rustdoc: remove dead code in `clean`
Builds on https://github.com/rust-lang/rust/pull/86886 and should not be merged before.
|
|
Update to LLVM 12.0.1
LLVM 12.0.1 has been released, rebase our fork on top of it.
|
|
shrinking the deprecated span
ref: https://github.com/rust-lang/rust/pull/85617#issuecomment-854947988
part of #85403
r? `@estebank`
The reason is that if we use method_span directly, it will cause the in_derive_expansion judgment to fail.
|
|
|
|
|
|
|
