Change:
let g = consts::trans_static(ccx, m, item.id); update_linkage(ccx, g, Some(item.id), OriginalTranslation); <del> // Do static_assert checking. It can't really be done much earlier // because we need to get the value of the bool out of LLVM if attr::contains_name(&item.attrs, "static_assert") { if !ty::type_is_bool(ty::expr_ty(ccx.tcx(), expr)) { ccx.sess().span_fatal(expr.span, "can only have static_assert on a static  with type `bool`"); } if m == ast::MutMutable { ccx.sess().span_fatal(expr.span, "cannot have static_assert on a mutable  static"); } let v = ccx.static_values().borrow().get(&item.id).unwrap().clone(); unsafe { if !(llvm::LLVMConstIntGetZExtValue(v) != 0) { ccx.sess().span_fatal(expr.span, "static assertion failed"); } } } </del> }, ast::ItemForeignMod(ref foreign_mod) => { foreign::trans_foreign_mod(ccx, foreign_mod);

Discussion:
In I add a basic form of static assertions (as suggested by graydon in ), but it's not nice to use. The biggest problem with it is you need a static variable with a name, that goes through trans and ends up in the object file. suggested , which I think is a nice API but would need some invasive changed to the compiler (I think, uncertain).
Eh. I'm actually kinda ok with the way it turned out. If it's non-pub it shouldn't wind up in the object file as a public symbol (if it does, we're doing-stuff-wrong in codegen) and we can potentially just mark it as a throw-me-away sort of value harder if LLVM requires further convincing. Considering that static asserts in C are typically done by composing a negative-sized array and allowing the compiler to yell about that, I consider this implementation already pretty luxurious :)
How about having a thats just a wrapper around a automatically generated private static item with the #[staticassert] attribute?
if i understand you correctly, that's what i've suggested in but it seems not straightfoward to implement
Hm, but the current attribute-static item system works, no? Wouldn't a just be trivial sugar for that? Or is the 'generate a name'-part the hard one?
I don't know how to implement a macro to do this, so feel free to take a shot at it :smiley_cat:
Visiting for triage. Doesn't seem like a release blocker.
With hygiene, it should be much easier.
Triage: hygiene doesn't particularly help in this case, it's currently only for names created/bound with . A sketch: Uncommenting the gives a duplicate module error (as one might expect). If there was a macro (for creating a completely new ident) this might help, but is currently not valid as macros aren't allowed in place of s.
Macros can now expand to items with attributes:
triage bump. Nothing to add
It always needs to be crippled enough that it can't cause a compilation failure during expansion of generics. I think we should just remove the current attribute. It doesn't appear to have any real world use cases.
triage: nothing to add. We don't currently use anywhere in the codebase, which leads me to wonder if isn't right here.

An implementation in standard Rust based on the array size trick: In short, an invocation expands to It is variadic because there will be a name collision between two invocations... Yes the usability is horrible.
I wish Rust would support more static features(I use them extensively in C++ in order to enforce correct API usage)... I need to assert the simplest case: making sure the user doesn't pass an empty array/slice - and I cannot do it with the language... It's awful that I have to "assert" at run-time for such a simple case...