Skip to content

#![no_builtins] attribute occurs twice on BUILTIN_ATTRIBUTES list #43148

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.

Sign up for GitHub

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

Jump to bottom
Closed
pnkfelix opened this issue Jul 10, 2017 · 1 comment
Closed

#![no_builtins] attribute occurs twice on BUILTIN_ATTRIBUTES list #43148

pnkfelix opened this issue Jul 10, 2017 · 1 comment
Labels
C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@pnkfelix
Copy link
Member

(spawned off of #43106)

As the title says, there are two entries for "no_builtins".

They look like:

...
    ("no_builtins", Whitelisted, Ungated),
...
    ("no_builtins", CrateLevel, Ungated),
...

I doubt the duplicate differing entries are a deliberate choice.

I suspect this may be hiding a small bug, since I currently do not get an error from the compiler (including on the stable channel) when I hand it code like this:

#[no_builtins = "0300"]
mod no_builtins { mod inner { #![no_builtins="0200"] }
}

fn main() { }
@pnkfelix pnkfelix mentioned this issue Jul 11, 2017
Merged
bors added a commit that referenced this issue Jul 19, 2017
@bors
Auto merge of #43168 - pnkfelix:check-attr-gating, r=aturon
88e2c39 
Slew of builtin-attribute gating tests

Slew of builtin-attribute "gating" tests for issue #43106.

Some stray observations:

 * I don't know if its a good thing that so many attributes allow inputs which are silently discarded. (I  made heavy use of that in writing my tests, but that was more out of curiosity than necessity.)
 * The difference between crate-level and non-crate-level behavior is quite significant in some cases. Definitely worth making sure one has tests for both cases. (Not as clear whether it was worthwhile trying the various other AST forms like `fn f()` vs `struct S;`)
 * `#[no_builtins]` and `#[no_mangle]` occur twice on the `BUILTIN_ATTRIBUTES` list. Thats almost certainly a bug. (Filed as #43148)
 * We are maximally liberal in what we allow for `#[test]` and `#[bench]` when one compiles without `--test`.
 * We allow `#[no_mangle]` on arbitrary AST nodes, but only warn about potential misuse on `fn`
 * We allow `#[cold]`, `#[must_use]`, `#[windows_subsystem]`, and `#[no_builtins]` on arbitrary AST nodes. I don't know off-hand what the semantics are for e.g. a `#[cold] type T = ...;`
 * We allow crate-level `#![inline]`. That's probably a bug since its otherwise restricted to `fn` items
@Mark-Simulacrum Mark-Simulacrum added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Jul 19, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-bug Category: This is a bug. label Jul 28, 2017
@Centril
Copy link
Contributor

Centril commented Oct 25, 2019

This is no longer the case.

@Centril Centril closed this as completed Oct 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@pnkfelix @Centril @Mark-Simulacrum