Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make format_args! only depend on libcore #14342

Closed
thchittenden opened this issue May 21, 2014 · 6 comments
Closed

make format_args! only depend on libcore #14342

thchittenden opened this issue May 21, 2014 · 6 comments
Assignees
Labels
A-syntaxext Area: Syntax extensions

Comments

@thchittenden
Copy link
Contributor

Currently format_args! relies on format stuff in libstd, all of which is present in libcore. In order to use format_args! in a #[no_std] context you have to reexport core as std which is pretty hacky.

@alexcrichton
Copy link
Member

This is a general issue with macro hygiene. There is no dependency by format_args! on anything other than libcore other than names. Additionally, this isn't quite as easy as a renaming because libcore isn't injected into crates, only libstd is.

Basically, fixing this issue will likely require a significant amount of work in terms of macro hygiene across crates. I would love to have it fixed though...

@sfackler
Copy link
Member

Is there any reason to not just add extern crate core to std_inject?

@alexcrichton
Copy link
Member

I think of core as an implementation detail of std that shouldn't be exposed to users in terms of backwards compatibility. While it would certainly fix this problem for now to inject extern crate core, I don't think we want to do that in the long term.

@kmcallister
Copy link
Contributor

I'm working on a fix for #16803 which will also solve this problem. We tell libsyntax whether the crate is #![no_std] and then the extensions produce references to std or core etc. as appropriate.

@sfackler
Copy link
Member

sfackler commented Sep 7, 2014

We could potentially avoid the back-compat hazards by importing core under a gensymed name so user code wouldn't be able to see that it exists. It would be a bit hacky, though.

@kmcallister
Copy link
Contributor

I'm also making Vec<u8> into a FormatWriter that works without libstd.

kmcallister added a commit to kmcallister/rust that referenced this issue Sep 14, 2014
@kmcallister kmcallister self-assigned this Jan 16, 2015
kmcallister added a commit that referenced this issue Feb 3, 2015
…] crate

Fixes #16803.
Fixes #14342.
Fixes half of #21827 -- slice syntax is still broken.
kmcallister added a commit to kmcallister/rust that referenced this issue Feb 5, 2015
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 20, 2023
…-source-to-status, r=lnicola

Add path of workspace root folders to status output

Hi folks! Just a quick addition to the status output. There are some colleagues of mine who use a mix of Buck and Cargo. A person spent a bit of time this past week trying to figure out there the `rust-project.json` was coming from and pointed out that `rust-analyzer: Status` could be a good place to put this information. rust-analyzer doesn't seem to record the full path of the `Cargo.toml` or the `rust-project.json`, just the root directory. While not perfect, this should be enough for people to unblock themselves on. Here's an example of `rust-analyzer: Status` on the rust-analyzer repo:

```
Workspaces:
Loaded 192 packages across 1 workspace.
Workspace roots: [AbsPath("/Users/dbarsky/Developer/rust-analyzer")]
Analysis:
57mb of files
0b of index symbols (0)
2514 trees, 128 preserved
29535 trees, 128 preserved (Macros)
0b in total

File info:
Crate: rust_analyzer(CrateId(131))
Dependencies: proc_macro=CrateId(5), core=CrateId(2), alloc=CrateId(0), std=CrateId(7), test=CrateId(9), always_assert=CrateId(12), anyhow=CrateId(13), cfg=CrateId(25), crossbeam_channel=CrateId(35), dissimilar=CrateId(41), expect_test=CrateId(46), flycheck=CrateId(50), hir=CrateId(56), hir_def=CrateId(57), hir_ty=CrateId(59), ide=CrateId(63), ide_db=CrateId(66), ide_ssr=CrateId(68), itertools=CrateId(73), jod_thread=CrateId(75), lsp_server=CrateId(83), lsp_types=CrateId(85), mbe=CrateId(87), num_cpus=CrateId(96), oorandom=CrateId(99), parking_lot=CrateId(102), proc_macro_api=CrateId(110), proc_macro_srv=CrateId(111), profile=CrateId(118), project_model=CrateId(119), rayon=CrateId(125), rustc_hash=CrateId(136), scip=CrateId(141), serde=CrateId(145), serde_json=CrateId(147), sourcegen=CrateId(153), stdx=CrateId(155), syntax=CrateId(158), test_utils=CrateId(159), threadpool=CrateId(165), toolchain=CrateId(170), tracing=CrateId(171), tracing_log=CrateId(174), tracing_subscriber=CrateId(175), tracing_tree=CrateId(176), tt=CrateId(177), vfs=CrateId(188), vfs_notify=CrateId(189), xflags=CrateId(192), xshell=CrateId(194)
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-syntaxext Area: Syntax extensions
Projects
None yet
Development

No branches or pull requests

4 participants